search

nguyentientoan / socialauth-net

Automatically exported from code.google.com/p/socialauth-net
0 stars 0 forks source link

Auto-login with other providers just like Facebook? #96

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago 
What steps will reproduce the problem?
1. Setup Twitter provider
2. do initial login, authorizing app
3. login a second time to app, must authorize app again

What is the expected output? What do you see instead?

When using the Facebook provider I only have to authorize the application one 
time and subsequent attempts to login are just handled automatically without a 
reauthentication. I recently added Twitter and Google as providers for my app 
and every time I login I get redirected to Google/Twitter and have to authorize 
the app again. I expected to only have to authorize the application once.

What version of the product are you using? On what operating system?
2.3 - Windows Server 2008 R2 (although, hosted, so I can't say exactly what).

Please provide any additional information below.
It's an MVC3 application

Original issue reported on code.google.com by Matthew....@gmail.com on 2 Jul 2012 at 3:02

GoogleCodeExporter commented 8 years ago 
Can you monitor if your app is removing the provider cookies somehow? Here is 
how it works for me. 

It authorizes only once per site per provider upon success login. Only if you 
changed site, say from your localhost to your actual domain, it will ask you to 
authorize again for security reasons.

Original comment by kelvin1...@gmail.com on 3 Jul 2012 at 2:58

GoogleCodeExporter commented 8 years ago 
Should the cookie show up under my site url (I'm using Chrome 20, btw)?

Original comment by Matthew....@gmail.com on 3 Jul 2012 at 3:21

GoogleCodeExporter commented 8 years ago 
What cookie am I supposed to be looking for? I don't see any created by my 
application or by the demo application (Chrome 20, if it matters)?

Original comment by Matthew....@gmail.com on 11 Jul 2012 at 11:38

GoogleCodeExporter commented 8 years ago 
Hi Matthew,

Clarity on SocialAuth.NET:
SocialAuth.NET cookies are used for running authentication framework only. 
Every provider sets its own cookie which SocialAuth.NET is not aware of (and 
shouldn't be). For example, when you request SocialAuth.NET to login with 
Facebook, it passes your request to Facebook which has its own login screen and 
sets its cookie upon login. It conveys via callback to SocialAuth.NET that user 
is now logged in. When user requests login again with same provider, the 
process repeats. I.e., SocialAuth.NET again requests provider. However, if 
provider finds their cookie they may bypass authentication process and convey 
SocialAuth.NET that user is already logged in or show login screen to user or 
just permissions grant sccreen. You can not force authentication from a 
provider using any mechanism.

I tried to replicate your scenario using Chrome 20 and Google as provider. Upon 
login, the screen where Google displays list of requests application is 
demanding, there is a checkbox that states like "Remeber Approvals". If I check 
it and try re-login,  Google automatically bypass authentication and permission 
approval process and application logs in user. If I do not check it and attempt 
login again, though user wouldn't need to specify credentials but would need to 
grant permissions to application. Different providers have different behaviors. 
For example, Yahoo almost always needs permissions approval while Facebook 
happily logs in user silently. Browsers too have a role in varying behavior 
sometimes in context of their cookie expiry behaviors.

To sum up, issue you are facing is not related with SocialAuth.NET or MVC. It 
is likely a combination of browser support for cookies, Provider's 
authentication framework and finally options selected by user (where 
applicable).
However, you might come across sites like TripAdvisor.com, where you'd be 
amazed to see the level of information fetched from profile and displayed. They 
are paid sponsors and get additional access which are not available in general.

As an advance approach, you might save the authenticated tokens in database and 
pass them to login method of socialauth.net as argument. This would force user 
to login into application automatically (but wouldn't guarantee that token is 
still valid for provider. Ideally, I do not think there is any need to bring in 
such complexity and your issue is normal.

Hope it helps :)

I'm closing this issue for now. Please feel absolutely free if my response 
doesn't answers your query.

Deepak

Original comment by daggar...@brickred.com on 14 Jul 2012 at 6:11

GoogleCodeExporter commented 8 years ago 
[deleted comment]
GoogleCodeExporter commented 8 years ago 
Hi SocialAuth.NET Team,

Based on my understanding Mathew wants to authorize the application only once, 
which in fact is impossible because of the UserLoginEndpoint value specified on 
TwitterWrapper.

public override string UserLoginEndpoint { get { return 
"https://api.twitter.com/oauth/authorize"; } set { } }

The problem has something to do with the above code. To make the authorization 
only once we need to change the value of UserLoginEndpoint to:

public override string UserLoginEndpoint { get { return 
"https://twitter.com/oauth/authenticate"; } set { } }

Please refer to app authorization page.jpg currently SocialAuth will redirect 
the user to this page when SocialAuthUser.Login() method has been called 
whether he authorize the app or not, right? 

Please refer to must authorize app again.jpg once he authorized the app and he 
tried to login again he will be redirected to the same page but different 
content.
Here is the screen cap of the alteration I made to the code edited source.jpg. 
And here is the solution I think he wants expected page.jpg

I hope this can help.

Best Regards,

Lawrence

Original comment by lawrence...@gmail.com on 11 Aug 2012 at 3:57

Attachments:

GoogleCodeExporter commented 8 years ago

Original comment by deepak.a...@3pillarglobal.com on 16 Nov 2012 at 12:35

GoogleCodeExporter commented 8 years ago 
Thanks lawrence.ivp
You were correct. This issue is fixed in 2.3.1

Deepak

Original comment by deepak.a...@3pillarglobal.com on 18 Jan 2013 at 9:18