search

emonarafat / socialauth-net

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

WebForm Authenticated User Gets Overriden #85

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. Log in using Forms Authentication with a local user/pass
2.log in to any of the providers
3.check User.Identity.Name

What is the expected output? What do you see instead?
I would expect to see the originally logged in user. Instead, i see a token 
string.

What version of the product are you using? On what operating system?
2.1.0.0. Windows 7. ASP.NET MVC 3

Please provide any additional information below.

Original issue reported on code.google.com by ppcu...@gmail.com on 23 May 2012 at 3:10

GoogleCodeExporter commented 9 years ago 
I forgot to add that i am following all the instuctions on how to configure the 
web.config so it doesn't do authentication, but it's still happening.

Original comment by ppcu...@gmail.com on 23 May 2012 at 4:06

GoogleCodeExporter commented 9 years ago 
Hi ppcuban,

We are taking a look at the issue and will update you in a couple of days.

Warm regards,
Abhinav

Original comment by l...@brickred.com on 25 May 2012 at 11:51

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
Hi,

We have identified the issue and would soon be fixing it in one of our future 
releases. However, if you don't wish to wait for the release, you can implement 
the following code changes in our library in order to resolve the issue (which 
is probably the way we are going to implement the fix as well):

In the SetUserAsLoggedIn method of the SocialAuthUser.cs file under 
BusinessObjects, 
add a condition for the above scenario to the code for last condition (forms 
authentication):

            if (string.IsNullOrEmpty(HttpContext.Current.User.Identity.Name))
                    FormsAuthentication.RedirectFromLoginPage(SessionManager.GetUserSessionGUID().ToString(), false);
                else
                    FormsAuthentication.RedirectFromLoginPage(HttpContext.Current.User.Identity.Name, false);

Please let us know if you face any issues.

Thanks,
Meenakshi

Original comment by meenaks...@brickred.com on 28 May 2012 at 12:10

GoogleCodeExporter commented 9 years ago 
Thank you so much. It is funny that i found out about this fix thru 
stackoverflow :))) Crazy internet.

Original comment by ppcu...@gmail.com on 30 May 2012 at 2:23

GoogleCodeExporter commented 9 years ago 
Hi, I have tried your proposed solution, but it doesn't seem to work in this 
scenario:

Trying to adapt a current website and after succesful Login, when callback 
function is called, I get from my database the related username from my users 
table and try to set the authentication cookie with that value.

My callback function looks like:
    private void LoggedIn()
    {
        string displayName = SocialAuthUser.GetCurrentUser().GetProfile().DisplayName;

        string userName = GetUserNameFromDB(displayName);
        FormsAuthentication.SetAuthCookie(userName,false);
    }

Then, when code flows to SetUserAsLoggedIn method, 
HttpContext.Current.User.Identity.Name is still empty, because the valid 
username is stored in a Cookie in Response, but not yet processed. So, in the 
end, instead of having my custom 'userName', I got the GUID.

Still haven't figured out how to sort this. I will let you know I find any 
solution. Any idea on your side?

Original comment by ava...@jsvrfid.es on 31 May 2012 at 11:46

GoogleCodeExporter commented 9 years ago 
Hi avalor,

For your scenario, a check can be added to the same code for identifying 
whether the authentication cookie is already set, as:

if 
(string.IsNullOrEmpty(HttpContext.Current.Request.Cookies[FormsAuthentication.Fo
rmsCookieName].ToString()))
                {
                    if (string.IsNullOrEmpty(HttpContext.Current.User.Identity.Name))
                        FormsAuthentication.RedirectFromLoginPage(SessionManager.GetUserSessionGUID().ToString(), false);
                    else
                        FormsAuthentication.RedirectFromLoginPage(HttpContext.Current.User.Identity.Name, false);
                }

However, in this case, redirection to the originally requested URL would have 
to be handled in your callback:
private void LoggedIn()
    {
        string displayName = SocialAuthUser.GetCurrentUser().GetProfile().DisplayName;

        string userName = GetUserNameFromDB(displayName);
        FormsAuthentication.RedirectFromLoginPage(userName, false);
    }

Please let us know if this solves your issue.

Thanks,
Meenakshi

