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.
Related
I'm using VSEW 2013 and running windows 10.
I created a login page (Login.aspx) and a signup page (SignUp.aspx). I used the standard controls and did not add any code behind to them. They are out of the box controls.
What works:
Creating an account on signup.aspx page
Validating user login on Login.aspx page
On my computer, after login, it shows that I didn't log in yet. But when my friends test it, they don't have any problems with it.
Here is a drop box link to all of the files and you can test it yourself and see that it works.
https://www.dropbox.com/sh/do3f533s0hacy4x/AADuWBbIBpaxDy7SIPG9_7s6a?dl=0
Username: kyle
password 123456
However, signup.aspx works (well it won't send you an email because I didn't do that yet) so you can create your own account.
I've tried:
Verified that cookies are enables
Disabled Antivirus
Disabled Firewall
Checked Windows Defender (it's off)
Tested in Chrome, Edge, and Firefox.
Deleted all localhost cookies.
I cannot figure out why my computer won't let me log in successfully but everyone else can.
Please help me solve this problem.
Looking at your web.config, for some odd reason this section is there:
<system.webServer>
<modules>
<remove name="FormsAuthentication" />
</modules>
</system.webServer>
This section coupled with the fact that your authentication mode is set to forms:
<system.web>
<authentication mode="Forms" />
...
</system.web>
Would make it so that authentication wouldn't work at all, which is like what your describing. Try removing that first section, if you want to keep using Forms Authentication.
It's odd that this configuration would work on other computers, I can't explain that, but I would try removing that section of code where FormsAuthentication is being turned off and see if that helps.
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.
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"
We recently updated a site from Classic ASP to ASP.Net 3.5.
The old site used a login system based on cookies.
It would remember the users login information if a checkbox was selected when they first logged in. This would of course be done in a cookie.
We then upgraded the site Using ASP.net.
We transferred the old users to the built in ASP.net Membership Authentication.
It works great except for a really strange occurrence.
When a user logs in to the site, but had the old cookie for the site which stored the login information, the ASP.net Authentication seems to crash.
There is no error message, no information of any kind.
The user tries to login, gets no error message, just gets transfered back to the login page.
It seems to be looking at the old cookie and just doesn't know what to do.
The domain names of the old site and the new site are the same.
This does not occur for new users who have never been to the old site.
If an old site user clears out his cookies in his browser he can log in fine and the error never happens again.
But we have 5000 users, we can't tell all of them to clear out their cookies.
I tried changing the setting in the following line of code in my web.config.
<authentication mode="Forms">
<forms cookieless="UseCookies" loginUrl="~\User\Login.aspx" defaultUrl="~\Default.aspx" timeout="26280000" />
</authentication>
But I'm not sure if it helped or not.
Any assistance would be greatly appreciated.
Thanks
With forms authentication, your login is controlled by forms authentication cookie. So I don't understand how is your old cookie interfering with FAC?
In case you are storing some value in your custom cookie, one way would be change the name of the cookie in your new code. i.e. if the code is creating "CookieA", the same name as old application, change it to "CookieB" and same while reading.
Specify cookies token name:
<forms name=".ASPXFORMSAUTH" ... />