We are experiencing issues with sudden logouts. It came with a version switch, previous application ran JSF 1.2 while this one runs JSF 2.1. Since this was a major refactoring any specific code changes are impossible to track. But a major update to code has taken place (all though mostly views and not beans).
We have control over every place were we invalidate sessions, they are logged and are not the cause.
We use a session-bean for authentication, it implements HttpSessionBindingListener.
We log valueUnbound and can tell that the logout was caused by end of life for the session. We are struggling to find the cause.
Tomcat 6.0.26 has been profiled and everything seems normal. This also occurs for small customers with little load.
<session-timeout>
Is appropriately set to 30 minutes.
<param-name>javax.faces.STATE_SAVING_METHOD</param-name>
<param-value>client</param-value>
Not sure this has any impact but they all use client.
We tried bypassing load balance but the problem still occurs.
How could randomly my session is null?
We tried the suggested flag, emptySessionPath but it didnt help.
Further we are not sure how to proceed with logging the request headers as suggested.
In our application I tried to kill the session-cookie for debugging reasons:
HttpServletResponse response = (HttpServletResponse) getFacesContext().getExternalContext().getResponse();
Map<String, Object> cookies = getFacesContext().getExternalContext().getRequestCookieMap();
Cookie cookie = (Cookie) cookies.get("JSESSIONID");
cookie.setValue("");
cookie.setPath("/");
cookie.setMaxAge(0);
response.addCookie(cookie);
Seems like it's either not destroyed or recreated. I also tried delete cookies in the browser while logged in, still no problem.
Would appreciate some concrete tips on how to debug this further? Basically now all we know is valueUnbound is called all of the sudden.
Tomcat 6.0.26
JSF 2.1.10
Cheers
Was embarrassingly enough one of the Filters after all. I guess that's what can happen when everyone assumes everyone else checked something
Related
I want to delete a cookie USERID in my liferay custom theme free marker templete
i am using liferay DXP
I tried this code
<#if !is_signed_in>
<#assign aCK=objectUtil("com.liferay.portal.kernel.util.CookieKeys") />
<#assign userID = aCK.getCookie(request,"USERID") />
<#assign VOID=aCK.deleteCookies(request, response,aCK.getDomain(request), "USERID") />
</#if>
</#if>
but give me null pointer exception becuase of i have null response !
can someone help me to try to do this ?
update:my main purpose is to delete specific cookie "USERID" when:
a-the user logout
b-the session timeout
for(a) i have done the first part by implementing logoutPostAction hook (because logout action don't clear cookies so i need to do this manually)
for (b) i tried to implement sessionDestroyAction hook but i don't have request and response to delete cookies only httpSession
so i turned to the solution of deleting cookies when the session timeout redirect me to the login page or home page so trying to do this in my custom theme .
i hope this update is clear to describe my problem, and try to help me how to solve my problem ?
You're doing some active work in the theme, but a theme is typically thought of being rather passive: It provides the look and feel of your application, not any additional business logic.
Consider moving code that modifies Cookies into a portlet - and there into the action phase, when you can change state and it's still early enough to write response headers to the resulting page. Once you render your theme, you're not guaranteed to be able to render HTTP headers (which you're trying to do for the Cookies). If the first bytes of the page have already been delivered to the browser while your freemarker theme gets to these lines, they'll still fail. And even if it looks like they'd work: they might fail only under load, when it's particularly hard to debug such an event.
Or, alternatively: What are you actually trying to do that caused you to come up with this solution? I can't see a problem that I'd solve with this solution - we might be able to help you with suggestions to solve your underlying problem if you name it.
Edit: On your edited problem B (as A seems to be solved): Setting cookies when the session expires: This won't ever work, by specification. Because the session expires server side, without the browser requesting anything (that's the reason why you don't have a request and response object: The browser might have gone offline or terminated half an hour ago - you are just not able to reach it at this point).
If your USERID is sensible and must not be on the browser after the session is ended: Don't store it in a cookie. Use if from the session (server side) and you're good to go. You're chasing a problem that can't be solved.
And never act solely on the cookie value - always make sure that it's not been tampered with.
I have a page which will send some ajax request to my Jetty7.6.9 server. All of them containing a COOKIE named JSESSIONID so that the server knows the request is logged in.
But sometimes, the method org.eclipse.jetty.server.Request.getCookies() returns an empty Cookie[]. I set a breakpoint and checked the _connection._requestFields and I found the Cookie right there, but Request.getCookies() cannot fetch it or parse it.
The situation can happen in any one or more ajax request in that page, can happen in any time, can happen in both windows and linux. It seems that it's a random case, and even when I dropped the frame at the breakpoint to the pre line, it would run correctly when it ran to the same place, so I think it's an issue about synchronize/concurrent.
I didn't find the same case in jetty bug list.
Is it a bug? What can I do to verify or repeat it? How to fix it?
(For some reason,maybe I cannot update the Jetty version for our system.)
I'm developing an Ajax Web Application with Grails 2.2.3 Backend on a Tomcat 7 Servlet Container. As I ran the application with grails run from my IDE everything worked like a charm (i use the tomcat-grails-plugin which is providing a Tomcat 7 implementation).
Now if I deploy my Application to a standalone Tomcat 7 I'm not able to work with the HttpSession anymore as Tomcat is creating a completely new session on every single Ajax request which makes it impossible for me to work with the session object anymore. As I guess that I'm not the only one who deploys an Ajax Application at a Tomcat 7 I wanted to ask here if anybody could give me some advice on how to solve this problem?
Is the great invention of preventing Session Fixation by making it impossible to work with Session at all?
I still want to be able to use HttpSession in the way it was meant to be, with this behaviour the idea of a Session gets ad absurdum (in my opinion) if I can't save session related data to it...
Am I seeing something wrong? Am I doing something wrong?
UPDATE
After some research I found out that only a POST request triggers the creation of a new session in Tomcat... can anybody explain this behaviour?
After some more research (even through the source code of the authenticator classes (http://svn.apache.org/repos/asf/tomcat/tc7.0.x/trunk/java/org/apache/catalina/authenticator/)) I realized that it has to do something with the Realm declared in the server.xml file which affects all other webapps in the same [engine]/[host] and is there by default to be used with the Tomcat Manager.
As long as I only send GET request everything works well, but if I send a POST request a new Session is created but as I'm not changing the page I'm on (since it's a so called "single page application" I'm always on the same index.gsp page) Tomcat treats it as a failed login attempt and keeps on creating new Session objects for every POST request - and there are a lot of POSTs on my page ;)
So, as a quick fix I removed the manager from the webapps directory and removed the Realm declaration from the server.xml as I'm already creating a new Session on a successful login attempt at my Grails backend myself.
There are plenty of examples of similar problems littered around the web but none of their solutions seem to fix this particular variation. Any suggestions would be appreciated.
Usually this problem occurs because a rogue link is causing a request for a resources like a favicon or css file to hit the dispatcher more than once, thus causing multiple dispatch processes and therefore multiple rows in your database.
I have checked that all the links on this very simple example page do actually resolve to the resource to which they point.
The session handler is setup as follows:
Zend_Db_Table_Abstract::setDefaultAdapter($db);
Zend_Session::setSaveHandler(new
Zend_Session_SaveHandler_DbTable($config->session->toArray()));
The db logging is setup as follows:
$writer = new Zend_Log_Writer_Db($db, $config->log->tableName,
$config->log->columnMap->toArray());
$logger = new Zend_Log($writer);
Both objects are correctly setup and can read and write to and from the database. Only everything happens twice. If I put a test log message anywhere in the application it is written into the database twice. If I increment three variables with every call to the index action - one stored in the session, one passed around via a Zend_Registry object and another local to the indexAction - only the session variable is incremented by 2. The Apache access log shows the correct amount of requests being fired from the page load and all have good response codes of either 200 or 304 (unchanged).
I have tried disabling all head links.
I have tried disabling the layout entirely.
I have localised everything to the dispatcher and exited before dispatch is run.
In all cases the extra write/increment takes place.
Any thoughts?
Thanks in advance for any help.
I seem to have found and fixed the issue. Chrome (and possibly all Webkit browsers) issues an additional HEAD request on top of the GET which means the application is hit twice and anything session based will be triggered as a result of both requests. My temporary solution is to put the following code near the start of my index.php file.
if ("HEAD" == $_SERVER['REQUEST_METHOD']) {
exit;
}
I hope that helps anyone with the same issue.
Google Chrome always asks for the favicon.ico by making annoying requests to the server. Take care about this in Chrome.
For more information:
http://framework.zend.com/issues/browse/ZF-11502?page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#issue-tabs
Thanks to the Sebastian Galenski contribution.
I'm using Zend Framework for PHP and handling sessions with the Zend_Session module. This is what I have in my Initializer (or bootstrap):
Zend_Session::start();
Zend_Session::rememberMe(864000);
864000 seconds should be good for 10 days, but I'm still being kicked out at about an hour (or maybe a little less). I've tested to see if this statement works at all by setting it to 10 seconds, and indeed I am kicked out at the appropriate time, but when I set it to a very high value, it doesn't work! I went through some of the documentation here:
http://framework.zend.com/manual/en/zend.session.html
Another method I saw was to use the following:
$authSession = new Zend_Session_Namespace('Zend_Auth');
$authSession->setExpirationSeconds(3600);
Now, I have different namespaces. Does this mean I have to set this for all of them if I want to keep them from expiring? I haven't tested this method of setting the expiration, but I really wanted to see what the gurus on here had to say about what the correct way of approaching this problem is. Thanks a lot guys...
Also, does anyone know how I can make it so that the session never expires? I've tried setting the second to 0 and -1, but that throws an error.
I had the same problem and solved it by putting:
resources.session.save_path = APPLICATION_PATH "/../data/session/"
resources.session.gc_maxlifetime = 864000
resources.session.remember_me_seconds = 864000
in the application.ini (as suggested by tawfekov) and
protected function _initSessions() {
$this->bootstrap('session');
}
in the Bootstrap.php (this I typically forgot at first). You have to give the session directory the correct access rights (chmod 777). I described the issue here. Hopefully this will help the next person with the same issue.
Your client's computer clock, date, AND time zone need to be set correctly for session expirations to work. Otherwise the time conversions are off, and likely causing your cookie to expire the minute it hits the their browser.
Try calling remember me before starting the session:
Zend_Session::rememberMe(864000);
Zend_Session::start();
Otherwise I believe it will use the default of remember_me_seconds. See 49.4.4. rememberMe(integer $seconds)
Also, does anyone know how I can make
it so that the session never expires?
I've tried setting the second to 0 and
-1, but that throws an error.
I don't think that is possible. The session is controlled by whether the cookie exists on the users computer. Those cookies can be deleted, even by the users if they clear their cache. I think the best you can do is set it to a very large number. Say 12 months.
I guess you are using ZF 1.8 or above ,
so you can put in the config.ini file
resources.session.save_path = APPLICATION_PATH "/../data/session"
resources.session.remember_me_seconds = 864000
and these setting will automatically loaded
again only in ZF 1.8 or above if not you had to load these config manually
i hope it helps you :)
Are there other PHP applications running on the server?
Assuming you're using the standard, file-based, session handler, PHP will store all sessions in the same place (typically /tmp).
If you have some other script on the server using the default session_gc_maxlifetime settings, it may be eating your session files.
The easiest fix to try is to configure PHP to store session files for this application someplace special -- that way other apps running on the server will never accidently "clean up" session data from this app.
Try creating a directory like /tmp/myAppPhpSessions (or whatever), and adding:
ini_set('session.save_path','/tmp/myAppPhpSessions');
ini_set('session.gc_maxlifetime', 864000);
at the very top of your bootstrap file.
Make sure session.auto_start is off in php.ini