I have seem a few of these asking the same question but none of the solutions have worked for me thus far so I wanted to see if I am doing something wrong. I have a site that I am using asp.net MVC to create, at current I am using forms authentication to prevent anonymous users from browsing the site. That bit of code is as follows.
<authentication mode="Forms" >
<forms loginUrl="~/login" timeout="15"/>
</authentication>
Then I have a login controller that has the user enter their userName and password then creates an authcookie if the information is accurate.
if (password == encryptedPassword)
{
FormsAuthentication.SetAuthCookie("user", true, model.userName);
}
All of this works in Firefox and Chrome and after the user has logged in he is able to browse the site. However in IE it keeps returning to the log in screen because it keeps recognizing the user as an anonymous user. I checked and the Auth cookie is either never created or doesn't persist as soon as you enter the next page. Some of my attempts to fix this involved using cookieless in the web.config. The only one that works was the one that actually puts the cookie in the URI and we can't have that for the site. Then I tried setting ticketCompatibilityMode="Framework40" but there was no luck there either.
I did see a bug with domain names having non-alpha numerica characters. I currently use the IP to access the domain directly, so I don't know if periods run this problem but even my local host suffers from the same issues. Any input would be appreciated.
Parameters should be in the following order.
FormsAuthentication.SetAuthCookie(model.userName, true, ...);
OR
FormsAuthentication.SetAuthCookie(model.userName, true);
http://msdn.microsoft.com/en-us/library/system.web.security.formsauthentication.setauthcookie.aspx
Related
I have some code where we create an authentication ticket. After creating the ticket, we call SetAuthCookie to set the cookie such as:
FormsAuthentication.SetAuthCookie(username, true);
Response.Redirect("/", true);
If I check on the root page to see if the user is authenticated, it returns false. However, if I hard code the username in and do:
FormsAuthentication.GetAuthCookie("jason", true).value);
I get the appropriate cookie value. So, the cookie exists. But the name and the flag are not modified. Any ideas as to what my issue could be? I'm using ASP.NET 4 and MVC.
Solved
I was missing the forms section in the web.config. It was removed for local testing as the login form resides on another server. So, adding the following to web.config solved my issue:
<authentication mode="Forms" />
I'm trying to set up SSO on two separate IIS web sites (with a common domain) using Forms Authentication. I'm using the common approach of setting the auth cookie to the common domain and using matching machine key to enable decryption.
This works with no issues on test sites that I created. However, when trying to implement this in a legacy Web Forms site, I'm running into something that I don't understand.
When I log into one site, the test code on the second site has the following results:
var cookie = FormsAuthentication.GetAuthCookie("username", false); // works
var ft = FormsAuthentication.Decrypt(cookie.Value); // returns correct info
var isAuthentication = User.Identity.IsAuthenticated; // false
As an added bonus, whenever I sign in one site the other gets signed out (happens both ways.)
There must be something fundamental that I'm missing here.
Why is User.Identity.IsAuthenticated set to false, even though the FormsAuthentication ticket seems to be decrypting with no issues?
UPDATE: as pointed out below - FormsAuthentication.GetAuthCookie is not a valid way to obtain the existing auth cookie. Which brings me to this: I can see the top domain cookie in the browser, but it doesn't show up in the request. I suspect this is where the problem is occuring.
Solution: Both sites were not targeting the same version of .Net Framework as specified by the web.config:
<httpRuntime targetFramework="4.5" />
<compilation debug="true" targetFramework="4.5" />
Updating both sites to target the same framework fixed the problem.
The GetAuthCookie creates a new cookie:
http://msdn.microsoft.com/en-us/library/vstudio/3fay1e4k(v=vs.100).aspx
Creates an authentication cookie for a given user name. This does not set the cookie as part of the outgoing response, so that an application can have more control over how the cookie is issued.
No wonder it works, it doesn't look into the existing cookie.
My theory is that you have your new sites on an x64 machine and the legacy website sits in an x86. The encryption differs in such scenario even if keys are the same. Another possible reason is a different version of .net as the encryption algorithm has been changed in .net 4.
I am pretty sure I do not have a unique problem, but I have searched all over google and this site and I haven't found a solid answer for what I am looking for. So I wanted to explain myself to see if I could get any help on this issue:
We (my co-workers and I) determined that we need have cookie-less Sessions because our users require multiple sessions to get their work done in a more productive fashion.
Example
Bob the user could have initiated a long running process in window A and in order to continue working Bob will open window B which spawns a new session. This is necessary in order to not disturb what is going on in window A. Every time Bob opens a new window, he has to log in again.
The Problem
I am not really sure if this is a real problem or not, hence my reason for asking. The problem I think I have discovered is that each time Bob logs in, the current Forms Authentication Ticket (and Cookie) are over-written. Now I do not understand how this is okay or why the previous Session/Window combo is still valid after Bob logs in a second time. Since the ticket was over-written doesn't that mean the first Session/Window combo should end because the ticket is no longer valid? This is with respect to:
Request.IsAuthenticated //Making sure the supplied ticket is valid
Questions
So since the Forms Authentication Ticket (and Cookie) are being over written, what does this mean?
Should I be concerned that the ticket (and Cookie) are being over written?
During login, should I be intercepting the ticket (if any) and checking for its expiration? If it is not expired should I try to renew the ticket or just make a new one?
FormsAuthentication.RenewTicketIfOld(ticket) //Just an example
If I am using a cookie-less session should I just use cookie-less Forms Authentication too? The point of doing this would be to make each Session/Window 100% independent of each other. No over-writing would occur anymore. Is there a draw back to this? I can't think of any.
PS: I know the cookie is just a container for what ever is being stored in it, like a Key Value pair.
Additonal Info...
Forms Authentication Ticket:
IsPersistent set to true
Ticket Version 2
Forms Cookie:
Key = FormsCookieName (from web.config tag)
Value = Hashed Ticket
Web.Config:
<sessionState
cookieless="true"
mode="SQLServer"
sqlConnectionString="..."
timeout="300"
regenerateExpiredSessionId="true" />
<forms name="FormsCookieName"
path="../"
loginUrl="Login.aspx"
protection="All"
timeout="300"
slidingExpiration="true" >
</forms>
The default document feature is turned off in IIS and here's the situation...
My start page for my project say is A.aspx. I run the project and sure enough, A.aspx appears in the url of the browser. Like it should though, A.aspx finds no user logged in and redirects to Login.aspx like it should.
A.aspx:
if (Session["UserStuff"] == null)
Response.Redirect("~/Account/Login.aspx");
The login.aspx shows up BUT when the user Logs in, the code:
FormsAuthentication.RedirectFromLoginPage(txtUserName.Text, true);
always redirects to "Default.aspx" and not "A.aspx"
I've examined FormsAuthentication.GetRedirectUrl and sure enough it returns "Default.aspx"
I'm stumped????
In web.config you could set the default page using the defaultUrl attribute:
<authentication mode="Forms">
<forms
loginUrl="login.aspx"
defaultUrl="a.aspx"
protection="All"
timeout="30"
/>
</authentication>
http://www.codeproject.com/KB/aspnet/custom_authentication.aspx Follow this
If you're using FormsAuthentication, your settings should be defined in the web.config. It sounds like you have a default setting in the web.config for DefaultUrl. You shouldn't need the session redirect though. FormsAuthentication should perform this for you. It doesn't hurt to check the session and force a SignOut() if you don't find it, but FormsAuthentication should perform this redirect.
From my understanding, when the user is redirectoed to your login screen, the Forms Authentication mechanism will add the url of the page that the user was originally tring to access, to the login url that that they user tried to access. For example, if you had a login page: http;//bob/login.aspx, and a user tried to access http;//bob/showmethemoney.aspx, then they would get redirected to http;//bob/login.aspx?ReturnUrl=showmethemoney.aspx. So, if you use the ReturnUrl to redirect the user after the user logs in, the user will always be returned to the resource that they were originally trying to get to.
My site allows anonymous users.
I saw that under heavy load anonymous users get sometimes profile values from other users.
I first delete my cookies and get a valid unique value in the cookie value .ASPXANONYMOUS. After a couple of requests I get a new value for .ASPXANONYMOUS which is already used by another user. I see in my loggs that there are always a couple of users who share the same value in .ASPXANONYMOUS.
I can see in the my logs that 2 or more users realy get the same cookievalue for .ASPXANONYMOUS even if they have different IP.
Here is the htttp traffic. In the second image the changing cookie is shown (You have to display the image full size do be able to read the log):
One of the many requests that work ok:
alt text http://img413.imageshack.us/img413/2711/log1.gif
Then there is this one request that changes the cookie
alt text http://img704.imageshack.us/img704/8175/log2.gif
Then the new cookie is used
alt text http://img704.imageshack.us/img704/3818/log3.gif
Just to be safe I removed dependency injection.
I dont use OutputCaching.
My web.config has this setting for authentication:
<anonymousIdentification enabled="true" cookieless="UseCookies" cookieName=".ASPXANONYMOUS"
cookieTimeout="30" cookiePath="/" cookieRequireSSL="false" cookieSlidingExpiration="true" />
<authentication mode="Forms">
<forms loginUrl="~/de/Account/Login" />
</authentication>
Does anybody have an idea what else I could log or what I should have a look at?
UPDATE
I saw now that the http-traffic I showed is perfectly valid. A changing value in .ASPXANONYMOUS is something that happens because the cookie gets refreshed. The value contains AnonymousID and a Timestamp.
This does not lead to users having the same value in .ASPXANONYMOUS under normal conditions.
The problem realy is, that whenever the cokies get set from the AnonymousIdentificationModule, then there is a chance that a couple of user get this cookie. Setting a cookie in my application doesnt have this strange sideefect.
I had the same problem and solution was to turn off output caching for the responses where you call SetCookie. Below are several links describing this
Don’t let your cookie being cached by accident!
ASP.NET Session Mix-up using StateServer (SCARY!)
Integrated Pipeline and the kernel-mode cache
Are you declaring any static variables in your code at all? I had this similar issue, and narrowed it down to that; at least for my situation.