I am not sure how to put it as it sounds weird, but IE8 seems to be dropping sessions. I am talking about sessions in the server, HTTP sessions.
I know that a browser does not as such have to do anything with the HTTP session in the application server, but it seems when I request the server to fetch something I previously stored in the session, it returns a "null".
I go...
session.setAttribute(YGConstants.SEARCH_STRING, searchString);
and then I say
session.getAttribute(YGConstants.SEARCH_STRING);
I get a "null".
Is this a known issue? Am I missing something specific to IE8 or have I not "Googled" enough?
When I use any of the Firefox, Chrome, IE6, IE7 and Opera browsers it all works fine.
I know that a browser does not as such have to do anything with the HTTP session in the Application server
Sure it does: it sends the cookie to the server that the server uses to keep track of the server-side session state.
Use Fiddler (www.fiddler2.com) to monitor your requests and ensure that the session cookie is being reliably sent.
In case it has something to do with your case, we had the same problem, but not on all servers. We eventually found that the problems were only when on the server whose name had an underscore ("_") character in it. Removing the underscore from the domain name solved the problem.
Related
I am facing the issue where I am unable to get the sessionID in Safari. I am unable to get the session id in my further calls in localhost as well as in https calls.
Below code I am using in my server.js. In Chrome and Firefox it is working fine. Problem is in Safari only. I am using cookie-session package of node.
Please help.
Boot.App.use(session({name: 'checkSession',keys: new Keygrip(['app-key-1'], 'SHA384', 'base64'),secure: false,httpOnly: true,domain: doc.Domain.ENV,maxAge: 31536000000}));
This is how i am creating a session
Boot.App.get('/set', function(req, res){req.session={checkSession:"user"};res.end(JSON.stringify("sessionSet"));});
But in further calls i am trying req.headers.cookie session id is coming undefined.
This has been a known issue with Safari browser. What essentially happens is that Safari disables third party cookies by default. One has to go to the browser and enable it, obivously on an enterprise application you can't ask your users to do that.
There were known workarounds for this using iframes, for eg -
Safari 3rd party cookie iframe trick no longer working?
But apple has since circumvented these too.
I'm working on extensions for Firefox and Chrome. The data used by my extensions is mostly generated from ajax requests. The type of data being returned is private, so it needs to be secure. My server supports https and the ajax calls are being sent to an https domain. Information is being sent back and forth, and the extensions are working correctly.
My questions are:
Do the extensions actually make secure connections with the server, or is this considered the same as cross domain posting, sending a request from a http page to a https page?
Am I putting my users' information at more risk during the transfers than if the user were to access the information directly from an https web page in the browser?
Thanks in advance!
The browser absolutely makes a secure connection when you use HTTPS. Certainly, a browser would never downgrade the security of your connection without telling you: it will either complete the request as written or it throw some sort of error if it is not possible.
Extensions for both Chrome and Firefox are permitted to make cross-domain AJAX requests. In Chrome, you simply need to supply the protocol/name of the host as a permission in your manifest.json. In Firefox, I think you may need to use Components.classes to get a cross-domain requester, as described in the MDN page for Using XMLHttpRequest, but I'm not 100% sure about that. Just try doing a normal request and see if it succeeds; if not, use the Components.classes solution.
I've managed to make a CORS request on IE8 using XDomainRequest. However it seems the cookies are not sent on IE8. Is there any hack for that ? The request is made from buy.example.com to buy.api.example.com
There is no way except to include the authentication cookie value / token in the query string e.g. : buy.api.example.com/?sessionId=$sessionId&otherparameters=test and set your webservice to check the query string if cookies are not present.
There is another way. If you use SSL on the non-default https port, it will keep sending the cookies.
For example, if your URL is something like this https://example.com:8443/xxxx, then it will send the cookies.
I experience the same issue you have. My web app (internal web app) was working with https but in a non standard port and it just works fine. When I configure to use 443, it stops working because the cookies are not sent by XDomainRequest object.
I hope this will help
I have developed a simple web-app with 2 servlets A and B.
I have a few doubts related to session management for the web-app by Tomcat.
NOTE - I have disabled cookies in my web-browser (Chrome) while accessing the web-app.
1.) When the web-app is first hit, Servlet A gets invoked. Servlet A accesses the session from the request and does a simple sysout of the session hashcode. It then does a sendRedirect to servlet B.
[According to my understanding, since this is the first request, Tomcat will send a cookie containing the new session ID back to the browser. However, since we have not "encoded" the redirect URL using HttpResponse.encodeRedirectURL(), the redirect URL will not contain the session ID appended to it. Please correct me if I am wrong here.]
2.) Since cookies are disabled in my browser, it'll ignore the session ID sent back in the cookie and issue a new request to the redirect URL (which also does not have the session ID appended to it).
3.) The new request causes servlet B to be invoked, whoch also accesses the request session and does a sysout of the session hashcode.
What perplexes me is that both Servlets A and B output the same session hashcode, which means that they get the same session from both requests.
How does the second request from the browser map to the same session as before, even though no session ID has been sent ?
Thanks !
There are only 2 ways to pass sessions between requests: Cookie and URL rewrite. If you don't see the session ID in the URL, it must be cookies.
Are you sure the cookie is disabled? It should be easy to see from a HTTP header trace.
Are you certain you've disabled "in memory" cookies? Often browsers will let you disable persistent cookies which are saved to disk, but they'll still allow the transient in memory cookies which only stay resident during a browser session.
I recommend Wireshark for analyzing the HTTP stream. That way you can see the cookies that are sent and received by your browser.
This is strange.
When I tested the application yesterday, it was exhibiting a behaviour similar to what I have described. However, as I test the application now, it behaves perfectly, as I expect it to.
The cause could probably be that I did not restart my browser session after disabling cookies.
Will let you guys know if I experience the same behaviour again.
Thanks for your time guys !
I have done a bit of testing on this myself (During the server side processing of a DWR Framework Ajax request handler to be exact) and it seems you CAN successfully manipulate cookies, but this goes against much that I have read on Ajax best practices and how browsers interpret the response from an XmlHttpRequest. Note I have tested on:
IE 6 and 7
Firefox 2 and 3
Safari
and in all cases standard cookie operations on the HttpServletResponse object during Ajax request handling were correctly interpreted by the browser, but I would like to know if it best practice to push the cookie manipulation to the client side, or if this (much cleaner) server side cookie handling can be trusted.
I would welcome answers both specific to the DWR Framework and Ajax in general.
XMLHttpRequest always uses the Web Browser's connection framework. This is a requirement for AJAX programs to work correctly as the user would get logged out if the XHR object lacked access to the browser's cookie pool.
It's theoretically possible for a web browser to simply share session cookies without using the browser's connection framework, but this has never (to my knowledge) happened in practice. Even the Flash plugin uses the Web Browser's connections.
Thus the end result is that it IS safe to manipulate cookies via AJAX. Just keep in mind that the AJAX call might never happen. They are not guaranteed events, so don't count on them.
In the context of DWR it may not be "safe".
From reading the DWR site it says:
It is important that you treat the HTTP request and response as read-only. While HTTP headers might get through OK, there is a good chance that some browsers will ignore them.
I've taken this to mean that setting cookies or request attributes is a no-no.
Saying that, I have code which does set request attributes (code I wrote before I read that page) and it appears to work fine (apart from deleting cookies which I mentioned in my comment above).
Manipulating cookies on the client side is rather the opposite of "best practice". And it shouldn't be necessary, either. HttpOnly cookies weren't introduced for nothing.