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.
Related
So I have something weird going on and i can not pin down exactly what is causing it. My asp.net project is live with session state on two production servers that are synced using the following command:
msdeploy -verb:sync -source:webserver,computername=%MACHINE%,username=Administrator,password=%PASSWORD% -dest:webserver 2<&1
The application is an asp.net 4.0 website that is run on two Server 2008 R2 web servers behind a load balanced configuration where the users are set to stick to one server once they connect. We have <MachineKey> set hardcoded with validation and decryption keys in the root site of the application and it is the same between both servers. My application is set up to forward exception events to our email system.
What is happening is that i am receiving the dreaded 'Validation of viewstate MAC failed' from the servers but even though the server load is 50/50 split the errors are coming in on a 99/1 split. So one web server is generating these errors considerably more often than the other one. This is strange considering the servers are synced and all configurations are identical.
I've done extensive searching on this problem and it seems quite difficult to find any solution that doesn't mention or do the following.
<MachineKey> is not identical between servers. (I know for a fact this is not my problem)
Setting enableViewStateMac=false or some other setting that jeopardizes the site security.
Make sure that all action tags on form inputs reference the same page they are placed on
Make sure the instance ID of the servers are the same (they are)
If the user clicks through the page before the entire page (viewstate) has been downloaded (my viewstate is set to render at the top of the page).
Issues with response.redirect and server.transfer
Now i have eliminated all except the last two as possible causes. My application has been running fine for over a year with no issues and right before these errors appeared i enabled SQL session state, migrated the project from .NET 3.5 to .NET 4.0, and set the set the server mode deployment mode to retail. I have tried recycling the application pools and performing an 'iis reset' to no avail.
Does anyone else have any suggestions as to what i can look at? Bottom line i do NOT want to fix this by opening up security holes in my site.
It appears this is happening to users right after they authenticate using forms authentication the first time they try to log in but i can not confirm this. I also have a theory that this might have to do with caching but i can't be sure on this either.
Here is the juicy bit from my web.config (i have removed some sensitive information)
<system.web>
<httpRuntime requestValidationMode="2.0"/>
<globalization culture="en-US" uiCulture="en-US" resourceProviderFactoryType="WebResourceFactory"/>
<compilation debug="true" defaultLanguage="c#" explicit="true" strict="true" targetFramework="4.0">
<assemblies>
</assemblies>
</compilation>
<authentication mode="Forms">
<forms name=".ASPXAUTH" loginUrl="Login.aspx" protection="All" slidingExpiration="true"/>
</authentication>
<authorization>
<deny users="?"/>
</authorization>
<sessionState mode="SQLServer" sqlConnectionString="connection" compressionEnabled="true" />
<pages theme="Blue" controlRenderingCompatibilityVersion="3.5" clientIDMode="AutoID">
<machineKey validationKey="key" decryptionKey="key" decryption="3DES" validation="SHA1" />
</system.web>
EDIT:Emphasized that i'm using SQL session state with a load balancer set to prefer to route users to the server they started on.
There is an additional possibility that you have not added to your list - ViewStateUserKey.
I have seen issues with applications where the ViewStateUserKey was set to the Session ID on logon and (crucially) before any data is saved to the Session. Since ASP.NET does not persist Session IDs until one or more objects are saved to session this meant that the ID was constantly changing and the Viewstate was failing validation. Even if you have saved something to Session then the Session will be different on each server if you are using the default in-process model and not a state server or SQL session store (as you are doing). Any server specific value or value that is not readily predictable across servers used with ViewStateUserKey will of course also cause this problem.
Otherwise the most common causes of this issue I have seen is where an "Action" attribute is set on a form that is not the URL of the same page as the form (this catches out developers used to PHP or platforms that do not attempt to abstract away from HTTP), or missing Machine Key attributes in the Web.config in multi-server environments (which you seem to have covered).
Ok i appear to have fixed it, though i can not discern what exactly caused it so i will just list all the steps i performed in case someone else has this problem later on.
1 :
Installed these windows updates:
2:
My forms authentication cookie was set to persistent but my session cookie was set to the browser session. I set my forms authentication cookie to be browser session based.
3:
I copied my from the site config to the root of IIS. From all the documentation i could find it should not be necessary for me to do this because IIS should support multiple machine keys for different sites / applications.
4:
Rebooted the server.
That's it! I have not received the errors since then.
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 am trying to run two web application using the same ASP.NET membership provider database that comes with MVC3. So two web app runs side by side and they both has the same connection to the same membership databse. The problem now is, I can only login at one app and get automatically log out at the other. However, the feature I want is, if I log into either one, I get automatically log into the other.
I was wondering what the trick is to enable this feature.
thanks a lot
If you are using Forms Authentication users are tracked with cookies. Cookies are by default restricted only to the application that emitted them. And because of this the other application cannot see the authentication cookie created by the first. So for example if you have the two applications hosted respectively on foo.example.com and bar.example.com you could set the domain property of the cookie in web.config of both applications to example.com:
<forms
loginUrl="/login/index.mcp"
requireSSL="true"
protection="All"
timeout="120"
domain="example.com"
/>
This way the cookie will be shared among those two applications and you will be able to achieve Single Sign On.
Finanlly I fixed it.
My application runs under the same domain so domain is not a problem (But Thank you very much, Darin).
The problem is:
IIS by default generate differnt machine key for differnt web application. So I have to specify the same machine key in web.config explicitly~!
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" ... />
I have an aspnet webapp which has worked very well up until now.
I was recently asked to explore ways of making it scale better.
I found that seperation of database and Webapp would help.
Further I was told that if I changed my session providing mechanism to SQLServer, I would be able to duplicate the Web Stack to several machines which could each call back to the state server allowing the load to be distirbuted better.
This sounds logical. So I created an ASPState database using ASPNet_RegSQL.exe as detailed in many locations across the web and changed the web.config on my app from:
<sessionState mode="InProc" cookieless="false" timeout="20" />
To:
<sessionState mode="SQLServer"
sqlConnectionString="Server=SomeSQLServer;user=SomeUser;password=SomePassword"
cookieless="false" timeout="20" />
Then I addressed my app, which presented me with its logon screen and I duly logged in.
Once in I was presented, with a page that was not with the page I was expecting.
I can change the sessionstate back and forth. This problem goes away and then comes back based on which set of configuration I use.
Why is this happening?
Nice error Dude :)
Probably a red-herring, but what are you storing in Session state?
When you move from InProc to SQL Server, the stuff you store in SQL must be Serializable (I think)
Use Fiddler to see what's really going on over the wire. To me it looks like your app is sending back an image when the browser is expecting HTML.