I have an ASP.NET MVC application that is exhibiting some strange behavior...
Each page request gives me a new Session ID, I have tried everything that I can think of and its still not working.
The session is not empty, I am writing data to it on session start.
I have read the other questions on here and have checked:
1. All requests and coming from and going to the same domain.
2. The session is not empty.
3. The session is not being abandoned anywhere in the code.
I have used fiddler to confirm that the server is giving a new session ID on every request.
I have also checked the value of Session.IsNewSession and this is TRUE.
I must be missing something - if you have any idea what it might be I would really appreciate the help!
Fiddler output:
You are sending a session cookie that is marked "secure", but are making requests through HTTP (insecure). Either access your site through https, or change your session cookie to be non-secure.
Related
I post this question cause i've passed lot of time to find the solution and find nothing about this on SO.
I'm using a .NET WebAPI as back end and store the user informations in the session.
For any reasons the session is lost in Chrome.
I receive the Set Cookie with the session id on my first request but the session is not set in Chrome but is set in IE.
I've try to change the web.config several time and change the configuration of the server but nothing changed.
I'm using fetch API for call my services.
Fetch does not send cookies by default. If your cookies are not HTTP only, you have to set them manually in the headers collection.
The issue is on the fetch and not on the server side.
The strange thing is that it's work on IE. Apparently IE don't have the same policy for the fetch API.
You have to make sure to add the property credentials to include or same-origin to keep the session on your request.
Warning : Put credentials to include fire a security error in Chrome.
The same-origin value resolved my problem.
Example of request :
fetch(uri,{
method:'GET',
credentials:'same-origin'
})
.then()
.catch()
UPDATE: After doing analysis for my original problem which is listed in the second section i found the issue could be due to 304 response below is the detailed explanation.
I have developed a web application where users clicks on the link and its takes him to servlet where i set few session variables and then forward it to jsp. First time when i access the application things work fine after closing browser and then opening browser and accessing application i get null pointer exception in jsp because it is trying to access session data the reason it i am getting 304 response for the servlet , so this means that servlet is not invoked and my jsp are getting called ? since servlet is not called session values are not set .
Is my understanding correct?
I am observing this only in IE9
--------------------- My original question is below --------
We have integrated Siteminder in our application , I have observed that siteminder cookie SM session is created for different domain where as my application specific cookie is created for proper domain.
For every request i see new smsession value but my application cookie remains same , even though the cookie remains same the values which I set in session using servlet are not available in my jsp.
I have printed the jsession id, the jsession id is same for all request.
Below is the flow.
User hits a URL siteminder intercepts it and asks for credentials once user successfully logs in he is redirected to servlet where i set few values in Session then i dispatch the control to index.html which has two frames . I am loading two jsp for these frames and in these jsps i am trying to access the session values which i am unable to get .
I am observing this behaviour only in IE9 but IE8 behaves correctly,
First time access works fine second time does not in IE9
Can anybody let me know if change in smsesson incurs changes in httpsession for java app ? i don't think so as Jsession id remains the same.
What could be possible reason for this.
Have you checked if the jsps being called in the frames has the same session id as the one in the servlet?
To give you background on SMSESSION and JSESSION:-
The SMESSION id cookie keeps getting changed by the web agent periodically and is usually tagged to the base domain. Example - If the application is hosted at a.b.com - the JSession ID will typically be set to the domain a.b.com and the SMSESSION will be set to the b.com domain. This is the default Siteminder behaviour since it assumes that all applications in the b.com domain need the cookie for SSO. You can change this using the ACO for the agent by either setting the domain name explicitly or setting the scope of the domain that needs to be used.
Unless your application has logic which depends on the value of the SMSESSION id and modifies the java session, the JSessionID cookie is not impacted by the change in the value of SMSESSION
After doing analysis i found that it was 304 response for the servlet which was causing issue. When application was accessed first time there was no issue but next since when i try to run the application it would result into issue because browser would have cached responses , hence server would send 304 response because of this servlet would not be called and session would not be set .
I have two domains. Something like:
1) www.mydomain.com
2) www.mydomain.virtual.com
Temporarly, i must redirect Domain 1 to Domain 2, so when someone use www.mydomain.com y redirected him to www.mydomain.virtual.com.
The problem I'm facing is that (only on internet Explorer) session object is now losted between my sub-pages inside my web. I créate a session on default.aspx, and when i redirect with response.Redirect to let's say main.aspx, the object has no value. Does anyone have any idea why? Thanks!
Sessions are stored on the server, but the client needs to keep track of the sessionid. Usually a session cookie is used to store the sessionid.
What is causing this behaviour is that the sessionid cannot be resolved. Probably because the domain name is different and the browser interprets this as a third-party cookie, which can be (and probably is) blocked by the browser.
Since the sessionid cannot be resolved, all session info on the server is inaccessible. The link is broken.
Is it an option to copy the entire website to the temporary location and redirect all calls made to the original website to the equivalent page on the temporary location?
Otherwise you can solve your issue by using cookieless sessions:
https://msdn.microsoft.com/en-us/library/system.web.configuration.sessionstatesection.cookieless%28v=vs.110%29.aspx
For more information concerning cookies:
http://erik.io/blog/2014/03/04/definitive-guide-to-cookie-domains/
my question upfront is:
When changing from http to https: How do I enforce on Tomcat that the value of the JSESSIONID / (i.e. the session cookie) gets changed?
Here's my situation:
I assume we are having a potential security issue in our application and wonder how to fix it.
We run a JSF1.2 / Seam2 application inside of a Tomcat 6.x and force the usage of session cookies (no sessionid in URLs).
We allow http access, but when a user logs in we switch to https and stay on https.
We also do have a Filter that adds 'secure' to the cookie whenever the request is coming through https to ensure that the session cannot go back to http.
(somehow I thought Tomcat would do that automatically)
I noticed that the JSESSIONID doesn't change when switching between http and https.
This suggests to me that an attacker could potentially spy out the session cookie through http and then hijack the session.
So how can I tell Tomcat to use a different JSESSIONID when changing to https?
(Or if thats the default behavior: What could lead to this not happening anymore?)
Thanks for any hints/ideas!
some time (years actually) I posted this filter here that we use to renew the session ID after the login:
https://issues.jboss.org/browse/JBSEAM-2450
We call newSession() just after a login to mark the session-ID to be renewed on the next GET request (POST requests don't work well due to the restore of the view state, but the POST/REDIRECT/GET with Seam will issue GETs quite often).
You might want put it into your filter -- or you just mark your session to be refreshed in the next GET request. Just make sure that you don't renew your session when processing a JSF POST request.
Someone else also provided a Tomcat Valve to solve this
Best regards,
Alexander.
I am a bit baffled here; using IE7, ASP.NET 2.0 and Cassini (the VS built-in web server; although the same thing seems to be true for "real" applications deployed in IIS) I am looking for the session-id-cookie.
My test page shows a session id (by printing out Session.SessionId) and Response.Cookies.Keys contains ASP.NET_SessionId. So far so good.
But I cannot find the cookie in IEs cookie-store! Nor does "remove all cookies" reset the session (as it does in FF)... So where - I am tempted to write that four letter word - does IE store that bloody cookie? Or am I missing something? By the way there is no hidden field with a session id either, as far as I can see.
If I check in FF there is a cookie called ASP.NET_SessionId as I would expect. And as mentioned above deleting that cookie does start a new session; as I would expect.
Can anybody imagine what is happening here?
The ASP.NET session cookie is non-persistent, so it doesn't get saved to your hard-drive. It gets transmitted back and forth while you're using the application, but it gets discarded when you close the broswer.
From MSDN:
Note
When you run this code, you might see
a cookie named ASP.NET_SessionId. That
is a cookie that ASP.NET uses to store
a unique identifier for your session.
The session cookie is not persisted on
your hard disk. For more about session
cookies, see the "Cookies and Session
State" later in this topic.