search

meteor-utilities / avatar

Consolidated Avatar Template Package for Meteor https://atmospherejs.com/utilities/avatar
57 stars 27 forks source link

Consider normalizing the email address for Gravatar #15

Open dandv opened 9 years ago

dandv commented 9 years ago

If the user registers with a sub-address (e.g. joe+yourapp@gmail.com), Gravatar isn't smart enough to find the picture of joe@gmail.com.

I've just released a package to correct for that, idorecall:email-normalize. I can proudly say that it's the best solution I've seen so far for this problem, as it supports not just Gmail, but any domain hosted with Google Apps for Work (via an MX DNS lookup), plus FastMail, Microsoft, Yahoo! and others.

timothyarmes commented 9 years ago

That looks great, but what happens if a user's registered Gravatar address is, for example, forename.surname@gmail.com?

If it's normalized to forenamesurname@gmail.com (without the dot) then it won't be recognised, which defeats the intent of your package.

dandv commented 9 years ago

Gravatar should of course always be checked for the original address first. I've added a note about that.

The user might also have different avatars for different subaddreses, e.g. joe+games@example.com vs. joe+professional@example.com.

SeanBannister commented 9 years ago

This would be really great, we've noticed this happen a number of times and normalizing would be handy,

P.S. Just saw your talk on the Devshop SF live stream and came to post this issue :)

timothyarmes commented 9 years ago

I'd be happy to accept a PR for this. Here are some considerations that need to be made:

  1. The code that hides the avatar when there's an error loading the image will need to be modified to retry with the normalised address, both for the Blaze and React templates.
  2. We also need to allow the user to supply more that one email hash too (one based on the address given, one on the normalised address). It would make sense that the current hash property should hence forth be *either a string, or an array.
  3. We currently have a convenience function for generating the Gravatar-compatible hash. This should be updated to optionally return the array instead.

I do have a reservation about performance since we're now doubling the number of requests. Is this an issue?

dandv commented 9 years ago

@SeanBannister, thanks for the kind words.

@timothyarmes: unfortunately I'm on a very tight deadline and have to limit the scope of my contributions. Happy to make idorecall:email-normalize adapt for use by meteor-utilities:avatar, while letting the team handle the considerations you've brought above.

In terms of performance, the only potentially slow operation is the DNS MX record lookup, which is optional (detectProvider: false). DNS lookups are pretty fast though, and the result of the normalization can be cached, so only one lookup would need to be made per email address.

timothyarmes commented 9 years ago

Also compare to #39, which is complementary and probably far more likely to occur.