I have a web site. URLs com/default.aspx form should appear. But when I click on the URL (com/(S (the hito5tqogutqn21tcn2mozjrr))/default.aspx) as it seems. How do I fix it. URLs with a random number itself is changing.
Check this: https://msdn.microsoft.com/en-us/library/aa479314.aspx
This is happening probably because (unless, you have specified explicitly to use the uri for session id management, which I think, is not the case) the browser does not allow cookies (either for your web site or for all) and Asp.Net detects this and appends the session id to the uri because otherwise your site would not be able to support sessions.
In fact, this is the most secure approach, allowing session state to be available even if the user had disabled cookies.
You can change this behaviour by specifying the following in your web.config file:
<system.web>
<sessionState cookieless="UseCookies" />
</system.web>
After that, you will not see the session Id in the Uri, but users whose browsers do not accept cookies from your web site will not be able to have a session state.
At this point, defining a privacy policy for your web site might help your cookies to be accepted by the browsers:
https://msdn.microsoft.com/en-us/library/ms178194.aspx
Related
not sure if I'm going crazy, but I am having issues with session state inside an iFrame. Its a simple setup of one domain inside another. I dont need to share anything across the domains, all I want to do is embed a website inside another website and I want that embedded site to be able to log in / edit / update / etc using cookies / session state.
To remove all the complexities of server farms / shared sql session state etc, I created a simple html page served up by IIS that simply has an iFrame tag inside of it that call my site. All loads and is great, but the moment I try and log in, I get stuck in an endless loop of log in screens as the session is re-created with each request and I get logged out etc...
What am I missing? was there some uber browser security upgrade that cam into effect recently?
Any guidance would be awesome.
PS. I've got the p3p headers in place
Just for those experiencing the same pain as me, it turn that a cumulative update from microsoft changed the default cooke behavior from SameSite=None -> SameSite=Lax.
https://support.microsoft.com/en-us/help/4533013/kb4533013-cumulative-update-for-net-framework
to fix and I believe this is just a temporary workaround ( Message in Chrome console -> A cookie associated with a cross-site resource at was set without the SameSite attribute. A future release of Chrome will only deliver cookies with cross-site requests if they are set with SameSite=None and Secure. You can review cookies in developer tools under Application>Storage>Cookies and see more details at and ), is to add this to your web.config
<sessionState cookieSameSite="None" ..other attributes here.. />
I created a project using asp.net mvc 5.1, asp.net identity 2.0. After I deploy it to IIS, when I go to secure page 'https://www.xxxx.com/Account/Login', after login, if I go to https://www.xxxx.com. Request.IsAuthenticated return true on _LoginPartial.cshtml page, but go to http://www.xxxx.com, always return false.
It sounds like you may have the option set to only send the authentication cookie over HTTPS, therefore if you navigate to a page over HTTP, the authentication cookie is not sent and the application believes you to be unauthenticated.
The setting in question is requireSSL in the system.web/authentication/forms section
<authentication mode="Forms">
<forms name="auth" loginUrl="~/login" requireSSL="true" />
</authentication>
and this controls whether the secure property is used on the authentication cookie.
Since you are using HTTPS, I would recommend preventing the site from being navigated over HTTP.
RequireSSL will only allow the cookie to be transferred across https. In case you have this specific requirement then you need to take additional precaution in the code.
But beware, of what you are doing at this point.
You can use Request.IsSecureConnection at appropriate place. This could be in the module or in the base class on or in the filter.
An out of dated article is here, but can serve as a pointer.
http://r2d2.cc/2011/08/05/how-to-switch-between-http-and-https-in-asp-net-mvc2-and-allow-ajax-requests-from-site-master/
Caution: Use with care, as you may need to take additional precaution on the server to avoid hijacking.
I have an MVC 3 application that services requests on two different domains. Requests to firstdomain.com come from an iframe, requests to seconddomain.com come from a normal browser window. I need to use cookieless session in the iframe, but want to keep cookie-based session in the normal browser.
Normally the session type is determined in the web.config by setting the following:
<system.web>
...
<sessionState cookieless="UseUri"/>
...
</system.web>
But this applies to every request regardless of the domain. It would be possible to have two copies of the site on the server, one for each domain, and each having a different value for the sessionState cookieless setting, but I would like to avoid that for a number of reasons. Is there a way to toggle this feature depending on the domain of the request while running a single instance of the web application?
You could split the two into separate projects, each with their own web.config. That is one thought that would be better than two separate instances running.
Just out of curiousity, why cookies? Cache or Session would plausibly be better.
We're currently having an issue with cookieless sessions in ASP.NET, according to the documentation on MSDN here when you use AutoDetect:
ASP.NET determines whether the requesting browser or device supports cookies. If the requesting browser or device supports cookies, AutoDetect uses cookies to persist user data; otherwise, an identifier is used in the query string. If the browser or device supports cookies, but cookies are currently disabled, cookies are still used by the requesting feature.
Notice the query string part! Now if it were indeed added to the URL like &sessionId=yoursessionidhere it's all fine but actually what I get are URLs like this: http://yourserver/folder/(session ID here)/default.aspx.
So my question is: How would I configure ASP.NET to use the querystring (as it claims) instead of this URL defacing method?
UPDATE:
I'm adding the config value we use in our web.config:
<sessionState mode="StateServer" stateConnectionString="tcpip=127.0.0.1:42424" cookieless="AutoDetect" timeout="20" />
Reading this resource here http://forums.asp.net/t/1480365.aspx/1 do you have the cookieless="UseUri" setting in the web.config - try deleting that from what I gather it may help! Do let me know!
Additionally it would probably be worth posting your config block in the question.
Ive done some more digging and found this post which covers the request handling in the source code for MVC - using the session id in the URL for routing looks to be baked in pretty deep - see the excepted answer code blocks Possible Bug With ASP.NET MVC 3 Routing?
I'll keep looking for you but this one has me stumped! I think you need to get this question in front of someone like Hanselmann, Haack or Skeet.
My site has the following url format: www.mysite.com/Display.aspx?ID=128
However most users see the url as
www.mysite.com/Display.aspx?ID=128&AspxAutoDetectCookieSupport=1
How can I avoid &AspxAutoDetectCookieSupport=1 from appearing in the url.
Is it to do something with cookie in web.config, but where? And what would be the implications if I remove that. How to remove?
Session State and Forms Authentication can both be set up in the web.config file to operate without cookies - this is called "cookieless configuration". When this happens, ASP.Net can be set to try to compensate for lack of cookies by using the query string as a cookie substitute. This is what is causing your unwanted querystring parameters.
You should look in your web.config for "cookieless = AutoDetect" or "cookieless = UseUri".
Changing the setting to "cookieless = UseCookies" will ensure that the cookieless feature will not be used, and hence it won't be appending the AspxAutoDetectCookieSupport to your URL.
The implications of this is that users who browse with cookies turned off will not be able to have Session data or use Forms Authentication. This may or may not affect your target audience, you'll have to judge that for yourself.
Edit: Here's the MSDN link for the cookieless feature: http://msdn.microsoft.com/en-us/library/aa479315.aspx