Original comment by meenaks...@brickred.com on 31 May 2012 at 12:49

GoogleCodeExporter commented 9 years ago 
Hi! Finally I have developed a solution that is quite similar to the one you 
have proposed, but where there's no need to perform the RedirectFromLoginPage 
in callback as you proposed. The key of this is to check for the ASPNET cookie 
in Response:

SessionManager.ExecuteCallback();
                if (string.IsNullOrEmpty(HttpContext.Current.User.Identity.Name))
                {
                    HttpCookie newAuthCookie = HttpContext.Current.Response.Cookies[FormsAuthentication.FormsCookieName];
                    if ( newAuthCookie != null)
                    {                         
                        FormsAuthenticationTicket ticket = FormsAuthentication.Decrypt(newAuthCookie.Value);
                        FormsAuthentication.RedirectFromLoginPage(ticket.Name, false);
                    }
                    else
                        FormsAuthentication.RedirectFromLoginPage(SessionManager.GetUserSessionGUID().ToString(), false);
                }                    
                else
                    FormsAuthentication.RedirectFromLoginPage(HttpContext.Current.User.Identity.Name, false);

I have tested and it seems to work fine. Do you think this is a good 
implementation? Please let me know, thanks!

Original comment by ava...@jsvrfid.es on 31 May 2012 at 5:07

GoogleCodeExporter commented 9 years ago 
In my scenario, since i am not interested in authentication, i am going to 
simply comment out the whole code after the session.executecallback(). If i 
need any implementation, i would use the Action for this.

there should be a setting in the web.config where you tell the component 
(socialauth dll) to ignore the whole authentication process and use it 
exclusively as a retriever of contacts from the other providers. 

so far, great library.

Original comment by ppcu...@gmail.com on 1 Jun 2012 at 3:25

GoogleCodeExporter commented 9 years ago 
Hi avalor,

Thanks for your inputs! The solution you provided works well and we would 
probably incorporate this in one of our future releases after analyzing and 
testing with any other possible scenarios.

Thanks,
Meenakshi

Original comment by meenaks...@brickred.com on 1 Jun 2012 at 8:40

GoogleCodeExporter commented 9 years ago 
Thanks ppcuban!

We would look into the possibility of adding a setting for ignoring the 
authentication process.

Meenakshi

Original comment by meenaks...@brickred.com on 1 Jun 2012 at 8:43

GoogleCodeExporter commented 9 years ago 
Closing this issue as base issue stands resolved in 2.3. Possibility to stop 
execution post Session.ExecuteCallback will be added as a separate issue for 
next release.
Deepak

Original comment by daggar...@brickred.com on 14 Jul 2012 at 5:13

GoogleCodeExporter commented 9 years ago 
Did this ever get fixed? I just downloaded the NuGet version and i am still 
having the same issue.

Original comment by ppcu...@gmail.com on 1 Dec 2012 at 7:04

GoogleCodeExporter commented 9 years ago 
Hi, 

This issue has been fixed. I checked again with the latest NuGet version 
(2.3.0.0) and it works i.e. I get the forms authenticated user in 
User.Identity.Name, as mentioned in the original issue. Could you provide some 
more information on the issue you are facing along with code samples, if 
required?

Thanks,
Meenakshi

Original comment by meenaksh...@3pillarglobal.com on 3 Dec 2012 at 11:54

GoogleCodeExporter commented 9 years ago 
I am sorry. This issue HAS NOT BEEN FIXED. This is an example. I have a 
registration process in my website. I am registering the user (NOT LOGGING IN). 
One of the step is to import his contacts to invite his contacts to use our 
service. As soon as i import contacts, this user can access the website as if 
he was Authenticated.

That's a huge bug. 

I am going to reopen this ticket.

Original comment by ppcu...@gmail.com on 14 Jan 2013 at 6:53

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
For the little I know about this subject, and for what I've seen in many 
services that use OAuth in its registering process and offer to 'invite' 
contacts, this is always a 'ok! where are almost done here' step. This means, 
at that time the user has already given its permission to FB, twitter... to 
connect with the site and retrieve the related information about contacts. So, 
it's logic to think that the registration process has already finished and now 
we are taking optional steps.

I hope this helps you.

