I am developing ASP.NET MVC application. I made some changes to save some extra info in cookie in latest version.
Few of my customers are still running old version.
Is there any way to expire the existing cookies of my existing customer and enforce them to log-on again when they connect to my new application hosted in IIS?
Thanks,
You could use the SignOut static method:
FormsAuthentication.SignOut();
This will remove the authentication cookie and on subsequent requests the user will not be authenticated. I stressed the word subsequent because after calling this method you should redirect.
I am giving newer name to my cookie in web.config, and this seem to solve my problem:-
<forms loginUrl="~/Account/LogOn" name="InsightWebMobileCookie2" timeout="10000" slidingExpiration="true" />
The problem here is you cannot read the cookie expiration date so you don't know from the cookie who the old users are.
So your options are:
If you can figure out who is from the 'old' version - have logic to expire their cookie.
Force everyone to logout once if they dont have a cookie named "VersionLogout". Once you force their logout, set a cookie named "VersionLogout" with a value of 1.2 for example, this way you know you've forced their logout for a particular version and they (going forward) won't be prompted again.
You would put that code in a Application_AuthenticateRequest event in the global.asax. at this point a user has been authenticated so you can check their cookie there.
Related
I have an ASP.NET MVC (not Core) web app that uses another site to authenticate the user, which involves navigating to the other site and back. I store information in the Session variable that I want to read after the user comes back to the original site, but the session when the user comes back is a new one, not the one I stored the information in.
Why/how is ASP.NET deciding to start a new session (or not remember the old one)? Is there some way to make it behave the way I want?
Well, I've figured this out. The problem is that the authentication site's page does a POST to return to the original site. The ASP.NET session cookie has SameSite=Lax, so a cross-site POST like this won't send it. Since ASP.NET doesn't see the cookie, it creates a new session and associated cookie, overwriting the original one.
The solution (or a solution, anyway), is to mark the cookie as SameSite=None and Secure, which I did by adding the following to my Web.config:
<sessionState cookieSameSite="None" />
<httpCookies requireSSL="true" />
The first line makes the session cookie SameSite=None, and the second line makes all cookies to Secure.
I have a very strange behaviour on my production server that only happens a few times during a week. On a form login POST a redirect is sent to what looks like a cookieless URL like:
"/(F(kD5qGnK-0b5L80VYgScenFuCnjQsLR67HhXq-BWXS1hL45hhqL8AiLlEyB-9CuJgutiyXzN42w8Bo_cm2o73GFWP_fuQ1AtPfXSaB7odZYAOBnuNW3Yy873fQDpRzYgOVo3Ee48gaCbS7FUIyOBA3CksCTZ3N6YCZ7pcZylZEo01))/SiteSpecificPath/CMS/edit/"
What normally happens is a redirect to just "/SiteSpecificPath/CMS/edit/".
This in turn leads to a redirect loop going back to the login.aspx page and continuing like that.
I don't want to use cookieless so the question is how this is triggered? And is there a way to disable this behaviour? I have looked through all levels of config files and cookieless is set to false on all places.
The site is an EPiServer CMS site, but in this case it seems to be related to a normal asp.net forms login procedure that for some reason triggers a switch to cookieless URLs.
I have found some references about cookieless triggering a redirect loop, but in my case the strange thing is why it even starts using cookieless URLs in the first place.
I have also done debugging using advanced logging to see all headers sent from the browser, but I don't see anything strange there. Cookies are sent as normal, including the ASP.NET session cookie.
EDIT: This is not an access problem. A given user can normally login, but sometimes this redirect loop is entered.
Some details: IIS7 on Windows Server 2008 R2, EPiServer 6 R2, ASP.NET 4
Possibly the user doesn't has access to the redirect URL and this is why it redirects everytime to login page and continues like that.
Firstly check if the user is authorized to access the page in the redirect url.If the user isn't authorized, redirect to a page that the user can access Or update the access rights for the user.
I don't want to use cookieless so the question is how this is triggered
When using FormsAuthentication, Check your Settings for same in web.config. As seen below this has a property cookieless which can have options as AutoDetect,
UseCookies, UseUri, and UseDeviceProfile.
<authentication mode="Forms">
<!-- Detailed configuration options -->
<forms name="MyForm"
loginUrl="Login.aspx"
timeout="30"
cookieless="UseCookies"
... />
</authentication>
So, in your case the value for cookieless seems to be either : UseUri OR AutoDetect, although UseDeviceProfile is possible too.
UseUri:If this configuration option is selected, cookies will not be used for
authentication. Instead, the runtime encodes the forms authentication ticket
into the request URL
AutoDetect:Results in the use of cookies if the client browser supports cookies. Otherwise, URL encoding of the ticket will be used.
UseDeviceProfile :: Results in the use of cookies or URL encoding based on a device profile configuration stored on the web server. These profiles are stored in .browser files in the c:[WinDir]\Microsoft.NET\Framework[Version]\CONFIG\Browsers directory.
Since you don't want to use cookieless, set the value for cookieless to UseCookies.
NOTE: When using the setting cookieless="UseCookies" , requires the client browser to support cookies. If the browser does not support
cookies, forms authentication will simply not work. As
it will never receive a valid authentication cookie from the browser, ASP.NET
redirects back to the login page over and over again, and you end up in an
endless loop of presented login pages
In asp.net, I am able to login using forms authentication as usual, copy our auth cookie value, log out, add the cookie artificially to the client using the 'Edit This Cookie' addon for Chrome, refresh the (anonymous) landing page and hey presto i'm logged in again. This seems to be a vulnerability - is there any way of fixing it using the the standard forms auth or will I have to do something like use a custom Authorize attribute which overrides the existing one in asp.net mvc?
I don't think this is a bug per se. The following happens during forms authentication
You provide a username/password to the server
Server validates username/password
If valid, the server then sends an encrypted authentication ticket (cookie) to the client with the expiration time (set in the web.config forms authentication section) and username (all encrypted)
On each request that requires authorization, the cookie is decrypted on the server, expiration time is checked and username is used to see if authorized (or getting that role for the requested resource).
When you logout, the expiration time on the cookie is set in the past, therefore, it is not longer a valid cookie
Now, as to why you are seeing what you are seeing... You are copying the cookie before you logout. Thus your copied cookie never registers the logout (moved expiration time). When you reattach, you still have a valid auth cookie. Now, if your forms authentication timeout is set to...let's say 20 minutes...this method would fail if you copy the cookie and wait 21 minutes as by that time, it has expired.
Cookies are always vulerable and we can't do much about that. What we can do is prevent someone from stealing the cookies.
Regarding ASP.NET MVC it does a good job to avoid stealing cookies. Some of the main things it does by default as part of security are:
Encode the strings that are rendered to the view (if you are using Razor don't know about others) to prevent from XSS attacks.
Request validation (stop potentially dangerous data ever reaching the
application).
Preventing GET access for JSON data.
Preventing CSRF Using the Antiforgery Helpers
Regarding cookies Microsoft provides HttpOnly feature and this helps to hide the cookies from javascript. The Forms authentication that you are talking about is a HttpOnly cookie means someone can't steal that through JavaScript and it's more safe.
You can do that with any cookie/s. You can inspect/copy all the cookies from any given domain, and spoof if you want. You can do that to yourself (only) because its your PC (or user logged in to PC). Obviously if you're on a shared PC, that is a problem (across all your info).
The act of "copying your cookie" is in fact one way malware attempts to steal/hijack your identity (or current session on some web site). That said, unless you have some malware, you can't just "copy cookies" of someone else.
Assuming logout is done, you can ask users to close their browsers so the expired cookie is removed from the (file) system.
In my ASP .NET web application, when I first navigate to the login page, I do not see a Set-Cookie header coming back in the response from the server. I expect to see one that looks something like:
ASP.NET_SessionId=efypn5ihkam3pdcuucmbykvi; path=/; HttpOnly
Here is my sessionState config entry in the web.config:
<sessionState mode="InProc" cookieless="false" timeout="480"/>
I've cleared my cookies in my browser, then navigated to the login page. No Set-Cookie. After I log in to the application, it does send a cookie back for session tracking.
Other apps I've built work fine...this one is giving me trouble. Any ideas?
Usually, the session state isn't started until you create your first session state variable, which usually begins with authentication (after logging in). Unless your deliberately creating a sessionstate variable on the login page request, you shouldn't see one until you actually log in.
I had this problem that when I signed in with local host iis there were no problem but when I signed in with my site the session cookie and login cookie was not set.
The problem was in web.config that I hadn't sync that with my webserver.
I've got an asp.net application which seems to forget that a user is logged in after a while.
I'm using the membership provider and when opt to "remember" the log in it remembers it during the session. I can even close the browser, restart and come back and it will still be logged in. But after a while it forgets and it seems to do it at any old time. I've once been logged in and when I went to a new page it was logged out.
The other strange things are:
On my development machine it remembers the log in forever. Even after IIS restarts and recompiles it will remember my login as expected.
I have another application on the same server that does remember the login forever. I compared how they handle login and they seem to be identical.
This leads me to believe that the issue has something to do with the server or perhaps something in the application not directly related to the login and membership code. What could I look at?
Edit:
Looked up the cookie using Fiddler and they seem to be ok.
An Authentication cookie created today expires 2 weeks from now, which is how my config is set up:
expires=Mon, 06-Sep-2010 01:47:51 GMT
Edit:
The problem seems to be that the app pool is recycling and the authentication cookie becomes invalid because it can no longer be read as the machine key has changed. The solution was to add a machineKey segment to the web.config and supply a static machine key.
There are two major possibilities.
Cookie expiration. If the cookie expires / goes away, then you are considered logged out.
Cookie invalidation. Login cookies are encrypted based on the machineKey value. If you do not specify a machineKey, a new one is regenerated each time the application pool starts up (or is recycled). That means that any login cookie encrypted with the old machineKey is now invalid, and you will not be considered logged in.
Check to see what the recycle settings are on your application pool in IIS and see if that corresponds with the timing of you not being logged in.
"Remember me" functionality is done using cookies. Cookies can be set with an expiration date. You need to look into how the cookie is being set (Fiddler is good for this, you can inspect the HTTP header when the cookie is set.)