facebook profile pic url is expired

[s-kris]

Your question
Facebook's profile image url is expired after a month or so. Can next-auth refresh the url automatically?
example pic url saved by next-auth

I referred to this issue: #665 and that is not the case.
Any insight on this please? Thank you!

Feedback
Documentation refers to searching through online documentation, code comments and issue history. The example project refers to next-auth-example.

• Found the documentation helpful
• Found documentation but was incomplete
• Could not find relevant documentation
• Found the example project helpful
• Did not find the example project helpful

[iaincollins]

Not yet but upcoming token support may address this!

Right now you could copy a profile image on sign in and save it to a bucket (or database) and then use that copy as a "forever copy" (e.g. using the signIn() event that is triggered after a successful sign in).

However I haven't wanted to get into that until we had better tooling to help folks address how to do something like responsibly; including supporting linking to a privacy policy / terms of service from the built-in pages; and supporting built in account deletion and profile management so that users can more easily control what data about them is stored.

As an easy to implement alternative, you can also use something like Gravatar to resolve the email addresses on their profile to an image, as that's completely within a users control (and you don't have to worry about hosting it or providing an UI to manage avatars).

[s-kris]

I was thinking to override signin method as a last resort but gravatar sounds good too :)

I'll be looking forward to more awesome updates!

Thank you @iaincollins

[martinbavio]

I'm curious @iaincollins, why would you do it on the signIn() event rather than on the signIn() callback?

[iaincollins]

I'm curious @iaincollins, why would you do it on the signIn() event rather than on the signIn() callback?

Great question!

The signIn() callback lets you determine if someone should be allowed to sign in or not and is called before the user is created. The name might be confusing as it's role is something like allowSignIn() but it was named as it is to create a consistent convention and with a view to possibly expanding it in future (e.g. to allow it to it to return a user object so that operations like this could be done within the callback).

I suggest the signIn() event instead because it is called after a user has signed in (and been created in the database if they didn't exist already) so at that point you will have a User ID in the parameters passed to the event, and so its easier to update the entry for that user by updating their entry in the database.

---

An option for the future I've had in mind is a specific profile() callback to allow you do exactly this operation (i.e. to intercept all profile objects, after signIn() callback is called and account verified but just before it's written to the database).

There is no ETA on this though, so I think probably the signIn() event is the best place to do this if using a database (and that is not a feature I would expect to ever change, even if we introduced easier ways of doing it in future, so can be regarded as a stable feature).

[martinbavio]

@iaincollins thanks for sharing your two cents! Indeed a very important distinction, the callback happens before but the event happens after. profile callback sounds intriguing, I currently have a need to save more fields to the user profile on signup, so that callback might be the way for me to not have to make an extra call to the DB. But for now, I'll use the signIn() event!

[martinbavio]

Btw, I think you meant to write "...so I think probably the signIn() callback event is the best place..." in your last paragraph.