Original comment by ava...@jsvrfid.es on 15 Jan 2013 at 8:27

GoogleCodeExporter commented 9 years ago 
No No No. You are missing the point here. What i am talking about here is that 
this API should offer a way to import contacts (as they claim they have) 
without affecting your internal authentication mechanism. What if i have a very 
sophisticated (complex) way to authenticate users that involves Roles, Captcha, 
etc, etc, etc, etc, etc. 

This is not about what people may think of your registration process or how 
'shady' might be. If that's your concern, i guess you don't have a facebook 
account then. Can't get any more shady than that.

My point here is, now that i mention facebook, importing contacts using this 
API shouldn't override your internal authentication values. When you import 
'Friends' in facebook, you don't end up with your username being a GUID... your 
credentials remain the same. 

That's my point.

This is the problem with FREE stuff. Since we are not paying a dime for this, 
we should be content with whatever we have. Just like Socialism. I am very 
happy so far with this tool, but, they still have to fix all the bugs BEFORE 
you ask people for FEATURES SUGGESTION. Here is my suggestion. Make it PERFECT.

Original comment by ppcu...@gmail.com on 15 Jan 2013 at 3:54

GoogleCodeExporter commented 9 years ago 
ppccuban,

I doubt there is anything called perfect :) We all have a limited amount of 
time - whether it is free or paid. And we need to focus on where the largest 
number of users are, as you will no observe with even your own website.

Thanks for your suggestion.

Original comment by abhinav....@3pillarglobal.com on 15 Jan 2013 at 4:07

GoogleCodeExporter commented 9 years ago 
:) Perfect shouldn't be the right word of choice. I understand you're trying to 
help the community. Don't take my words as a destructive critique. I WANT to 
use your API because it's one of the best out there. I am pretty sure i am not 
the only one having this problem. Most people they wouldn't even take the time 
to post issues, since all they do is just to switch over a different library.

I didn't quite understand your last sentence. "as you will no observe with even 
your own website"... what did you mean?

Original comment by ppcu...@gmail.com on 15 Jan 2013 at 6:20

GoogleCodeExporter commented 9 years ago 
Thanks for understanding :) It was meant "as you will no doubt experience with 
even your website", i.e. even a paid product has to prioritize the features 
which a large number of users need. It is certainly possible that some users 
may have turned to other libraries without reporting that they need this 
feature.

I can understand your understanding of this as a bug - but it is more like a 
feature to us, because we had intended this library to be used as "the" 
authentication mechanism of the website, and hence the name socialauth.

Original comment by abhinav....@3pillarglobal.com on 15 Jan 2013 at 6:42

GoogleCodeExporter commented 9 years ago 
We all do experience issues with our own code. That's not the point.

Ok, now that i read what you may consider a feature (as opposed to a bug), i 
understand why this doesn't seem a priority to you. 

I guarantee you that there is a lot of people out there wanting this feature to 
be available. And i truly think it wouldn't take much ;). 

In the other hand. Let me give you a scenario. Let's say that i am certainly 
willing to use your api as a authentication mechanism. Let's say that i let the 
user pick whatever provider he wants. Then i save that username in my database 
because i need to assign him an id for all relational tables. Next time he 
comes, if he uses a different provider, he is going to be authenticated, but, 
to my system, it's a brand new user. Even if i check for that username and 
return a not found, he is already "authenticated"... meaning he can access any 
area that might be protected in my website. 

Anyway, i am going to download the source code and modify some code and let you 
know how it goes about ONLY importing contacts.

For a market standpoint, you will be WAY more successful making this the main 
feature of your API, than authenticating. There is a good article i just can't 
find right now, on "Why People Don't Like to Use Social Media as their Login 
Credentials" and the main reason is because they forget which provider they 
used for a specific website. I will try to find it and post it here.

Original comment by ppcu...@gmail.com on 15 Jan 2013 at 9:16

GoogleCodeExporter commented 9 years ago 
http://blog.mailchimp.com/social-login-buttons-arent-worth-it/

I think this is the article. Can't quite remember but still prove a point.

By the way, i must admit you're very proactive toward issues follow-ups. 10 
points on that.

Original comment by ppcu...@gmail.com on 15 Jan 2013 at 10:07