I want to retrieve all cookies in a browser using java (i.e. request.getCookies()).
The problem is request.getCookies() retrieves cookies of fb.com and if I want to get cookies of 'abc.fb.com' it is showing only cookies of 'fb.com' and not 'abc.fb.com'.
How to overcome this?
As mentioned it's not allowed due to the same origin policy.
But you will be able to get both cookies only if you store them for the domain "fb.com". In that case you will get the same set of cookies in requests to fb.com and abc.fb.com as well.
Related
I have a legacy Java 1.6 running localhost with Tomcat 7 application using JSP pages, a frameset with frames, javascript, but no framework like Struts. I pass an object to display in the page from the servlet using the request or session and that works fine.
However, I made some changes recently and now I can't retrieve that same object back from the session or request. It had been working fine previously, so I'm not sure what is broken, but I can't even send a string value back from the JSP's back to the servlet.
I created a new stripped down JSP and I can't get anything back from that either using the request or session. It does the same thing when I push the code our Tomcat 6 web server. Using the debugger, I see the objects populated in the session, but then lost later when a new session is created each time as in using this simple code to get the sessionid:
System.out.println("The session id is: " + session.getId());
The session id is: EB431C19B41957B2BB2EFC3DBAF32241
The session id is: C9CBD30E84D5C93DF6114C1412AE5523
I then see this in firebug under the Header, response headers:
Set-Cookie JSESSIONID=C9CBD30E84D5C93DF6114C1412AE5523; Path=/Name omitted here/; HttpOnly,
so I know cookies are set. I also removed jquery and I"m stripping down the jsp code as much as possible, but that doesn't seem to be the issue.
I'm using:
HttpSession session = request.getSession(true); but using false didn't matter.
session.setAttribute("ObjNameList", objNameList);
The context.xml has cookies set to true and we do use response.sendRedirect, but only if an error is thrown as in: response.sendRedirect("Error.jsp"); There is no place in the code with session invalidate either.
All I'm doing from the jsp is sending a form back using something like:
document.formName.submit(); which works fine. Using this code to try and set a simple string in the session doesn't work either:
session.setAttribute("somevalue","someValue");
Gives me null in the servlet here:
String val = (String) session.getAttribute("somevalue");
Any ideas as to what could be causing this?
Resultion:
It turned out to be an issue with the url, a typo actually, as BalusC mentioned, so the path for the session cookies didn't match between the jsp and the servlet.
Doublecheck if the request URL to that servlet matches the session cookie domain and path. If it doesn't match, then the browser simply won't send the session cookie back along with the request and the server will think that there's no means of an established session and will therefore simply create a new one.
You can check cookies in the HTTP traffic monitor of browser's web developer toolset (press F12 in Chrome/Firefox23+/IE9+ and open "Network" tab). When a new session starts, the server must have returned a response with Set-Cookie header with therein the cookie value and path (and implicitly domain). When the browser sends a subsequent request on the same domain and path, then it must have passed that cookie back via Cookie request header.
See also:
How do servlets work? Instantiation, sessions, shared variables and multithreading
I'm trying to invalidate/expire an insecure cookie from a securely accessed servlet and send a redirect back to the client. However, when the redirect is followed, the request still contains the original, unexpired, uninvalidated (is that a word) cookie.
Here's a more detailed description of the flow:
1) Client requests a particular insecure url backed by Servlet A.
2) Servlet A detects that there is a Cookie XX and redirects to a secure url backed by Servlet B
3) Servlet B does its magic, then invalidates Cookie XX by setting the MaxAge to 0 and redirects to Servlet A via an insecure url.
4) In Servlet A, I'm still able to access the cookie just as it was in the first request.
Can anyone lend a hand? I was under the impression and can't find evidence to the contrary that when a cookie is sent back with a redirect response, it is still processed before the new request is sent out. This is happening in all browsers (Chrome, FF, IE) that I have access to, so I don't think its a browser thing. In HTTPFox and the Chrome Developer tools I can see the original cookie getting sent in the first and second request, the invalidated cookie coming back in the response to the second request, and the original cookie being sent again in the third request. I've tried setting the MaxAge to 0, setting the value of the cookie to null/empty string, and another value but it never changes. All of the server side code is done in Java if it matters.
Help is very much appreciated.
Have you tried making sure that the domain and paths for the invalidated cookie is the same as the original cookie?
Also, a better way to handle sensitive cookies is setting the 'secure' flag on the original cookie. That will tell the browser to never send the cookie over an insecure connection.
This turned out to be an oversight on my part. When Servlet B invalidated Cookie XX, it also set the cookie's path to something other than what it originally was. That, in effect, created a Cookie XX-B and had no effect on the original Cookie XX. Making sure my cookie's paths were the same fixed it.
In two separate projects I've had to invalidate a cookie. This is what I have had to do:
Get the cookie in question from the HTTP request object
Set cookie max age to by invoking Cookie.setMaxAge(int).
Call the Cookie.setPath(String) method, even if path is to remain the same
Add the cookie back into the HTTP response object, I.e. HttpServletRespons.addCookie(cookie)
Only after executing all the steps above did the browser stop passing the cookie back to server on subsequent requests.
I'm new to Java. I'm writing an application to link to a vendors Flash site. I have my BlazeDs based program talking to their site. I'm running into a problem where a session cookie is not getting set. The problem is that the host doesn't return it as a "set-cookie" header.
Their site returns the following cookieDirectives to set the SMSESSION cookie
cookieDirectives
Externalized Object
flex.messaging.io.ArrayCollection
[0] String SMSESSION={CONTENT STRIPPED FOR CLARITY}; max-age=-1;path=/; domain=.-----.com
I can set the cookie in my amfConnection as follows:
amfConnection.addHttpRequestHeader("Cookie", resultString);
However, that only gives me the one cookie and there are several others I need. The others have been set earlier by the host and are set using a "Set-Cookie" header.
How can I either add this cookie to the existing ones or recover the existing cookies so I can manually add them.
I was able to resolve this by changing my approach. Instead of relying on my amfConnection to handle the cookies I grab the session id using httpclient, store it in a variable, and then push my cookies to amfConnection.
I need to implement a simple remember me option in a java servlet with cookies, without using any advanced framework.
First, at login, I create the cookie and send it in response to the browser (client). The value to be stored in the cookie is just a simple hash from username + password.
How should I manage the incoming request from the browser, sending the cookie?
My approach is to check between registered users if there is any user that has the hash from username + password equal to the value in the cookie?
Is this approach correct?
Also, I did not understand exactly what is the mechanism of the expiration date. Does the browser delete the cookie when it is expired, it not, how do I check if the cookie is expired?
As long as you're not using HTTPS the method you suggest is highly insecure. I would suggest to generate some sort of session token (e.g. use java.util.UUID.randomUUID()) and set this as cookie and store it somewhere on the server side so you later can identify the user associated with this session id in the cookie.
This gives you the opportunity to reset a certain session cookie if you think there's some fraud happening and there's no direct relation between the user name/password and the cookie id you use. But note: this method is still vulnerable to a man-in-the-middle attack.
Concerning the expiration: yes the cookie becomes invalid and might get deleted by the browser if it is expired. But you can set the cookie to something in the year 3000, so it lives forever.
Do a browser pass the cookie name and cookie value saperately or both in one string ? Do it also pass domain or not??? I want to know what happens in the case of a java browser.
Cookies are sent as HTTP header, which is a pair of strings.
What kind of java browser are you talking about?
If you want to make a HTTP request in java, I'd suggest you use HTTPClient.