I'm sure that this problem is just due to a missed configuration parameter and that there is a simple answer to this, but it is driving me insane. Everything works as expected on our development machines, but on our test server, we have the following problem...
We've got a Symfony2 (version 2.5.7) application. A controller sets a session variable to hold the ID of an entity. The app then fires off Ajax requests and the controller that receives the requests uses the session variable to decide what to send back.
In the main controller, we have (after checking that $page is a valid entity)
$this->get('session')->set('pageId', $page->getId());
and then in the controller that handles the ajax, we have
$pageId = $this->get('session')->get('pageId');
On loading the main controller, I can see that a session cookie has been set and it has the expected value for 'pageId'. I can see details of the session being stored in the app/session directory on the server, so I'm pretty certain that the session is being set correctly. The permissions are correct on this folder, so apache is allowed to read and write to it. But, the Ajax controller reports that $pageId is false. If I get the ID of the session;
$session = $this->get('session');
$session->start();
$sessionId = $session->getId();
I can see that the ID of the session matches the value in the cookie sent with the Ajax request, and matches a file called 'sess_{sessionId}' in the app/session directory.
What I am missing?
It turns out that manually deleting all files from the app/session directory solved the problem. I have no idea why, but it did solve it.
Related
I want to write a servlet with which I can create a new session.
The servlet requires the user to authenticate with BASIC authentication and returns the standard session cookie (using HttpServletRequest#getSession(true)). However, if the client uses the received session cookie in his next request instead of BASIC authentication it is not authenticated. The server recognizes the session but it doesn't contain the user information.
I'm using Tomcat and after a bit of debugging the reason is also obvious: the user information (Principal) is added to session upon authentication. However when the first BASIC authentication is taking place no session exists yet as this will be created by the servlet. Does anyone have idea how to solve this problem?
After one night of sleep [1] I believe I have come up with a working solution myself. The following snippet (using JAX-RS, but it shouldn't be too difficult to translate it to plain servlet code) does the trick if the calling client will follow redirects:
public Response getSessionCookie() {
boolean sessionExists = m_servletRequest.getSession(false) != null;
if (sessionExists) {
return Response.noContent().build();
} else {
HttpSession session = m_servletRequest.getSession();
return Response.status(Status.TEMPORARY_REDIRECT)
.header("Location",
m_uriInfo.getAbsolutePathBuilder().matrixParam("jsessionid", session.getId()).build())
.build();
}
}
The first request will create a session and redirect the client to the same address but with the session ID in the URL (which is important). The client will follow the request and send the same BASIC authentication data again but now it will be registered in the existing session. The second invocation of the method above will simply return an empty response with the session cookie that can now be used for subsequent requests.
Note that the session cookie is different for me in the second response but looking at Tomcat code this seems to be deliberate (successful authentication will always create a new session).
[1] Sleep is highly underestimated!
In ASP.NET MVC from one controller in one area I am using:
TempData["Model"] = model;
then RedirectToAction to pass the model to another controller in another area. In the controller action method I immediately pull the data back out of the model.
I am concerned that if I deploy to a web farm then TempData's use of session state will cause issues but am not sure if I can get away with it in this case because I immediately pull the model out of TempData again in the action method I pass to?
You are right to be concerned, a RedirectToAction sends the client a 302 message containing a url of the redirected resource. This is then the clients responsibilty to create a new request to the redirected resource. There is no guarantee this resource will be served by the original server. The fact that the request is pulled immediately from TempData makes no difference to this approach, at some point it is going to error.
You need to have some means of managing sessions. You could configure HTTP session affinity so that requests served from a server will always return to the originating server.
You could use cookies for session state or implement a session state provider.
This blog post is also a good start on the overview of the options.
If you are using InProc session state you might run into problems because in the redirect you could be sent to another server where the same session will not be available.
Two possible options are to either implement a cookie based TempData provider or switch to another session-state mode. Note that cookie based TempData is completely visible to users, though there are implementations where you encrypt the data.
Try with cooke based instead of session tempdata
See below link
http://volaresystems.com/Blog/post/2011/06/30/Sessionless-MVC-without-losing-TempData
Avoid the use of TempData all together. If you are sending your model in the redirection then use something like
RedirectToAction("MyAction", new {model = myModel});
public actionresult MyAction(model model)
{
/// Mode Code
return View(MyView, model);
}
Assuming that you controller action will take the model as parameter.
I have a simple SpringMVC v3.2.2 controller that does the following:
#RequestMapping(value = { "/login" }, method = RequestMethod.GET)
public String login(WebRequest request) {
request.setAttribute("myattr", "myvalue", SCOPE_SESSION);
}
I'm using the WebRequest object in order to save attributes in the session scope. The SCOPE_SESSION is an integer stating that I want to use it in the session scope. More info on the API is here:
WebRequest API
I assume that it means that I'm adding some attribute that will be saved in the session scope. Session, I assume, will be deleted when the server restarts, during my tests, because I don't want to have any session persisted locally. Unless some default configuration keeps it persisted.
For some reason, the session doesn't get deleted even after tomcat restart(I'm using Tomcat V7, default configuration), meaning that it is persisted for some reason. Tried to find more documentation explaining how to disable it, but could not.
What Am I missing ? if the attribute is saved in the session scope, as the API states, should it get deleted if I restart the Tomcat Server ?
Thanks in advance,
Elad.
I have edited the original question, which was not so clear. Sorry.
Problem solved. I totally missed that the session management is controlled by Tomcat.
The solution was to edit the Tomcat 7 context.xml configuration file and make sure it has the following element :
This disables the session persistence for good. Didn't really think that this is how it works by default. Thank you anyway.
How to get session value in code file while session is created in httphandler .it gives error like Object reference not set to an instance of an object.
The session is connected with a page request, to work is require to read the cookie of the user from the browser, or the url in case that is with out cookies.
So in the asp.net session if you do not have the httphandler, you can not have the session, because you can not know who is calling and see the page at that time.
Maybe in a custom solution session, you can send the session id to some other code with out the httphandler and use that id to read the session data, but the asp.net did not give this option.
I am using an HttpModule to open a session that span each request and it works great with lazy loading and everything.
My concern is that since I open a new session per request (and stores it in HttpContext.Current.Items) it opens a session for every request even request including request for .css files and images.
I recall reading that session creation is a pretty lightwheigt operation (dont know about transactions though) but anyway it seems unnecessary to open a session for a requests for a .css file?
Anyone got some ideas about this, is it a problem and/or am I doing something stupid?
Thanks in advance
only create the session object if the file type is .aspx or .ashx:
switch (context.Request.CurrentExecutionFilePathExtension.ToLower())
{
case ".aspx":
case ".ashx":
context.Items[ContextKey] = CreateMySession();
break;
}
or encapsulate session creation inside a property getter, and clean-up checks whether session != null