[buddypress-trac] [BuddyPress] #4571: Changes in Gravatar APIs result in failed fallback on default avatars

[buddypress-trac at lists.automattic.com]

#4571: Changes in Gravatar APIs result in failed fallback on default avatars
--------------------------+-------------------
 Reporter:  boonebgorges  |      Owner:
     Type:  defect (bug)  |     Status:  new
 Priority:  normal        |  Milestone:  1.6.2
Component:  Core          |    Version:
 Severity:  major         |   Keywords:
--------------------------+-------------------
 BP allows admins to specify a default avatar, which is to be used when a
 user both has no Gravatar and has not uploaded a local avatar. We
 implement this by passing the URL of the default avatar along to Gravatar
 using the `?d=` parameter. I'm not 100% sure how Gravatar handles these
 params, but it appears that they cache a copy of the local avatar and
 serve it from their servers.

 A change made at gravatar.com last week means that this method no longer
 works in all cases. For security reasons, your default image must now be
 "publicly accessible". That means that they can't be behind HTTP
 authentication or otherwise hidden with Apache rules. See
 https://twitter.com/beaulebens/statuses/251407787341524992

 I first noticed this in a password-protected staging environment, but
 users are already reporting the issue in their production installations.

 Possible solution: Near the end of bp_core_fetch_avatar(), we detect when
 a Gravatar query has failed, and if so, we serve up the local default
 directly.

-- 
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/4571>
BuddyPress <http://buddypress.org/>
BuddyPress