I have a login cookie for www.mysite.com and several sub-domains, eg.:
www.one.mysite.com
www.two.mysite.com
www.three.mysite.com
In IE only (firefox does not do this) if I log on in mysite.com, it appears as though that cookie is shared across all subdomains (logged in to all sites). If I log on using a subdomain (one.mysite.com), the cookie is not shared (only logged into one.mysite.com).
www.mysite.com and www.one.mysite.com share the same web.config file, and I don't mind them sharing a login cookie (it's the same site with a different url is all), but not across the rest of the sites.
How do I stop IE from sharing the cookie to all or some subdomains?
Can I do this just using the web.config file?
Update:
I'm using membership and role manager in my web.config file. In the above problem I have not set
<authentication mode="Forms"> <forms domain="...
As far as I can see,
<authentication mode="Forms"> <forms domain="mysite.com" ...
can either allow only one domain (www.mysite.com), or all subdomains (.mysite.com). I need a way to allow www.mysite.com and one subdomain. Is this possible?
Can I tell the other subdomains not to accept the .mysite.com cookie?
Normally a cookie set on example.com will be accessed by all of the subdomains. However, if you want to limit the cookie to a specific subdomain, you should manually set the domain property for each domain you want them to access.
Response.Cookies["domain"].Domain = "www.example.com";
Some valuable reading, or More valuable reading... (read: "Limiting Cookie Domain Scope" section), and finally "How to limit cookie for a particular subdomain in ASP.NET"
The answer is that I really have no idea what is going on with the login procedure here.
The other guy who I'm working with is fixing the problem. Apparently it has something to do with the machine key, which needs to be changed on all the other subdomain websites (two.mysite.com, three.mysite.com) except the main one (www.mysite.com).
This is hardly an answer, but if you're stupid like me (don't know enough about ASP.Net logins), and have to deal with IE8/compatibility view and this login problem... Well hopefully it will help someone who doesn't know where to look for an answer.
Related
We have a wild card domain hosted on azure. I've setup up subdomain.domain.com to rewrite to domain.com/subdomain. It all works fine.
However when I login to our identity server, once the login process is completed and I am redirected back to subdomain.domain.com it seems like the authentication token is lost.
I can't see how this can be possible. This issue happens with all our identity providers (google, Facebook, Microsoft live)
If I change the setup to use domain.com/subdomain then everything works as expected
The main issue is what type of cookie your identity server places,
It looks like your server places and domain specific cookie, and not a wildcard one.
Cookie domains
Common issue with the cookie for the authentication is the domain for the cookie. Similarly to the paths of the cookies, if the cookies are created on two different subdomains, then the cookie will only be accessible on the domain where it was created. For instance, your main application may be on www.domain.com, but you have Telligent Evolution running on cs.domain.com. If you create the cookie on www.domain.com, the browser will only send it to that domain, and it won’t be passed along when they navigate over to cs.domain.com.
The cookie can be carried over by setting the domain to “.domain.com”. Cookies don’t use the common “*” wild card. Simply use “.domain.com”. With this entry, the browser will not to pass the cookie when it goes over to cs.domain.com as well.
Like the path, the domain can be specified in either the web.config or through code. When setting the web.config file, it will only check for the authorization cookie. You must have this set for the site to correctly recognize the new domain level cookie:
<authentication mode="Forms">
<forms name=".CommunityServer" ... domain=".domain.com" />
</authentication>
The "domain" name is ignored by the FormsAuthentication.SetAuthCookie method, so you must manually set it on your login page when creating the AuthCookie. For example:
HttpCookie cookie = FormsAuthentication.GetAuthCookie(username, true);
cookie.Domain = ".domain.com";
Response.Cookies.Add(cookie);
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
I've run into a problem and I'm not sure how to go about fixing it. Here is the scenario.
A user visits my website (www.MyWebSite.com) and clicks on a button that puts a cookie on their computer. If I examined that cookie on their machine it would list the "host" as www.MyWebSite.com.
If the user then changes the URL in their browser to MyWebSite.com (without the www) reloads the page and then clicks on the button, a brand new cookie with the same name as the first cookie is created. The host of this cookie is MywebSite.com
Obviously this is not good - beside two cookies with the same name, only the cookie with the corresponding URL address is being read by my program.
Can I force cookies to be created with the www host and/or can I force the page to be www or what??? What and how is the best way to prevent this problem?
Cookie Creation using VB.net
Response.Cookies("AAA")("bbb") = strABC
Response.Cookies("AAA").Expires = DateTime.Now.AddDays(1)
Any help is greatly appreciated.
For (obvious) security reasons you can only read cookies that are set by the same domain the user requests. It doesn't matter if it is just a difference like in your example, or an entirely different domainname.
What you could do in this situation (it should improve your SEO as well), is redirect (301) all traffic from the site without www to the site with www.
If you're using IIS 7 or higher, you can find an example on how to do that with URL Rewrite here: http://weblogs.asp.net/owscott/archive/2009/11/27/iis-url-rewrite-rewriting-non-www-to-www.aspx
That's for security reasons. Any subdomain of a host is considered to be another realm, another world.
If you want your cookies to be sent to your subdomains too, then start the Host attribute of the cookie with a .. In other words, set your cookie for .MyWebSite.Com.
See Wikipedia for more information.
Per a question I posted yesterday, our website's DNS structure has changed to round-robin DNS which literally swaps back and and forth between two production servers. Our web.config for both prod servers has:
<sessionState mode="SQLServer" ... > pointing to the same shared DB
A machineKey on each server that is consistent between the two (this was the main point of my post yesterday).
[update] The same domain in the <forms domain=".mydomain.com" ... > tag
When we use the login feature on the site, the login actually makes a web service request to a 3rd website that authenticates a user. If the resulting response says it was a successful login, then we use FormsAuthentication to log the user in:
FormsAuthentication.SetAuthCookie(strUserID, true);
Our issue is that on some pages we see we are logged in, others we're not. Is this something indicative of either us not completing a final step to share session between two prod servers or could our SQL server session DB be broken?
Thanks in advance
UPDATE:
Our code to determine if the user is logged in is quite basic:
HttpContext.Current.User.Identity.IsAuthenticated
UPDATE 2:
When I hit prod1.mysite.com (or prod2.mysite.com) I get a cookie called "ASP.NET_SessionId" but when I hit the live public URL, www.mysite.com, I don't get this cookie. Is this part of the problem?
RESOLUTION:
It turns out that everything we did here was all correct and that our live site which uses Akamai was being cached in various states due to Akamai's cache configuration. Sharing your logged in state between servers has been confirmed to work.
One thing you could do is use the Firebug add-on for Firefox to ensure that the authentication cookie is being sent to the browser as expected after logging in although as you are seeing that you are logged in on some pages I would expect this to be the case.
Another thing to check would be that the domain is set correctly for the authentication cookie and that it is valid for all pages on your website.
This is typically set in you web.config in the forms tags, example below and should be same on each server in the web farm.
<authentication mode="Forms">
<forms name="yourAuthCookie" loginUrl="/login.aspx" protection="All" path="/" domain="mydomain.com" timeout="30"/>
</authentication>
If this is all correct then it is possible that session is not being shared correctly between your servers although the settings that your have described in your question appear to cover what is needed.
I have two domains, domain1.com and domain2.com pointing at the same asp.net website which uses asp.net build in form authentication. The problem is that even if the domains point to the same website the user only get authenticated for one domain at a time. So if he uses www.domain1.com first and then visits www.domain2.com it's the same website in the back but he only is authenticated for www.domain1.com. The same thing happens if he uses www and not www when visiting the sites.
This is what I use to login:
FormsAuthentication.RedirectFromLoginPage(username, cookie.Checked);
To check login:
User.Identity.IsAuthenticated
How can I make the user gets authenticated for all domains that points to the same website?
What you're after is a Single Sign-on solution.
As ASP.NET authentication is at it's heart generally cookie based, there are two things to look at:
Set your cookies correctly.
Bounce your users to the alternative domain during signup.
Looking at both of these in more depth:
1. Setting cookies correctly
You need to ensure that ASP.NET is writing the authentication ticket cookies to the root domain, rather than the explicit domain this is done using the domain attribute of the forms element:
<forms
name="name"
loginUrl="URL"
defaultUrl="URL"
domain=".example.com">
</forms>
You should set your domain to ".example.com" - note the leading period - this is the key. This way requests to example.com and www.example.com will both read the cookie correctly, and authenticate the user.
2. Bounce users to the alternative domain
What we have implemented on a few sites that use a single sign on is a round trip login process. The user authenticates on the first domain, we encrypt the login details, and redirect them to a known page on the second domain, log them in there, and then redirect back to the original server.
This client side redirection is important - cookies are only written when there is a response back to the client, and the browser has to visit the second domain to actually see the cookies.
Other details to consider in this sort of set-up:
You probably want to have a timeout on the encrypted sign-in details - so that recalling that URL from the browser history doesn't automatically log the user in.
If the domains are on different servers, you will need to ensure that either the machine keys are configured the same, so that you can encrypt and decrypt the details correctly, or use some other shared key.
You will probably want to have a mechanism in place to recall the users ReturnUrl from the original server so that you can send them back to the correct place.
You could also take a look at "Forms Authentication Across Applications"
You could try setting cookieless="true".
You should read Explained: Forms Authentication on MSDN. They cover Cross-Domain Authentication.