We recently updated a site from Classic ASP to ASP.Net 3.5.
The old site used a login system based on cookies.
It would remember the users login information if a checkbox was selected when they first logged in. This would of course be done in a cookie.
We then upgraded the site Using ASP.net.
We transferred the old users to the built in ASP.net Membership Authentication.
It works great except for a really strange occurrence.
When a user logs in to the site, but had the old cookie for the site which stored the login information, the ASP.net Authentication seems to crash.
There is no error message, no information of any kind.
The user tries to login, gets no error message, just gets transfered back to the login page.
It seems to be looking at the old cookie and just doesn't know what to do.
The domain names of the old site and the new site are the same.
This does not occur for new users who have never been to the old site.
If an old site user clears out his cookies in his browser he can log in fine and the error never happens again.
But we have 5000 users, we can't tell all of them to clear out their cookies.
I tried changing the setting in the following line of code in my web.config.
<authentication mode="Forms">
<forms cookieless="UseCookies" loginUrl="~\User\Login.aspx" defaultUrl="~\Default.aspx" timeout="26280000" />
</authentication>
But I'm not sure if it helped or not.
Any assistance would be greatly appreciated.
Thanks
With forms authentication, your login is controlled by forms authentication cookie. So I don't understand how is your old cookie interfering with FAC?
In case you are storing some value in your custom cookie, one way would be change the name of the cookie in your new code. i.e. if the code is creating "CookieA", the same name as old application, change it to "CookieB" and same while reading.
Specify cookies token name:
<forms name=".ASPXFORMSAUTH" ... />
Related
Our company has an old web forms site running. The problem we had was that in web.config the expiration of log in cookie was originally set for a year for some odd reason... We decided to change that to 7 days now.
So I updated the timeout value in web.config. That part is fine.. But the problem is that for users who had logged in before this update and if they had the remember me check box checked.. they are still able to log in with the old cookie.
Is there a way I can force everyone to log in again?
Thanks in advance! :)
If you change the name of the Cookie in the web.config file, the data does not match the one stored on the local computer and the user is invalid and will be required to login again.
<authentication mode="Forms">
<forms name="myNewCookieName" />
</authentication>
Hy, You Can Try This. If It Can Help. I just Found it on the internet so if it can help you
I been struggling with an issue lately. My website which is using forms authentication is behaving pretty wierd suddenly. Once forms authentication is timing out, I can see I'm logged out of my application but for some reason, I'm not getting redirected to the login page. This was working absolutely fine before. Not sure what has happened to it suddenly. I'm using SQL Server to store session state and when I made my application to inProc, everything looks fine.
I even deleted and recreated my ASP.NET Session state database but no luck yet. When I look into Event viewer, I have many entries with the following message:
"Forms authentication failed for the request. Reason: The ticket supplied has expired."
On little search, someone said, this could happen with app pool recycling. I even deleted and recreated my app pool now. But still, I'm not getting redirected to login page.
Can someone help me out here.
Thank you.
For Forms Authentication to actually block access to pages, you need to tell your application under what circumstances to block access.
This will block all users who aren't logged in and cause a redirect back to your specified login page. Place it right after your <authentication> tag for simplicity.
<authorization>
<deny users="?" />
</authorization>
If you want to limit on more specific terms, you can add <location> elements with more detail. See this article for more information.
I've got the following structure
www.website.com --> ASP.NET 4.0 Web-site
www.website.com/blog --> NET 4.0, Web-Application
Both do form-authentication against the same SQL database and use the framework ASP.NET memberships and roles. I can log into each portion just fine (same user/password) but the authentication doesn't carry over i.e. if I log into / and then click a link to /blog/, /blog/ thinks I'm Anonymous and prompts for login again. I've done the basics
i.e.
Identical <authentication mode="Forms"> in both the site as well as app web.configs
Identical <machineKey> section (yes, identical validationKey and decryptionKey)
So I then inspected the cookies generated and noticed that website and the web application seem to be working on different cookies.
Cookies created by website.com/blog
.ASPXFORMSAUTH-27604f05-86ad-47ef-9e05-950bb762570c
.ASPXROLES
Cookies created by website.com
.ASPXFORMSAUTH
I think this is the problem, although I see it despite having identical <authentication> sections which looks like
<authentication mode="Forms">
<forms timeout="30" slidingExpiration="true" name=".ASPXFORMSAUTH" enableCrossAppRedirects="true" protection="All" cookieless="UseCookies"/>
</authentication>
I did read several other posts like
Single Sign On with Forms Authentication
as well as
http://msdn.microsoft.com/en-us/library/eb0zx8fc.aspx
There were also a few other posts I can't recall now. I've gone through them (all?) but am still stuck. I can gladly supply more debug data if needed.
Would really appreciate any tips someone might have! I think I'm hitting a wall on this one!
Ok, so I was able to answer my own question after beating around it for longer.
Basically, BlogEngine.NET 2.5 (my web-app) seems to be overriding the .NET 4.0 framework way of doing things. There are a couple of things you need to fix, all within BlogEngine.Core\Security\Security.cs (download the BlogEngine.NET source code)
Part 1: Fix cookie name
In there is a method FormsAuthCookieName which I changed as follows:
File: BlogEngine.Core\Security\Security.cs
Method: FormsAuthCookieName()
// return FormsAuthentication.FormsCookieName + "-" + Blog.CurrentInstance.Id.ToString();
return FormsAuthentication.FormsCookieName;
This ensures that the cookie names are the same. One hurdle down ...
Part 2: Avoid web-app/BlogEngine.NET's login page/controls/code
Instead of directing users log into the BlogEngine.Net's login.aspx (www.website.com\blog\account\login.aspx), I pointed all login links to my main website's login.aspx page (www.website.com\login.aspx). In case you're wondering how to implement you own site-wide authentication, this is a super-quick guide
msdn.microsoft.com/en-us/library/ff184050.aspx.
I also had to add something like this to both the website web.config as well as the web-app web.config, so anytime a protected resource is accessed (from website or web app) my own global /login/aspx is used.
<authentication mode="Forms">
<forms timeout="30" loginUrl="/login.aspx" blah blah />
</authentication>
Now, my own generic, site-wide user login controls will be creating the (.NET framework standard) authentication cookies and the (user) role cookies. By avoiding the BlogEngine.NET's login.aspx we're cleaner plus we avoid calling this code which is problematic.
File: BlogEngine.Core\Security\Security.cs
Method: AuthenticateUser(string username, string password, bool rememberMe)
Details:That code adds a "blog instance" into the cookie, so so if you have multiple blogs on the same domain, this prevents user1 authenticated on blog instance 1 from NOT being automatically authenticated on blog instance 2. I'm guessing most will only have one blog per domain (www.domain.com\blog!), so this is unnecessary. More importantly, that check breaks our single sign-on.
Two hurdles down ...
Part 3: Fix Per-access authorization check
Now, our site wide, standardized login.aspx doesn't add the specific BlogEngine.NET instance ID (see above). This would have been ok, except that there is still some BlogEngine.NET code that specifically looks for that. We don't need that check either, so lets remove that offending check...
File: BlogEngine.Core\Security\Security.cs
Method: void Init(HttpApplication context)
// Comment line below to revert to only-framework/default processing
//context.AuthenticateRequest += ContextAuthenticateRequest;
So at this point you should have
All logins handled by a single, site wide login.aspx
All authentication cookies and user role cookies created by the above site wide login.aspx
All such cookies encrypted and protected per of both the website & web-app web.configs (which should match!)
Which in turn allows single sign on :) !! Hooray !
In addition: in both web.configs you must insert machinekey with the same validationKey and the same decryptionKey.
I am having trouble with I guess Forms Authentication..
Site runs perfect can login and log out.. but after a while (this is not a specific time frame) suddenly URLs start to look like this:
http://www.mydomain.com/(A(EvoNg_065oCKJ1l_AcU4ND7Uzkm05wugwbYu4jiKb-_24aJmbmE_r5djE-mw9b_3tvEBOLIH1f64rrtq6RZOSFto_o0MaN-3edRpjH2Bfn8uBnrUFhv2xmk4_9oLXHVEt-Dg5BfdPA3VprkCIixmbhr2KPs1))/Default.aspx
What does this encoding (A) mean... is it the authorization ticket or Anonymous user ticket or what is it.
The funny thing is that it stays there and also include the encoding in all links on the page. Until at recycle the application pool for the site... when it is gone..... and it just starts over again after a while....
Anyone to point me in the right direction. Site is ASP.NET 4, using form auth and deployed on a IIS7
Please help...
Best regards
Henrik
This could be related to a cookieless session which you might have configured. Look for the following in your web.config:
<sessionState cookieless="true" />
Also checkout if cookieless Forms Authentication is not enabled.
I am working on two ASP.NET websites. Both use custom authentication process based on forms authentication with:
<authentication mode="Forms">
<forms cookieless="UseCookies"/>
</authentication>
set in Web.config.
When I compile the first website, it always remembers my credentials I've entered before, like expected.
When I compile the second website, each time it forgets completely all credentials I've entered a minute before, and .ASPXAUTH cookie is not here nevermore.
What can cause the second website to do so? Where to start to search for the resolution of this problem?
Perhaps when the 2nd site recompiles some class or other object changes that is stored in the session so the application has to restart the session, but in the first site the only thing being stored in the session are standard .net objects that havn't been recompiled. Is this causing a real world problem, it is fairly usual to lose your session state when you recompile a website, but this does not cause any problems i the wild unless you are updating your live code several times a day and kicking users of the system.