I have a pair of websites I am building in Asp.Net. In development, they are both on my machine. One is hosted in IIS and one is in IISExpress. I have configured both websites to use FormsAuthentication, and set the same authentication and httpCookies elements in each web.config:
<authentication mode="Forms">
<forms loginUrl="~/LogOn" timeout="2880" domain=".mydomain" />
</authentication>
<httpCookies domain=".mydomain" requireSSL="false"/>
However, after a standard FormsAuthentication.SetAuthCookie , the second site cannot read the .ASPXAUTH cookie from the first. It CAN read the same Asp.Net_SessionID cookie from the other website. So, one cookie is being passed across applications, but the second is not.
Additionally, when the debugger is attached to the second application and it receives the redirect from the from the first site, the Chrome debugger shows both cookies, Fiddler reports that both cookies were transmitted, and the Response.Headers["cookie'] contains the .ASPXAUTH cookie.
How can I effect this cross-application sign-on? In production, these two sites will answer on separate sub-domains.
I've found the answer to my problem.
IISExpress and IIS use separate MachineKey values, even though they are originating on the same physical machine. To solve my problem, I generated a MachineKey entry at http://aspnetresources.com/tools/machineKey and dropped the same MachineKey element into all participating application's web.config files.
Thanks to Robert Smith #smithrobs on Twitter for suggesting I check this line of the problem.
Related
I am working on an old application that uses Forms Authentication and I'm trying to get it working locally as a web site in Visual Studio 2012. It seems to run OK using the internal debugger on http://localhost:54006/. Images, html, etc are served out. Unfortunately with login, I think there is some cookie issue that is preventing it from thinking I'm logged in. I noted that in the web.config there was the wrong domain set. I've changed that to read localhost, but I still haven't had any luck.
<authentication mode="Forms">
<forms loginUrl="/" path="/" slidingExpiration="true" timeout="480" name=".ASPXAUTH_ADD" domain=".localhost" enableCrossAppRedirects="true">
</forms>
</authentication>
Does that setting look okay for running this from Visual Studio at http://localhost:54006/? It does not complain about a bad username or password. It works in production with a different domain attribute set. Is the correct domain attribute for localhost ".localhost"?
Thanks in advance for any help or guidance.
EDIT: I was able to get it working by simply removing the domain attribute rather than trying to set it. Why does that work?
"Gets the value of the domain of the forms-authentication cookie." "The default value is the current domain."
the msdn example gives the value "contoso.com."
looks like a good top answer here (more detail).
another (similar) answer here.
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 am working on several asp.net sites simultaniously. All of them use cookie-based (out of the box) authentication mechnism. When a web site on localhost:4587 was being bedduged in VS I have logged in as an "admin" user and did some testing.
The next day I am opening different project for debugging that runs on localhost. And when I attempt to access the MVC controller action that is marked with Authorization atribute, the system assumes the current user is "admin" and is looking for it's roles based on a custom provider. But on this site, there isn't even a user named "admin". How can I make sure cookies from other sites don't make it to Role check in ASP.NET MVC application?
I would suggest it is always a good practice to delete all localhost cookies after testing. As explained here : asp.net cookies, authentication and session timeouts , you can also add details to the authentication cookie to ensure it is discarded after a session, ie when you close the browser or to differentiate between two sites. Another approach to avoid cookies 'clashing' is to use two different browsers : Chrome for the one and a Comodo Dragon or Chromium for the other.
Give your forms tag a unique name in each application
<authentication mode="Forms">
<forms name="myVeryUniqueNameForApp1" />
</authentication>
<authentication mode="Forms">
<forms name="myCompletelyUniqueNameForApp2" />
</authentication>
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've converted a web site to a web application and am now experiencing a strange behavior with the application. Essentially, there are 2 webs. One web site is the main, front-facing site written in ASP.NET 1.1 but with the Membership piece added from 2.0. The other is a former web site now grown up to a web application.
It seems as though when I login to the web site (project 1), I get properly redirected to the web app (project 2) properly. However, any link I click on sends me back to login on the web site (project 1). The machine keys are the same and all of the forms authentication properties are the same.
I've stopped IIS several times and deleted the files in the temporary folder and still no go. Very frustrating.
Here is an example of my forms element for my web app:
<forms domain="beta.domain.com" name=".ASPXAUTH" loginUrl="http://beta.domain.com/" protection="All" timeout="600" path="/" requireSSL="true" slidingExpiration="true" defaultUrl="https://beta.domain.com/app/" enableCrossAppRedirects="true"/>
Here is an example of my forms element for the web site:
<forms name=".ASPXAUTH" enableCrossAppRedirects="true" timeout="600" defaultUrl="/QueryStringAuthenticate.aspx" loginUrl="/" protection="All" slidingExpiration="true" cookieless="UseDeviceProfile" domain="beta.domain.com" />
Then on both I have the same machine key value specified. The QueryStringAuthenticate.aspx page in the web site hasn't changed. It still does the same thing it always did (obtain the cookie name [.ASPXAUTH] and cookie value [authentication token]).
I finally got it. It actually had nothing to do with the authentication itself, but rather the browser settings. Apparently, someone had modified our image file for dev machines to add the site in the trusted sites for HTTPS, but did not add it without the HTTPS. So, IE was dropping the connection somewhere. Either adding both with and without the HTTPS or removing those entries resolved the issue.