Closed simison closed 7 years ago
@chmac probably has good ideas about this because of http://composer.io experience
On Wed, Apr 15, 2015 at 9:56 AM, Mikael Korpela notifications@github.com wrote:
- GitHub
As an Agenda https://www.npmjs.com/package/agenda job (there's already one job https://github.com/Trustroots/trustroots/blob/master/app/jobs/message-unread.server.job.js there.)
How often? Once a week? Once a day?
Probably needs a date field at user model when connection was last refreshed (or consider saving this under connection data?)
Might need some extra permissions ("refresh token"?) from user.
— Reply to this email directly or view it on GitHub https://github.com/Trustroots/trustroots/issues/250.
Pagekite might prove handy for testing this #251
Different services issue tokens with different expiry times. I think with most oauth implementations you can refresh the token server side, without any user involvement. However, with Facebook, the user has to be logged in, and the user has to visit the Facebook URL again. It's a silent redirect, so they come right back, but they have to be logged in to the correct account, etc. It is possible to detect that with the Facebook client side SDK. So, long story short, for Facebook, the best solution is to check if the user is logged in, and if they are, open the oauth flow in an iframe or a pop up. Then it should auto complete and without any interaction from the user, generate a new token.
Oh, and Facebook tokens live for 60 days. I think that's pretty typical. Many oauth services provide a token that's valid indefinitely I believe. No issues with Twitter, you get a token, and that's it, it's good to go (or you can refresh it server side).
Nice, thanks. I think we can therefore start refreshing our already outdated tokens once we write some more features around FB connection and ask for more scope permissions at the same time.
Turns out there's a package: https://github.com/fiznool/passport-oauth2-refresh
You can change the scope for existing tokens through the same process. But, if there have been permissions added, the user will see a window asking them to confirm whether or not they want to grant the additional permissions. I think the Facebook Javascript SDK also has some stuff to make this easy. With Facebook, it doesn't make sense to use any kind of "job" scheduling, because the user must be online, so it's only something to check during a user's session.
Also, it is definitely a good idea to store the token expiry date along with the token itself. That makes this whole thing much easier, otherwise you're basically guessing as to when tokens need refreshing. Only LinkedIn and Facebook require these (I don't know the GitHub API) and they're both 60 days, and both require the user to be logged in.