We Keep Coding

Does secure flag true makes sense here for https application?

My application is on SSL(https). If user tries to the url with http , webserver(weblogic) redirects automatically to https.
With secure flag true, cookies will be passed on site is accessed with https.
Will adding secure flag as true makes sense here as my site is not entertaining http request and internally redirecting it to https ?
As per mine understanding , whether i add secure flag true does not make any difference as even i access the site with http cookies not be passed.
It will be passes only when my webserver redirecting to https. So i do not see any vulnerability even without adding this configuration.
Is that correct?

What if your user accesses via HTTPS, gets the cookies, and then later mistakenly accesses via HTTP? The cookies will get sent from browser to server in the clear, the server will redirect, and then everything will be secure again... but that cleartext transmission? That's why you want to mark them as secure.

How to share the Remember me cookie between Spring Apps in the same domain?

I'm developing an environment with 2 webapps deployed in Tomcat 7. One authenticate users using form, openid, remember me cookie or x509 cert. This one works as expected and use the Remember me cookie to authenticate properly when generated.
The problem resides in the second one (the client):
When the login request comes back to the client from the first one, I don't see any cookie. I'm pretty sure they are in the same domain (localhost) and the cookie path is "/" but the browser (firefox) is not sending the cookie to the client.
If I want to use the generated remember me cookie to authenticate in the client, do I need to include all remember me cookie stuff from Spring's security?
Is the remember me cookie a good approach? Do I need something like siteminder or other better approaches?
Thanks in advance. Answers will be voted

