Is the application storing the OAuth details on the server against the user? This would be the approach I would have thought should be taken with OAuth? ... --Message 1 of 4 , May 15, 2012View SourceIs the application storing the OAuth details on the server against the user? This would be the approach I would have thought should be taken with OAuth?On 16 May 2012 10:14, iosart <alex@...> wrote:
I'd also like to see if there's a solution to this. It would definitely make more sense IMHO for Flickr to redirect right back if the user has already authorized the app (as it always did with FlickrAuth), instead of displaying the 'app authorization' page every time. In Flickriver's case, this will be affecting thousands of users once the site moves to OAuth.
Any Flickr folks reading this? Would really appreciate your thoughts.
--- In firstname.lastname@example.org, "medvekoma" <medve@...> wrote:
> Hi all,
> I am also facing the same problem with my web application, and I'd like to see an 'official' flickr recommendation on how to implement the login workflow without forcing the user to re-authorize with every login.
> I personally don't like storing the token and the secret in a cookie, for several reasons:
> - In is browser and computer related, the user is forced to re-authorize on every computer and browser she uses.
> - Probably doesn't work if more people are logging in with different flickr accounts on the same browser.
> - I am also not too comfortable with sending the secret through the wire, I feel that it compromises the official oauth workflow.
> Are there any plans to implement bypassing re-authorization on flickr side?
> Attila / medvekoma
> --- In email@example.com, "jef_poskanzer" <jef@> wrote:
> > So a while back in the Flickr API group, another app developer noticed a difference in how OAuth interacts with the user. He doesn't store his token in a cookie, he just runs through the whole authorization flow every time. With old flickr auth, this would just mean a little back-and-forth but no extra user interaction - flickr would see that a token exists and is authorized, and would not ask the user about it. However, when he tried the same thing with OAuth, flickr did ask the user to re-authorize the app.
> > I got around to testing this today and can confirm the difference. I do store my token in a cookie, but if I delete the cookie - not revoking the authorization, just deleting the client-side record of it - then an old flickr auth flow just gets the token again, while the OAuth flow asks the user to re-authorize and then returns the token.
> > The part I found interesting is that the token OAuth returns is the same one I had before. So flickr isn't just throwing away the old token and authorizing a new one, it really is re-authorizing an existing token. To me that indicates it should be possible to have the OAuth flow short-circuit re-authorization too.
> > I actually don't care one way or the other about this one. Since I do use a cookie, it won't impact my users. But I thought I'd put the issue out there.
> > ---
> > Jef
m: +61 401 501 625
p: http://flic.kr/jufemaiz/t: http://twitter.com/jufemaiz