Safari set-cookies not working for first party cookie - spring

When I login, I return to the browser:
Overview
URL: https://subdomain.domain.de:8444/api/auth/login
Status: 200
Source: Network
Adresse: xxx.xxx.x.xx:8444
Initiator:
xhr.js:177
Request
POST /api/auth/login HTTP/1.1
Accept: application/json, text/plain, */*
Content-Type: application/json;charset=utf-8
Origin: https://subdomain.domain.de
Content-Length: 62
Accept-Language: de-de
Host: subdomain.domain.de:8444
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_4) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.1 Safari/605.1.15
Referer: https://subdomain.domain.de/login
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
Response
HTTP/1.1 200
Access-Control-Allow-Origin: https://subdomain.domain.de
Content-Type: application/json;charset=UTF-8
Pragma: no-cache
Set-Cookie: accessToken=FycxgaSUgHnBlzMqYn/qsBEm5YBcmX52/eYbm+daUHPP1Fa7edawdawdawO1EdJlz9nyP5FrlPYnh/b//SZJRDs0Am8sGF+UZ+XffvPra8awdawd9+RbHiN0WcL+9T4xLlueMxd5bNVRVKHqeTonSK02Ym0cLxfALOeHrmbdqLS95uNOlzFYbjOuGV7bhwLGk5bavNPv9IWKqNAILAbkkw+gdawdawduM+BXdGE7KFbUgxvGmDw==; Path=/; Domain=subdomain.domain.de; Max-Age=PT448343981H30M29S; Expires=Sat, 16 Apr 2072 22:57:46 GMT; Secure; HttpOnly;SameSite=Lax
Set-Cookie: refreshToken=FycxgaSUgHnBlzMqYn/qsBEm5YBawdawdadawdupnO1EdJlz9nyP5FrlPYnh/b//SZJRDs0Am8sGF+UZ+XffvPra84jWTk9+RbHiM1+aNElVA8jXewqlexh7tGKuawdawdv4pxzC/RsDoGS/Jc8Xkzg133dYMCr7mRHlkU7jijoJrPYUAayiewVIMPUh/IE8sGUqIMKbiGoqAJAawdawdawdawdawdaw03GS4XgbwFj76V2AAAw==; Path=/; Domain=subdomain.domain.de; Max-Age=PT450502981H30M31S; Expires=Fri, 15 Jul 2072 21:57:46 GMT; Secure; HttpOnly;SameSite=Lax
X-XSS-Protection: 1; mode=block
Expires: 0
Transfer-Encoding: Identity
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Date: Mon, 22 Feb 2021 22:58:53 GMT
Access-Control-Allow-Credentials: true
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
Vary: Origin, Access-Control-Request-Method, Access-Control-Request-Headers
Strict-Transport-Security: max-age=31536000 ; includeSubDomains
Request data
MIME-Typ: application/json
Codierung: utf-8
Anfragedaten:
I also see, the cookie in the response:
But the cookies are not saved in the browser. This is a first party cookie which I am creating in my spring backend.
In Spring Boot, I create the cookies like this:
import org.springframework.http.HttpCookie;
import org.springframework.http.ResponseCookie;
#Component
public class CookieUtil {
public HttpCookie createAccessTokenCookie(String token, Long duration) {
return ResponseCookie.from("accessToken", token).maxAge(duration).httpOnly(true).path("/").build();
}
public HttpCookie createRefreshTokenCookie(String token, Long duration) {
return ResponseCookie.from("refreshToken", token).maxAge(duration).httpOnly(true).path("/").build();
}
}

There are a great number of problems related with Safari and the use of cookies, if you look up for information related with the problem you will find multiples bugs and solutions, ones appropriate for some cases, and ones for another.
Although Lax is preferable (please, see this great article), one thing you can try is setting your cookies SameSite attribute to None. Be aware that this change maybe could be relevant and affect the application behavior in other browsers, especially Chrome.
Another thing you can try is setting the domain for the cookie to something like .domain.de or domain.de to avoid any possible subdomain related problem.
Finally, please, pay attention to the fact that in your screenshot it seems that the value for max age is not printed correctly. Probably not but perhaps a similar issue, for the same version of Safari you indicated, has been reported here on SO in this question: the OP solve the problem by adjusting the value of the max age cookie attribute. Please, try different values for that information, maybe it works.
According to your comments, for future reference, in some way the problem seems related actually with the cookie max age: removing max age value from the cookie looks like a temporary workaround for the problem.

In safari you ll have to ask the user to allow the use of your cookie.
As of ITP 2.1, Safari uses its machine-learning magic to identify which first-party cookies can be used for tracking. Then, it blocks cookies unless you use the Storage Access API to ask users to allow the use of your cookie.
you can further read on how to use this here https://developer.mozilla.org/en-US/docs/Web/API/Document/requestStorageAccess

Related

Spring Boot: RequestRejectedException: The request was rejected because the URL contained a potentially malicious String ";"

I get the following exception when I POST the login credentials for my Spring Boot app.
org.springframework.security.web.firewall.RequestRejectedException: The request was rejected because the URL contained a potentially malicious String ";"
It is posting to /dologin and then redirecting to /home with the jsessionid appended to the end. It does also set the session cookie too. I did not change any session settings and there is no mention of session in application.properties.
I tried to set
server.servlet.session.cookie.http-only=true
server.servlet.session.tracking-modes=cookie
As mentioned in https://stackoverflow.com/a/31792535/148844, but it didn't work.
I added
#Bean
public ServletContextInitializer servletContextInitializer() {
return new ServletContextInitializer() {
#Override
public void onStartup(ServletContext servletContext) throws ServletException {
servletContext.setSessionTrackingModes(Collections.singleton(SessionTrackingMode.COOKIE));
SessionCookieConfig sessionCookieConfig=servletContext.getSessionCookieConfig();
sessionCookieConfig.setHttpOnly(true);
}
};
}
But now it just POSTs, sets the cookie, and redirects back to the login screen. It's as if it can't access the session.
I set server.session.tracking-modes=cookie (instead of server.servlet...) and it is only using cookies now, but the Chrome browser is not sending the cookie back to the server after login! /home action will only re-display the login page if user attribute in the session is null.
POST /dologin HTTP/1.1
Host: localhost:8080
Origin: http://localhost:8080
Upgrade-Insecure-Requests: 1
Referer: http://localhost:8080/home
HTTP/1.1 302
Set-Cookie: JSESSIONID=3B82AAA40CE94FF490FBF7B4DBD837DD; Path=/; HttpOnly
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: 0
X-Frame-Options: DENY
Location: http://localhost:8080/home
GET /home HTTP/1.1
Host: localhost:8080
Upgrade-Insecure-Requests: 1
Referer: http://localhost:8080/home
HTTP/1.1 200
Set-Cookie: JSESSIONID=B60BF649068F7E85346691FD2F5D119B; Path=/; HttpOnly
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: 0
X-Frame-Options: DENY
Content-Type: text/html;charset=UTF-8
Content-Language: en-US
Content-Length: 2742
Date: Sat, 29 Sep 2018 17:41:55 GMT
Notice the cookies are different and Chrome did not send the cookie back to the server? Why?
Spring Boot 1.5.13, Chrome Version 69.0.3497.100 (Official Build) (64-bit)
OK changing server.servlet.session.cookie.http-only=true to server.session.tracking-modes=cookie and changing http://localhost:8080 to http://127.0.0.1:8080/ worked. I found this answer:
Chrome localhost cookie not being set
It seems Chrome keeps flipping from allowing localhost to disallowing localhost. It was working about a month or three ago. localhost is working for a Rails app and Chrome is sending the cookies.
In fact, Chrome is also sending the _mt_rails_session Rails cookie for localhost to the Spring Boot app, but never the JSESSIONID cookie.
I suspect, but have not confirmed, it may be due to setting up HTTPS on port 8080 for an unrelated 3rd Spring Boot app, and there may be some HSTS setting cached in Chrome internals. It's probably a bug in Chrome.

Permanent Cookie Contains Sensitive Session Information Laravel using Appscan security tool

I have scan the Laravel Project using AppScan tool, I am facing security issue Permanent Cookie Contains Sensitive Session Information issue in AppScan Security Document.
Here is My Network information of Header:
Cache-Control: no-cache, private
Connection: keep-alive
Content-Encoding: gzip
Content-Length: 3692
Content-Type: text/html; charset=UTF-8
Date: Thu, 16 Aug 2018 06:01:02 GMT
Expires: 0
Pragma: no-cache
Server: Apache
Set-Cookie: XSRF-TOKEN=eyJpdiI6Ik9XVzJyOXRSZ0JkRnhaTXdkZlQzeVE9PSIsInZhbHVlIjoibUxEKzBLUHdCM2VwWVc4MzhPNjR3TmpcL2VZdWJXRjJmeVZklSaGtnb2RRblVBblpXNEVDS1wvMXExKzQwaE9NWlQwVFRpUTZiTHB3b1ZRMlcwZz09IiwibWFjIjoiNzhmMDg4MjUzN2YzMDA3MDg3MTJiOGNkMTQ4MTZlNWIyZWZiZTkxYjgwNzI1NzVmMzBmNWQyYjE1ZThjZDc3MiJ9; expires=Thu, 16-Aug-2018 08:01:02 GMT; Max-Age=7200; path=/; secure;HttpOnly;HttpOnly;Secure
Set-Cookie: laravel_session=eyJpdiI6InJpK3FNeHhTMGFEUUgxSGxKUkc1Rmc9PSIsInZhbHVlIjoieVRGaGpMcnJ3bnBrWCtOTzZcL2dzVFRKNDl5U29jUTlvb0tSZE54d2YxbTFvSHZ3TW5jc2FXcFwvcjhLaXlFN2R5eEo0Tlpoa1FxY0VUWlJ5bUjIjoiYTY2MjkwODU3YWQyMTFmZTJkNmZlMWUzMTgyYzk2NjA2OTBiMDgyODMzM2ZlZjg4NDE4MDBjZDFkYmIyNmEyMCJ9; expires=Thu, 16-Aug-2018 08:01:02 GMT; Max-Age=7200; path=/; secure; httponly;HttpOnly;HttpOnly;Secure
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
Vary: Accept-Encoding
X-Content-Security-Policy: allow 'self';
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1; mode=block
Also When i stop/ remove cookies from server side. I will block the csrf token.
How can i fix this security issue.?
Please Help!!
Thanks in Advance
I think it's a bug in the AppScan application. The message is already correct, session information is stored in the cookie. This serves to transfer this token with every request and to send back a new CSRF token afterwards.
Since the cookie has a Max-Age=7200; the cookie lives only 2 hours. Therefore, AppScan's statement that the cookie exists permanently is false.
And remember, with each request a new CSRF-Token is assigned to you, whereby the attacker would have to manipulate your locally sent request to be able to use this method.

JHipster: CORS fails on form login (actual request, not pre-flight)

I would like to extend my monolithic setup of jHipster with a second front-end application which accesses the same API from a different URL. As a first step, I've enabled CORS in the application.yml and I'm sending the request from the front-end with the withCredentials flag. I'm using sessions and no JWT authentication.
Many methods work now as expected, but not all. The pre-flight (OPTIONS request) always goes through and works as expected. The response of this call contains the correct CORS headers.
The actual request (e.g. the POST request to sign in), however, requires also a header (Access-Control-Allow-Origin) in the response. This header is automatically set on my custom REST interfaces, but it is not set on jHipster-generated methods like /api/authentication or /api/logout. It does also not work on Spring-Security-protected resources like /api/account (only if not logged in, 401, afterwards it works as expected with the correct headers)
As for the logout, for example, Google Chrome reacts with the following message in the console, even though the call goes through in the Network tab (POST response status 200):
XMLHttpRequest cannot load http://localhost:8080/api/logout. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost:9000' is therefore not allowed access.
I was wondering, what I'm doing wrong here. I guess the headers are not properly set. I could now manually add the header (e.g. in the AjaxAuthenticationSuccessHandler), but that does not seem right.
I'm using the rather outdated version of jHipster 3.7.0. I would, however, prefer not to update the core project.
Do you have any idea, what could be causing this issue?
Headers
Here are the complete headers of the POST call to /api/logout. The OPTIONS call works as expected but in the POST response the Access-Control-Allow-Origin header is missing:
OPTIONS Request
OPTIONS /api/logout HTTP/1.1
Host: localhost:8080
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache
Access-Control-Request-Method: POST
Origin: http://localhost:9000
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.113 Safari/537.36
Access-Control-Request-Headers: x-csrf-token
Accept: */*
DNT: 1
Referer: http://localhost:9000/
Accept-Encoding: gzip, deflate, br
Accept-Language: de-DE,de;q=0.8,en-US;q=0.6,en;q=0.4,de-CH;q=0.2,it;q=0.2
OPTIONS Response
HTTP/1.1 200 OK
Access-Control-Allow-Headers: x-csrf-token
Date: Mon, 11 Sep 2017 13:54:57 GMT
Connection: keep-alive
Access-Control-Allow-Origin: http://localhost:9000
Vary: Origin
Access-Control-Allow-Credentials: true
Content-Length: 0
Access-Control-Allow-Methods: GET,PUT,POST,DELETE,OPTIONS
Access-Control-Max-Age: 1800
POST Request
POST /api/logout HTTP/1.1
Host: localhost:8080
Connection: keep-alive
Content-Length: 0
Pragma: no-cache
Cache-Control: no-cache
Accept: application/json, text/plain, */*
Origin: http://localhost:9000
X-CSRF-TOKEN: [***token removed in this snippet***]
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.113 Safari/537.36
DNT: 1
Referer: http://localhost:9000/
Accept-Encoding: gzip, deflate, br
Accept-Language: de-DE,de;q=0.8,en-US;q=0.6,en;q=0.4,de-CH;q=0.2,it;q=0.2
Cookie: [***removed cookies in this snippet***]
POST Response
HTTP/1.1 200 OK
Expires: 0
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Set-Cookie: CSRF-TOKEN=null; path=/; Max-Age=0; Expires=Thu, 01-Jan-1970 00:00:00 GMT
Set-Cookie: JSESSIONID=[***removed jsessionID in this snippet***]; path=/; Max-Age=0; Expires=Thu, 01-Jan-1970 00:00:00 GMT
Set-Cookie: remember-me=null; path=/; Max-Age=0; Expires=Thu, 01-Jan-1970 00:00:00 GMT
X-XSS-Protection: 1; mode=block
Pragma: no-cache
Date: Mon, 11 Sep 2017 13:54:57 GMT
Connection: keep-alive
X-Content-Type-Options: nosniff
Content-Length: 0
Reproduction
You can reproduce this behavior by using this demo project of jHipster in version 3.7.0. Then, enable the CORS settings (all of them) in src/main/resources/application.yml. After that, create a new user on localhost:8080 and activate it. Finally, try to authenticate with the following JS snippet from another port (e.g. a simple node server or xampp). You can also try to make a simple POST call to /api/account, which will lead to a 401 error. See the Google Chrome console for the error message.
<script type="text/javascript" src="https://cdnjs.cloudflare.com/ajax/libs/axios/0.16.2/axios.js"></script>
<script type="text/javascript">
var Http = axios.create({
baseURL: 'http://localhost:8080/api',
});
Http.interceptors.request.use(function (config) {
config.xsrfCookieName = 'CSRF-TOKEN';
config.xsrfHeaderName = 'X-CSRF-TOKEN';
config.withCredentials = true;
return config;
});
var credentials = {
username: 'test-user',
password: 'test123',
rememberMe: true
};
Http.post('authentication', 'j_username=' + credentials.username +
'&j_password=' + credentials.password +
'&remember-me=' + credentials.rememberMe +
'&submit=Login');
</script>
It looks like you are running into this CORS issue where one of the filters before the CorsFilter in Spring Security's filter chain throws an error. The request never reaches the CorsFilter, causing the CORS headers to be missing in the response. That's why Chrome complains about the missing headers in the console even though it's a different error.
You need to put the CorsFilter before CsrfFilter and UsernamePasswordAuthenticationFilter so that if there's an issue with either of those filters, the response still gets the CORS headers. To accomplish this, add the following code to SecurityConfiguration.java:
// import CorsFilter
import org.springframework.web.filter.CorsFilter;
...
...
// inject for JHipster v3 apps, add to constructor for JHipster v4 apps
#Inject
private CorsFilter corsFilter;
...
...
// add this line in the configure method before ".exceptionHandling()"
.addFilterBefore(corsFilter, CsrfFilter.class)
Also in SecurityConfiguration.java, you can set #EnableWebSecurity(debug = true) to see the filter chain for each request. You can verify everything is correct by making sure the CorsFilter is before the CsrfFilter and UsernamePasswordAuthenticationFilter in the chain:
Security filter chain: [
WebAsyncManagerIntegrationFilter
SecurityContextPersistenceFilter
HeaderWriterFilter
CorsFilter <--------- Before CsrfFilter and UsernamePasswordAuthenticationFilter
CsrfFilter
CsrfCookieGeneratorFilter
LogoutFilter
UsernamePasswordAuthenticationFilter
RequestCacheAwareFilter
SecurityContextHolderAwareRequestFilter
RememberMeAuthenticationFilter
AnonymousAuthenticationFilter
SessionManagementFilter
ExceptionTranslationFilter
FilterSecurityInterceptor
]
If you are running into CSRF issues in your new client, you may need to make a GET request after a POST to refresh the CSRF token. An example of how JHipster handles this can be seen when logging out.
Have a look at how the org.springframework.web.cors.CorsConfiguration Spring bean is configured in the JHipster common application properties. I think you are missing the following configuration line:
exposed-headers: "Authorization"
I just documented this a few hours ago, and also added this configuration by default a few hours ago.
In the next release, which should be out tomorrow, you should have a new page called Separating the front-end and the API server that should explain that better - and if you have found a better solution, don't hesitate to improve that page, it's a first version.

Redirects stopped working in Firefox

I'm stumped, my website was working fine and now on Firefox suddenly the redirects stopped working.
I've tested IE and Chrome and going to /login redirects me to /dashboard however on Firefox the page is blank (no output sent) and no errors are logged. So this is why I'm assuming it to be a browser related issue. It might be due to a firefox update, but not sure how to confirm that.
Here are the headers:
Request Headers
GET /login HTTP/1.1
Host: local.example.com
User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Firefox/24.0 FirePHP/0.7.4
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
DNT: 1
Cookie: __utma=34805930.947644602.1372214584.1380730296.1380733154.30; __utmz=34805930.1378700053.15.2.utmcsr=google|utmccn=(organic)|utmcmd=organic|utmctr=(not%20provided); __utma=214248714.242656582.1377296111.1380047082.1380734348.30; __utmz=214248714.1377296111.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); __qca=P0-705514134-1378344178153; __utmc=34805930; __utmb=34805930.15.10.1380733154; __utmb=214248714.5.10.1380734348; __utmc=214248714; PHPSESSID=lli8i30qkhvohfm9ufkbdvbki0
x-insight: activate
Connection: keep-alive
Response Headers
HTTP/1.1 302 Found
Date: Wed, 02 Oct 2013 17:30:58 GMT
Server: Apache/2.4.3 (Win32) OpenSSL/1.0.1c PHP/5.4.7
X-Powered-By: PHP/5.4.7
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Location: /dashboard
Content-Length: 0
Keep-Alive: timeout=5, max=98
Connection: Keep-Alive
Content-Type: text/html; charset=utf-8
It all looks pretty standard to me, however FF stays stuck on /login Am I missing something?
This behaviour is both on my local windows host and my remote amazon Linux web-server. The body is empty...
How could I go about debugging this?
The Expires header field in the response is really off. Firefox probably does not bother to render stale responses.
Please check the system time in your server. It is possible it is an Amazon problem, but it is also possible that one of the server users set the system time.
You can look into setting up a Network Time Protocol (NTP) client to run regularly (with ntpd), if you don't have that yet.
I would fire up Fiddler to see what bits actually went over the wire. Among other information, Fiddler will show what content type is actually used during the HTTP request / response.
This could be related to the fact that there is no extension. Firefox could be having trouble determining if this is a document or folder. Try firebug and see what URL Firefox tries to request after the redirect.

Can not log out from Tomcat using Firefox

I've encountered quite unexpected problem using Tomcat and CAS authorization. I just cannot logout in Firefox. I'm redirected to the logout page, but as soon as I reenter application url in the address bar, it is opened as if I'm logged (and I'm logged actually!).
First I've take a notable amount of attempts to fix something in tomcat config, then I've read logs, but nothing helped me actually before it comes up to my mind to check logout behavior in other browsers.
In other browsers everything work just as expected.
And I'm just stuck and would appreciate if one will give me a hint.
I guess [this question][1] is in some way relative with mine, but, helas, disabling caching on the page which should me logouted doesn't help either.
UPD: Some debug information. Firefox's version is 7.0.1, unfortunately, it is not a public application and I can not provide any url. It looks like response.sendRedirect output is something that Firefox is missing. Here is minimal code that works in any browser except Firefox.
session.invalidate();
response.sendRedirect("https://app:8552/cas/logout");
HEADERS
1st REQUEST - which invalidates session and redirect to CAS logout page
REQUEST HEADERS
Host: dev.service.net
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20100101 Firefox/7.0.1
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip, deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection: keep-alive
Referer: http://dev.service.net/
Cookie: JSESSIONID=53B9469EFE9F130E9694F7406BFAB755
RESPONSE HEADERS
Server: nginx/1.0.4
Date: Thu, 20 Oct 2011 09:20:45 GMT
Content-Type: text/html
Content-Length: 184
Location: https://dev:8552/cas/logout
2nd REQUEST - cas logout page itself
REQUEST HEADERS
Host: dev:8552
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20100101 Firefox/7.0.1
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip, deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection: keep-alive
Referer: http://dev.service.net/
Cookie: JSESSIONID=8A68F008825A0F0D14C6BF803E1332CF; GUEST_LANGUAGE_ID=en_US; COOKIE_SUPPORT=true
RESPONSE HEADERS
Server: Apache-Coyote/1.1
Pragma: no-cache
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Cache-Control: no-cache, no-store
Content-Type: text/html;charset=UTF-8
Content-Language: en-US
Content-Length: 1226
Date: Thu, 20 Oct 2011 15:53:57 GMT
3rd REQUEST - we are retuninig to the page which actually should
redirect us to login page, but it does not.
REQUEST HEADERS
Host: dev.service.net
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20100101 Firefox/7.0.1
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip, deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection: keep-alive
Cookie: JSESSIONID=53B9469EFE9F130E9694F7406BFAB755
RESPONSE HEADERS
Server: Apache-Coyote/1.1
Pragma: no-cache
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Cache-Control: no-cache, no-store
Content-Type: text/html;charset=UTF-8
Content-Language: en-US
Content-Length: 1226
Date: Thu, 20 Oct 2011 13:30:51 GMT
According to the headers, you're maintaining two different sessions on two different hosts. When you request a logout on the first host, you're redirected to the second host (which uses a different session cookie). The session cookie of the second host is in turn indeed invalidated (according to the presence of the Set-Cookie header). But based on the last request, the session has not been recreated on the server side (there is no Set-Cookie header). This means that session.invalidate() before response.sendRedirect() has failed somehow, or that the page is actually requested from the browser cache.
In Firebug you should be able to see if the page is requested from the browser cache by checking the text color of the request in the Net tab. If it's grayed out, then it means that it's been served from the browser cache. For Firefox, the must-revalidate header is actually mandatory next to the no-cache, no-store headers. You need to configure your server to add that entry to the header, or to change/create a Filter for that.
See also:
How to control web page caching, across all browsers?

Resources