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.
Related
Our vaadin 6 application runs in a browser pop up window provided by another web app. However, that web app is not aware of when our application is completed so the responsibility to close the browser pop up is on us. We did that in the vaadin 6 by using setLogoutURL method to redirect to another servlet after vaadin application is closed and run JS command window.close() from that servlet. I didn't find similar concept of setLogoutURL in vaadin 8. What is the replacement for that in the same scenario? Basically, I am looking for a hook that can run a JS command to close the browser pop up after vaadin UI is properly closed. I am assuming the following code will not work.
myUI.close();
JavaScript.getCurrent().execute("window.close()");
// let this thread go back to vaadin framework here
Because the close() and execute() may be in a race.
In Vaadin 8 the best practice for logout procedure is indeed different. You should invalidate http session via Vaadin session and after use set location with logout url.
vaadinSession.getSession().invalidate();
ui.getPage().setLocation("");
I found that the solution given in Answer 1 is not completely correct. When running the code given in the solution, an internal error occurs. The following code will work, basically not invalidate the session but only setLocation.
ui.getPage().setLocation("page1");
ui.close();
So the replacement of vaadin 6 setLogoutURL() is ui.getPage().setLocation("page1") in vaadin 8.
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
I got few doubts on sessions in JSF and/or in general.
First up, does session gets created on load of an web app in AS/servlet container? Meaning, after I do right click- run as - run on server and the app is started and synchornised?
Or does it get created after the web app is loaded and the defined welcome page is displayed and then the client makes a request?
Second: I was looking into the issue of "Cannot create a session after the response has been committed" in jsf.
I was trying to reproduce the issue by doing this given in the following site,
http://java.net/jira/browse/JAVASERVERFACES-2215
But, I didnt get any error as mentioned above. I tried with all bean scope.
Was the session created?
This is the code.
<h:body>
<h:form id="test">
<p:growl id="msg"></p:growl>
<h:outputText value="#{myTestBean.exceedBuffer}" />
</h:form>
</h:body>
bean code is.
public String getExceedBuffer() {
int size = FacesContext.getCurrentInstance().getExternalContext().getResponseBufferSize();
char[] chars = new char[size];
Arrays.fill(chars, 'x');
return new String(chars);
}
My understanding is the following,
First when the app is loaded the servlet container or an AS creates a session and a sessionID(JSESSIONID) and puts it in server memory. So the initial page gets loaded up anyhow, meaning even if the response buffer is overflowed or not but the session wont be created. Now, when the client makes a request on this page, since the session was not created, the error occurs. But, I tried even doing this by
<p:commandButton actionListener="#{myTestBean.onSelect}" update=":test"></p:commandButton>
and in onSelect method just entered a dummy code. Even now the page displayed as usual.
Well, that was when I was completely lost. Can someone pls help me on this? Thanks in advance.
First up, does session gets created on load of an web app in AS/servlet container? Meaning, after I do right click- run as - run on server and the app is started and synchornised?
Or does it get created after the web app is loaded and the defined welcome page is displayed and then the client makes a request?
It's created on start of the HTTP session, not on webapp's startup (that's the application scope). Basically, when request.getSession() is called for the first time and the HttpSession hasn't been created yet. This all is handled by the Servlet API which JSF is using under the covers. So the following answer should help in understanding how it works: How do servlets work? Instantiation, sessions, shared variables and multithreading
Second: I was looking into the issue of "Cannot create a session after the response has been committed" in jsf.
I was trying to reproduce the issue by doing this given in the following site, http://java.net/jira/browse/JAVASERVERFACES-2215
But, I didnt get any error as mentioned above. I tried with all bean scope. Was the session created?
You will get this error when the HttpSession isn't created yet at the moment the response is committed. That you didn't get this error can only mean that the session has already been created beforehand. You need to test it on a freshly started webapp and the session shouldn't be created yet. Note that some servers by default stores sessions on shutown/restart. You'd need to disable this or to remove the JSESSIONID cookie in your browser before sending the first request on this test page. Restarting the webbrowser or using a different one should also force a fresh new session.
i already posted this question but still wasnt able to resolve this issue.
seems that everyone has this problem with codeigniter .
When i set my session in a controller it works perfectly and i can display it.
WHen i move to another controller, the (CUSTOM) session data is completely lost.
i tried changing my cookie_domain in config.php. Since i am on localhost i tried localhost with without / and localhost/codeigniter and sodeigniter all did not work. i am lost
btw, i read somewhere that this happens when 2 ajax requests happen at the same time. could that be the problem?
Or maybe tell me how you resolved the problem if you had same issues
screw this, i am swithing to php native sessions. if anyone wants to do that,
http://codeigniter.com/wiki/PHPSession
Check and double-check your code or any external libraries you are using for a stray sess_destroy(). I ran into a similar problem where I was storing an id in the session for reference but if the user then logs in the SimpleLogin library I was using for logins just destroys the entire session including data I did not want to lose.
This is what I get for not writing my own code.
I'm trying to set up an MVC application that will service several facebook applications for various clients. With help from Prabir's blog post I was able to set this up with v5.2.1 and it is working well, with one exception.
At first, I had only set up two "clients", one called DemoStore and the first client, ClientA. The application determines what client content and facebook settings to use based on the url. example canvasUrl: http://my_domain.com/client_name/
This works for ClientA, but for some reason when I try any DemoStore routes I get a 500 error. The error page points to an issue with the web.config.
Config Error:
Cannot add duplicate collection entry of type 'add' with unique key attribute 'name' set to 'facebookredirect.axd'
I am able to add additional clients with no problem, and changing DemoStore to something like "demo" while using the same facebook application settings works fine also.
Working calls:
http:// localhost:2888/ClientA/
http:// localhost:2888/ClientB/
http:// localhost:2888/Demo/
Failing call:
http:// localhost:2888/DemoStore/
I was thinking this might be an MVC issue, but the Config Error points to the facebookredirect handler. Why would the SDK try to add this value to the config during runtime, and only for this specific client?
Any insight would be greatly appreciated.
I managed to figure out what went wrong here. Silly mistake..
After I had set up the application routes to require the client_name I changed the Project Url in the project properties to point to demostore by default. When I hit ctrl+S a dialog popped up that I promptly entered through without reading.
When I changed the Project Url, IIS Express created a new virtual directory for the project. This was the source of my problem. Why? I'm not sure, but once I removed the second site from my applicationhost.config I was able to access the DemoStore routes.
Moral of the story: read the VS dialog messages!