Pls Help me, In my application I am storing some values in session. When I host the application in the server and store the session values in a page and redirect to another site and returning back to the domain I am unable to retrive the session values, but If I do the same in local host server, I am getting all the session values back, can anybody explain me the reason...???? I have set session mode as Inproc..
ASP.NET session (by default) is cookie based - so you need to check two things:
If session cookie with original request is being send with the next request to your domain (this will need domain name to be same for both requests)
Whether session is getting timed out at server end
Related
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.
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/
Can i access session variable of one site in another(same IIS)
site1:
aaa.xxx.com
Session["name"]="balaji"
site2:
bbb.xxx.com
string name=Session["name"].ToString()
Is it possible?
ASP.NET session state enables you to store and retrieve values for a
user as the user navigates ASP.NET pages in a Web application. HTTP is
a stateless protocol. This means that a Web server treats each HTTP
request for a page as an independent request. The server retains no
knowledge of variable values that were used during previous requests.
ASP.NET session state identifies requests from the same browser during
a limited time window as a session, and provides a way to persist
variable values for the duration of that session.
source : MSDN
This can be achieved using Query String.
Call the second site URL with a query string with it. http:\\bbb.xxx.com?name=balaji
Handle the query string in the second site.
More info - How to use Query String
Concerning an HTTP session: It is either implemented via cookies or URL rewriting.
Since the HTTP 1.1 uses persistent connections, I assume that a session is invalidated when a TCP connection disconnects. Or not?
I am confused on this since otherwise the behavior using cookies vs URL-rewriting would not be the same,right?I mean the browser does not store the values part of the URL-rewriting to disk, correct?
Additionally if it is not, how could we programmatically invalidate it on the server when a tcp connection resets?Is there such e.g. listener in Tomcat?
Since the HTTP 1.1 uses persistent connections, I assume that a session is invalidated when a TCP connection disconnects. Or not?
This is wrong.
In Java the session is implemented via cookie, usually (tomcat, jetty,etc). A cookie called JSESSIONID=1234567 (the number is randomly generated and identifies the session) is set from the server on the first response, then it gets stored in the browser and is sent back to the server for every subsequent connection.
This cookie usually has default lifetime of 30 minutes, and survives when the tcp connection is interrupted. This allows the server to recognize the user across different connections.
URL rewriting means that every URL contains the JSESSIONID as part of the URL, on the server side nothing changes, except that the JSESSIONID value is read from the URL instead than from the cookie.
If the cookie was lost after the tcp connection was closed, it was completely useless. Imagine a chat system based on a persistent tcp connection: do you need a cookie if you can simply identify the connection from an identifier binded to the socket? No... The cookie is useful exactly because you need to track the user across several connections.
Since the HTTP 1.1 uses persistent connections,
They are persistent, in the meaning that after a first request (the html page), the same connection can be reused to send also other resources (images, css, javascript, etc). And the browser keeps the connection open for sometime after, to avoid recreating a new connection in case the user clicks to another link. It's just an optimization, it doesn't mean that when you open a URL in your browser, the connection keeps alive for all the time you lay on the same website.
Additionally if it is not, how could we programmatically invalidate it on the server when a tcp connection resets?Is there such e.g. listener in Tomcat?
On the server, you can always invalidate the session calling session.invalidate().
If you want to invalidate the session every time a request is made, then you simply don't need a session.
Cookie can also be invalidated on the client side via javascript.
I am confused on this since otherwise the behavior using cookies vs URL-rewriting would not be the same,right?I mean the browser does not store the values part of the URL-rewriting to disk, correct?
URL rewriting works where cookies are disabled. Basically, every time you click on a link, the JSESSIONID= is appended to the url, so the server will identify the user, and all the subsequent links will continue to be generated on the server having the same JSESSIONID. In this way, every POST or GET request will contain the identification of the user (the session).
The cookie works in the same way, only that instead of being hardcoded on the URL, it gets embedded in the HTTP request as header information, and this is done by automatically by the browser (unless it has been disabled).
It doesn't mean that it gets saved in the disk (for what purpose?), it just keeps it in memory, for session cookies (that expire when you close the browser or after 30 minutes).
You can set a longer life time for a cookie; in that case, the browser stores the cookie for a longer time. But usually those are not "session cookie", but are cookie used to identify a specific user (like a UUID). From the UUID cookie then you can create a new session cookie when the same user reconnects.
The session, is used to keep track of a CONVERSATION. The user closes the browser, the conversation ends. If there is a persistent cookie like a UUID, then you can use that cookie to create a new conversation and bind the new session to the same user you met before.