Cookies in ASP.NET are causing me some problems.
For the most part, I want to use cookieless sessions. This is mainly to get around a problem where safari won't let me set the cookies from an iFrame. So that part all works fine. Cookieless sessions do the job.
However, I have a page which is called from a POST. It uses a post to pass in a hidden field from a form which then does some stuff....you don't really need to know what.
So it turns out that when cookieless sessions are on, the POST is disabled and only GETS can happen in ASP.NET web forms. This is breaking my functionality.
What I want to do is add a web.config to the folder that contains my POSTing pages to go back to normal cookie sessions so I can get my POSTs working again, but this doesn't work.
<?xml version="1.0"?>
<configuration>
<system.web>
<sessionState cookieless="false" />
</system.web>
</configuration>
Does anyone know a way of making a folder work with normal cookie sessions while the rest of the site works with cookieless sessions?
I've found a solution to this:
What I do is create an HTTP Handler (a .ashx file). This takes specific post values form Request.Form and tags them on as Querystring parameters. This then does a redirect to my original page which now looks for Querystring params instead of Form ones. Phew!
The HTTP handler is what my app posts to now - it was a Facebook Signed request.
So the good news is, that I can use HTTP Handlers now - you learn something every day.
Related
Is it possible to increase the request timeout for just the one particular web page? I am working on ASP.Net 4.0 and I need one particular page to have a longer request timeout, since it is responsible for initiating a long running process. Thanks.
Use Web.config:
<location path="Page.aspx">
<system.web>
<httpRuntime executionTimeout="180"/>
</system.web>
</location>
This is an old thread, but it should be emphasized that updating the executionTimeout of a page or the entire machine must also be accompanied by the compilation debug flag being set to "false", otherwise the timeout element is ignored.
Also, depending on whether or not you are using AJAX update panels, you may also have to look at the AsycPostBackTimeout flag on the ScriptManager itself - depends on how your timeout is manifesting itself. Ajax post back timeouts will be seen as error messages logged to the Javascript Console and tend to manifest themselves as ajax operations "dying on the vine" depending on how you are handling things.
The debug="false" bit is probably what is afflicting the gentleman above who was having issues on his Amazon Server, but not locally.
Some googling will also reveal that some folks have noticed that localhost handles things differently as well, so you may need to experiment around that.
I am losing the ASP.NET_SessionId when switching between pages on my site. The issue happens in Chrome/Firefox/Safari. It does not happen in IE. It is rather strange...here is my scenario.
My site can be accessed by entering www.example.org or example.org in browser (this is an important piece of info as you will see).
I enter example.org. From my home page, I log into to my site (note: I am not using ASP.NET forms authentication). I am sent to my default user page (e.g., userpage.aspx). From this page, I click on an <a> that sends me to a different page on my site. The <a> link is full-qualified (e.g., http://www.example.org/page2.aspx). When I get sent to the new page, my session is lost!
So, I ran Fiddler to try and discover the problem. What I found was interesting. The Request Header tag Referer was getting lost between pages.
Here are the steps:
Go to example.org.
Login to example.org.
I get redirected to userpage.aspx. The Referer is http://example.org. The ASP.NET_SessionId is set.
I click on the <a> (e.g., http://www.example.org/page2.aspx). After the page is rendered, the ASP.NET_SessionId is lost.
The lost ASP.NET_SessionId is lost consistently is Chrome/Firefox/Safari. This does not happen in IE.
If repeat the above steps by substituting example.org with www.example.org, the ASP.NET_SessionId is not lost. It works, correctly each time.
Any thoughts on this behavior?
Add this to your web.config under the <system.web> element
<httpCookies domain=".mysite.com" />
See if there is any change in behavior. It sounds as though sub-domains are failing although I thought the cookie was based at the root domain to begin with. this should force it that way.
In my case the following was the issue:
In my local Visual Studio environment, my development "web.config" file accidentially contained the following:
<configuration>
<system.web>
<httpCookies requireSSL="true" />
</system.web>
</configuration>
Since the development IIS Express runs at http://localhost:7561, which is not HTTPS, this check triggered to not set/accept any cookies, including the session ID cookie.
Solution was to simply comment out the <httpCookies requireSSL="true" /> line.
Another, similar issue I could imagine is that the Content-Security-Policy HTML meta tag, that also controls how cookies are handled, could also be configured to not allow the session ID cookie to be set.
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 have an aspx page with a listbox control. The listbox is populated from a collection that is retrieved from a service when the page loads. When the user selects an item from the listbox the page posts back, adding the retrieved objects to the session before reloading. On the reload I use the session objects instead of having to call the service again.
This all works fine until I access the page from within an iFrame. The Session objects are not retrieved when the page is in an iFrame (Session["blah"] is null). This code works perfectly when the page is not in an iFrame.
I am using IIS7 and windows server 2008. Is there anything I need to do in ISS to allow Session variables to be used in an iFrame? Does anyone know of anything else that may cause this to happen?
Thanks,
Neil
IE gives lower level of trust to 3rd party content loaded in an iframe. This blocks session cookies.
You can solve this by setting a P3P header in IIS:
Name = p3p
Value = CP="IDC DSP COR CURa ADMa OUR IND PHY ONL COM STA"
See Also
Cookie blocked/not saved in IFRAME
in Internet Explorer
Compact P3P
settings with IIS7
In my case, the project was .net framework 4.6.1. I've upgraded to 4.7.2 version and added the key below to the web.config
<system.web>
<sessionState cookieSameSite="None"/>
This way third party Iframe sessions starts working.
Before you do this change, it's better to read this
https://learn.microsoft.com/en-us/aspnet/samesite/system-web-samesite
Actually never mind, I just cleared out the files in C:\Windows\Microsoft.NET\Framework64\v2.0.50727\Temporary ASP.NET Files and restarted IIS and it was all working
As of 2021, Chrome (and maybe others) requires that the cookie is secured.
This can be achieved this way :
<system.web>
<httpCookies httpOnlyCookies="true" requireSSL="true" sameSite="None" />
</system.web>
To enable sessions in iFrames:
InterNet Options -> Privacy -> Advanced -> Check "Always Allows Session Cookies"
I am having trouble with I guess Forms Authentication..
Site runs perfect can login and log out.. but after a while (this is not a specific time frame) suddenly URLs start to look like this:
http://www.mydomain.com/(A(EvoNg_065oCKJ1l_AcU4ND7Uzkm05wugwbYu4jiKb-_24aJmbmE_r5djE-mw9b_3tvEBOLIH1f64rrtq6RZOSFto_o0MaN-3edRpjH2Bfn8uBnrUFhv2xmk4_9oLXHVEt-Dg5BfdPA3VprkCIixmbhr2KPs1))/Default.aspx
What does this encoding (A) mean... is it the authorization ticket or Anonymous user ticket or what is it.
The funny thing is that it stays there and also include the encoding in all links on the page. Until at recycle the application pool for the site... when it is gone..... and it just starts over again after a while....
Anyone to point me in the right direction. Site is ASP.NET 4, using form auth and deployed on a IIS7
Please help...
Best regards
Henrik
This could be related to a cookieless session which you might have configured. Look for the following in your web.config:
<sessionState cookieless="true" />
Also checkout if cookieless Forms Authentication is not enabled.