Check the cookie information when it is sent back from the server (use Firebug to monitor the network traffic if you're using Firefox).
Check the domain and path, and also whether the cookie is flagged as secure. If the remember-me cookie is issued over a secure connection it will be marked as secure and the browser won't send it over HTTP.
If this is the case, you have to explicitly override it (though you're better to use HTTPS throughout). There's a use-secure-cookie attribute in the remember-me namespace element which you can set.

Is it possible to add headers for CORS at the calling side server?

I have a GWT appilcation in which the client makes a request to another domain.
I wrote the request using RequestBuilder in GWT.
On executing the code, I get an error in my browser :
No 'Access-Control-Allow-Origin' header is present on the requested resource.
So I google and I found that the domain to which I am making the request should add this header in the response that it sends. Now I dont't have control over the other domain's server, so I can't do any modification there.
My question is, can I intercept the response and the Access-Control-Allow-Origin header to the response that is being sent by the other domain's server at my server, before I send it to my client?
I tried using Filters but the Filter doesn't get called for responses coming from another domain.
Is this possible to do, am I missing something or is it just not possible?

Vivek's answer that cross domain requests aren't allowed by the browser is true, except for the CORS mechanism, whereby newer browsers that support it can try in a cross origin way to servers that also support it.
However, unless that remote server support it itself, there is nothing you can do. If I server my app from A, and want to connect to B, only B can authorize that. If A were allowed to permit my app to connect to B via some filter or servlet, then I could write an app that makes calls to gmail or facebook or twitter and read/write your settings and personal data at those other urls.
So instead, it is the cross origin server that you are contacting that must approve the connection with the header you mentioned. In lieu of that, you can still use your own server as a proxy for the cross origin server.

Cross-domain requests are forbidden by web browsers as per the same origin security policy. These restrictions are limited to browser based applications and hence you can definitely use your own server application as a filter between the GWT based client side application and the external server.

Session is lost and created as new in every servlet request

I have this big issue. My current session is gone every time I made a new request to Server.
I have checked in a lot of places. I can't find what's the problem. I also have included
session-config in web.xml both in tomcat and application. I also enabled to accept cookies to my browsers. Tested in every browser. It's not working.
I am just developing a simple java ee applcation using JSP/Servlet. I am facing the problem only after I have deployed to tomcat in server machine.

One possible cause for this is having a "naked" host name (i.e. one without a domain part). That's fairly common if you're working in an Intranet.
The problem is that almost all browsers cookies will not accept cookies for hostnames without a domain name. That's done in order to prevent evilsite.com from setting a Cookie for com (which would be bad, as it would be the ultimate tracking cookie).
So if you access your applicaton via http://examplehost/ it won't accept any cookie, while for http://examplehost.localdomain/ it will accept (and return) the cookie just fine.
The nasty thing about that is that the server can't distinguish between "the browser got the cookie and ignored it" and "the browser never got the cookie". So each single access will look like a completely new sesson to the server.

After years, I never posted the answer back here. At that time I was busy and forgot about this question. But, today I am looking for a solution in Stackoverflow as usual and saw this notification mentioning I am getting points from this Question. Seems like other developers are facing the same issue. So, I tried to recall how I solved the issue. And yes, I solved by manually put back the session id to track/maintain the session id.
Please see the code that I manually put back jsessionid inside the servlet.
HttpSession session = request.getSession();
if (request.getParameter("JSESSIONID") != null) {
Cookie userCookie = new Cookie("JSESSIONID", request.getParameter("JSESSIONID"));
response.addCookie(userCookie);
} else {
String sessionId = session.getId();
Cookie userCookie = new Cookie("JSESSIONID", sessionId);
response.addCookie(userCookie);
}

First check if the webapp's context.xml does not have cookies="false" configured.
Further it's good to know that cookies are domain, port and contextpath dependent. If the links in the page points to a different domain, port and/or contextpath as opposed to the current request URL (the one you see in the browser's address bar), then the cookie won't be passed through which will cause that the session cannot be identified anymore and thus you will get a new one from the servletcontainer.
If that is not the cause, then check if you aren't doing a redirect on every request using HttpServletResponse.sendRedirect() for some reason. If you do this already on the very first request, then the cookie will get lost. You'll need to replace
response.sendRedirect(url);
by
response.sendRedirect(response.encodeRedirectURL(url));

In Your properties
server.session.cookie.http-only=true
server.session.cookie.secure=true
Remove these settings, it will retain your session id cookie, which is being reset with every request.

I experienced a stale https session cookie (my ad-hoc term) problem, due to a secure flag.
I had this problem when switching between http and https. The cookie stored by https session was never overwritten by http session. It remained in FireFox memory for eternity. It was visible in FireFox Tools / Options / Privacy / Delete single cookies where in Send for field it was Only for secure connections. Clearing this single cookie or all cookies is a workaround.
I was debugging the problem with wget, and I noticed such a header:
Set-Cookie: JSESSIONID=547ddffae0e5c0e2d1d3ef21906f; Path=/myapp; Secure; HttpOnly
The word secure appears only in https connections and creates this stale cookie. It's a SecureFlag (see OWASP). There are ways to disable this flag on server side, which seems like a permanent solution, but maybe not safe.
Or is it a browser bug, that the cookie is not overwritten?

Try adding the Live Http Headers plugin to firefox, and make sure the session cookie is indeed being passed to the browser from the server, and make sure the browser is sending it back again on the next request.

Please verify if the session is not being invalidated in your code someplace. Look for code similar to request.getSession().invalidate();

If there is a load balance configuration, will must have to configurate a route in the network for preserve the requests in the same server. Otherwise, the each request will go to a different server, losing the session attribute.

Edit your tomcat context.xml file and replace <Context> tag to <Context useHttpOnly="false"> , this helped me.

Are you connecting via http or https?
For servlets the session I'd cookie has attributes 'secure' and 'httpOnly'. 'secure' means user agent will only send cookie if transport is secure (https/tls). If your connecting with http a new session is created on each request. 'httpOnly' means the cookie can not be modified by client side script.

HTTPS Authentication and Cookies via Java

I am trying to login and retrieve status information from a HTTPS URL via Java programming. I login through /login.cgi, providing the username and password with a POST request to that script.
The script then verifies the credentials and creates a specific cookie (with session information, user name, etc.) and then immediately calls a Location response header to /home.cgi. Which, I'm guessing, the /home.cgi script verifies the cookie information before continuing to load. Otherwise, it just reverts back to the /login.cgi page.
All of this works fine within a browser because of the way browser's handle cookies/sessions correctly. However, within Java, this is very tricky because I can not get the appropriate cookie to send as a request to subsequent pages. I can not get the correct cookie because I am unable to get the HTTP response back (which holds the correct "Set-cookie" value) in between /login.cgi creating the specific cookie and it calling Location /home.cgi.
Is there something I'm missing or is there a better way that Java can handle cookies similar to a browser? (is there a cookie store, etc?)
Thanks for the help,
Steve

Cookie management is by default not enabled in the java.net HTTP API. If you don't need any specific handling or cross-application cookie persistence (the cookies will be deleted when your application terminates), you can simple enable it with
CookieHandler.setDefault(new CookieManager());

How are you making the HTTP connections and managing cookies?
I would recommend just using commons-httpclient rather than managing this yourself. It will automatically manage cookies for you.