For the last couple of days I'm trying to resolve a problem in my MVC 5 web application related to the anonymous identification module.
I enabled the anonymous identification by adding the following line to Web.config:
<anonymousIdentification enabled="true" />
The problem is that the cookie used by the module changes every time the browser sends a request:
.ASPXANONYMOUS=6yylwpA5baKlbP-ntBra3pA1vr1y5kXp...
After refreshing the page the cookie changes to:
.ASPXANONYMOUS=s3-AlVJNimP5NrDI1PLWc8RK720RTeNY....
And so on and so forth.
What's interesting is that anonymous identification works perfectly fine in our test environment and keeps the value of the cookie consistent across multiple requests. But deploying the same code to production results in this strange behavior, so I suspect a configuration issue in IIS. Both environments use IIS 8.5.
Any idea what I'm missing here?
You have likely moved on but I noticed this while in development on some MVC5 applications.
If you use a valid hostname / domain / IP and not 127.0.0.1, it shouldn't recreate the .ASPXANONYMOUS cookie every request.
On a side note, you can do a lot of edits to the anonymous cookie by applying attributes to the configuration.
For example, the following would only set the anonymous cookie for an hour:
<anonymousIdentification
enabled="true"
cookieName=".ASPXANONYMOUS"
cookieTimeout="60"
/>
Link to documentation on the anonymousIdentification element for more info.
Related
I am working on MVC framework in ASP.NET where, I was trying to access the application but I was not able to go past the login screen, after which it kept throwing the not found IIS error. After workaround i found that i had this line : httpCookies httpOnlyCookies="true" requireSSL="true" in my web.config file which was stopping the access. Can anyone help me understand the problem and concept here?
Thanks already.
I was able to access the site after removing the requireSSL part only.
Web-config
httpCookies httpOnlyCookies="true" requireSSL="true"
Global.asax's Application Start :
if (ServicePointManager.SecurityProtocol.HasFlag(SecurityProtocolType.Tls12) == false)
{
ServicePointManager.SecurityProtocol =
ServicePointManager.SecurityProtocol | SecurityProtocolType.Tls12;
}
I think the part of code in global.asax's Application Start might be causing the problem, but I'm not sure about it.
Websites use cookies to store information between page requests or browsing sessions.
The callback from an external provider to your site contains security tokens(httpCookies) that allow access to your site and contain user information.
If someone manage to steal other's authentication cookie for a website, he could carry out all the actions that they are capable of.
Transmitting this information over HTTPS to prevent interception while this information travels over the Internet is important
You can stop script access to all cookies in your site by adding a simple flag: HttpOnly. You can set
this flag in the web.config, as follows:
<httpCookies domain="" httpOnlyCookies="true" requireSSL="false" />
So If you write requireSSL="true" in your Web.config It Enforcing the external provider to make their callbacks to your site using HTTPS only.
#Vishesh Pandita In your case you are trying to access site using HTTP only. So faced "HTTP Error 403 - 403.4 Forbidden: SSL required" error.It means the page you are trying to access is secured with Secure Sockets Layer (SSL).
Solution:
To view the page, you must enable SSL (Secure Sockets Layer) by typing "https://" instead of "http://" at the beginning of the address you are attempting to reach. The "s" in "https" specifies a secure site.
Migration for HTTP to HTTPs
source : Professional ASP.NET MVC 5
Is it possible to use ASP.NETs session state with URL like
http://myserver/somesite?sessionKey=thekey
The problem is, that I have to write a site for a client software which authenticates a user by a request like
http://myserver/somesite?user=xyz&passwd=xyz
The client expects than to get a session key as result if the authentication was successful.
This session key will then be used as variable in the query as shown above. The client does not support cookies.
How can I implement this behavior by using ASP.NET MVC 4?
P.S.: I know it is absolutly not the way to go but I am not in position to change the client.
If I do understand you correctly, you could just try it, right?
(We already met it, and it was a pain for searching engines)
<sessionState mode="InProc" timeout="5" cookieless="true" />
And I can say it is working
The url generated instead of
"http://server/Product/en-GB/MyEntity"
is now:
"http://server/Product/(S(rxavnpuw05o3fmy3tjnuystr))/en-GB/MyEntity"
I have two servers: STS and Web. On the STS server, I call:
FormsService.SignIn(model.UserName, false);
The next line, I check:
User.Identity.IsAuthenticated
This is set to TRUE. Then I redirect back to my Web server and in the controller I hit, I check:
User.Identity.IsAuthenticated
This is set to FALSE.
What could cause this?
UPDATE: I also just tried moving the STS web site to the Web server. I get the same error/issue
UPDATE: I forgot to mention that our DEV server works just fine. The configuration there is identical (except for the server name and cert thumbprints). The only thing different between these two servers is that one (DEV) is using a self-signed cert and is inside our firewall. The other (QA) is using an official (thawte) cert and is ourside our firewall. This cert's common name does not match the server name (so it can be shared in our farm). So when we access the site, we do so using https://[commonname].com/web as opposed to https://[servername]/web. I tried the latter approach (I get cert errors that there is a name mismatch) but still have the same result.
Also, I can access the STS site directly and login fine there.
ASP.NET authentication is based on cookie by default. Cookie lives inside web domain.
So if you have two servers installed like this:
http://www.web.com
http://www.sts.com
WEB server cannot read cookie set by STS
There are two possible solutions:
Implement both servers as sub-domains
Store authentication ticket in URL instead of cookie
For option 1
Move servers as follows:
http://www.web.yourdomain.com
http://www.sts.yourdomain.com
Update web.config to scope cookie to yourdomain.com:
<authentication mode="Forms">
<forms domain=".yourdomain.com"/>
</authentication>
For storing ticket in url check this article - http://www.codeproject.com/Articles/2796/Cookieless-ASP-NET-forms-authentication
Update: Seems that I did not get that STS stands for Security Token Service. My answer is not relevant. :(
While redirecting from your STS server you will have to redirect using the AutoPostform which will submit the token to the Relying party.
And when Relying party will receive the token it will create the cookie against that user.
So next time whnen you will check User.Identity.IsAuthenticated at Relying party it will return you True.
Go throung the following link to know more,
http://chris.59north.com/post/2013/03/27/Claims-based-identities-in-ASPNET-MVC-45-using-the-standard-ASPNET-providers.aspx
We had the same issue when moving the RP to a different server. It turns out that we needed to go into the application pool -> advanced settings -> Set 'Load User Profile' = true.
After that, everything worked as it should on the new server and User.Identity.IsAuthenticated was returning 'true' after it came back from the STS.
Well I'm totally stumped on this one. Here is the scenario
asp.net mvc3 web application, has been working fine for quite a few months, but I have been going through patches and new releases weekly or so with new functionality. The codebase itself runs on two separate iis7 windows r2 servers. One of these servers, I dont use the standard app pool identity (network service) - I have a specific user, since it pulls some files off a file server, and hence needs specific rights too add/delete from that directory.
On this server, its just started to act crazy with forms authentication 99% of the time in IE9, once or twice I've got to do it on chrome, but chome/ff usually behave themselves no problems.
The problem is as soon as you log in, and go to another page, it keeps responding with a object moved, and redirecting to the login page again. (Sometimes it even does this on logging in) However the session is still valid, because as part of the template, it shows menu items that are based off having the user authenticated, with calls like
Context.User.IsInRole(xxxx)
Request.IsAuthenticated
I've fiddled it, and cookie sessions seem to be fine, everything is being set as it should.
However, if I do a complete iisreset, ie9 will work for about 5 minutes, then it just fails for every request, and redirects back to the login page.
I'm not using iframes at all in the web application, and my web.config settings are
<sessionState mode="InProc" timeout="80" />
<authentication mode="Forms">
<forms loginUrl="~/Account/LogOn" timeout="40" slidingExpiration="true" cookieless="UseCookies" />
</authentication>
Time sync has been checked, and both client(s) and server are within 1 second of each other.
So at this stage, I'm stuck, I don't know where to go to troubleshoot further, or anything else I can try. I can remotely debug the server, if need be.
When I test locally on my dev box, I'm not seeing any issues.
Thanks,
Cameron
Problem solved. I had the number of worker processes set to 2 for the app pool, and hence it was a lucky pot dip as to which of the 2 worker processes had my validated form cookie/session.
Changed back to 1 and the application works as expected. However I'm going to completely rewrite my session handling and store in a db, so I can increase this worker processes to 4 or so to make the app more efficient.
If you are using FormAuthenticationTicket, check below.
FormsAuthenticationTicket authTicket = new
FormsAuthenticationTicket(1, //version
username, // user name
DateTime.Now, //creation
DateTime.Now.AddDays(5), //<--- THIS Expiration
remember, //Persistent
userdata);
We're in a period of moving all our applications to sub-domains of the same primary domain.
Once this is done we aim to move our entire set up to a Single Sign-On system. Currently, we use Forms authentication and set a cookie containing an encrypted token when the user is successfully logged in.
When it comes to setting this up for SSO - is it simply a matter of changing the domain to which the session cookie(s) are set? Or are there other matters that need addressing for this to work.
Set the Machine key in the system.web section of your we.config's to the same value, get that from your IIS config:
<machineKey validationKey="<from IIS>" decryptionKey="<from IIS>"
validation="SHA1" decryption="3DES" />
Then all the sites will see the cookie as valid. The domain names in your section should be subdomains, I think. Well, it works when they are subdomains, don't know what it will do if the actual domain names are different.