HttpServletRequest's getSession(boolean) method mentions session integrity. How does Tomcat maintains session integrity? What rules does it use? What method? What is happening under the hood precisely?
EDIT
How and when is a specific session ID is created? Does Tomcat rely on IP address and port for example?
In Tomcat the ManagerBase.generateSessionId() method is responsible for session id generation. It looks for me that session ids are generated based on random numbers. You can store the client's IP address in the session and check it in your webapp but as far as I know Tomcat does not do that.
About session integrity: could you define it, please? There is a paragraph about it in the Java Servlet Specification, Version 3.0 but it isn't too much:
7.1.4 Session Integrity
Web containers must be able to support the HTTP session while
servicing HTTP requests from clients that do not support the use of cookies. To
fulfill this requirement, Web containers commonly support the URL rewriting
mechanism.
This blog gives some details on Session Tracking with cookies with Tomcat.
Related
I am creating a JSF application deployed in Tomcat/EE (with CLIENTCERTs). By default, the jsessionid (generated with a SecureRandom, so it looks safe) was set in the URL, which I disabled for security reasons by changing the SessionTrackingMode.
Now I am trying to find the security advantages/disadvantages of using:
<tracking-mode>SSL</tracking-mode> vs. <tracking-mode>COOKIE</tracking-mode>
(considering security almost always has an impact on performance and other variables). Probably one of the problems is that I do not know what SSL tracking-mode exactly does. This API documentation is not very clear.
When should I use one or the other?
PS: I know this is not specific of Tomcat or JSF but I need to give context to the question
I would recommend the use of cookie-based session-tracking over SSL session-tracking for a few reasons:
Using SSL session-tracking may prevent explicit (user-initiated) logouts
Using SSL session-tracking may prevent sessions from being terminated due to inactivity-timeouts
Using SSL session-tracking may cause unexpected logouts (due to TLS renegotiation, which changes the TLS session-id)
Using SSL session-tracking will make it harder to debug, troubleshoot, and generally manipulate your own application if necessary (telling a client to clear their cookies is easier and less arcane than asking them to expire their TLS session-ids)
FWIW, IBM WebSphere has dropped support for SSL-based session-tracking as of version 7.0 (circa 2008).
I don't see any advantage to using SSL-based session-tracking.
I would like to add some details to #Christopher Schultz's answer.
If your application is not using client certificates, then it might be more convenient to use cookies. The reason is potential invalidation of sessions as Christopher pointed out. I have not tested this, though, it is just a theoretical impression.
If client certificates are used, I have verified that tracking sessions via SSL connections is completely valid. I have been doing this for a while and I have not found any problem, nor unexpected error/logout, nor tedious process for users to have to login again. In my opinion, in some situations SSL might even be a cleaner way to keep
sessions. Note that developers might have to keep some security
considerations when using cookies (e.g. HttpOnly, cookie secure
flag...). I am not saying this is a reason to choose SSL
tracking, since developers might have to keep some security
considerations with SSL tracked sessions too, I am just saying I am
not currently aware of them, while I am aware of the cookie ones.
If you opt for SSL tracking and you are using JSF (Java EE) and e.g. #ViewScopeds, then you will have problems when using the insecure HTTP, because JSF will not be able to track the session if no TLS/SSL is in place. So if you need JSF with scopes that need tracking the session, and need HTTP access to your application, then you should go for COOKIE tracking. On the other hand, if you always use HTTPS, or have no need to e.g. #ViewScoped, then SSL tracking is totally fine.
For the application server set as clustering in glass fish. I have sent request through jmeter and all the requests hits to only one server . Expected was requests should be distributed to multiple servers in the cluster. But if sent requests manually clustering is working. Please help to sort out this issue
There could be different clustering load balancing mechanisms, as far as I can see from the GlassFish Server High Availability Administration Guide:
Cookie Method
The Loadbalancer Plug-In uses a separate cookie to record the route information. The HTTP client (typically, the web browser) must support cookies to use the cookie based method. If the HTTP client is unable to accept cookies, the plug-in uses the following method.
Explicit URL Rewriting
The sticky information is appended to the URL. This method works even if the HTTP client does not support cookies. To implement explicit URL rewriting, the application developer must use HttpResponse.encodeURL() and encodeRedirectURL() calls to ensure that any URLs in the application have the session information appended to them.
So depending on your Load Balancer configuration you need to
Either define either different cookies in the HTTP Cookie Manager
Or make sure different threads send requests to different URLs i.e. via HTTP URL Re-writing Modifier
In any case it is recommended to add DNS Cache Manager so each virtual user would resolve the underlying IP address of the application under test on its own.
I'm writing a web client that needs to deal with lost connection.
If you are connected to a server using HTTPS and Internet connection drops, will the server lose the session information?
Once Internet connection is restored, does the client need to re-login to the server or does it depend on the server?
Usually the server determines how long a session lives (by defining a session timeout) and how a session (if at all) is persisted between single requests. The server sends a cookie with the session information (a session key) back to the client, so when the client sends the next request including the session cookie, the server knows which session to use.
Having said is - there is no information between two requests, whether the internet connection was lost in the meantime. As long as the server still has the session and the client still has the corresponding cookie, everything should work as expected.
On the other hand, even if there was no interrupt in the connection at all and both server and client were up and running, but without talking to each other (i.e. without requests), the session might be lost because of a simple timeout on the server side.
So on the server you might receive requests for resources that are secured or need a certain session state - and there is no such session. And on the client side you always might receive responses that indicate that a login is necessary.
Both cases must be implemented properly.
The HTTP protocol itself is stateless i.e. each request is served as is without any relation to previous of future requests.
To overcome this you can use client Cookies. Your cookie can keep a session state identifier which can be sent back to the server after a connection drop to resume the previous state.
In addition to that you can build a session management module which handles session persistence.
first it depends on the type of session you are talking:
ssl session
This can cause an shortend renegotiation. If the Server support it.
That mean it save CPU time.
http sessions
here it does not only depend on the server but also on your web page code.
For example if the session drop's while delivering the page conntent.
The servlet receive an connection reset during flush and may invalidate the session.
Also id depends if the session is bound to the ip adress. Than it depends if the
new connection use the same ip adress.
There is no simple answer as you maybe expected. Since it depends on to many points.
As the others already stated you can "persist" a connection by using a SessionID, which is recommended to be stored in a cookie. Most of the modern Environments like PHP and ASP.NET use this mechanism which can deal with lost connections.
Please refer to https://www.owasp.org/index.php/Session_Management_Cheat_Sheet for security considerations for implementing a secure Session Management.
Additionally what you can do with SSL is to build the Session Management using client certificates. The user is identified by the unique certificate which is issued to him. This has the advantages that the client does not have to login first. On the other hand you have to issue a client cert to every client, which might be complex.
Use cookies to store the session information, once connection is lost you can easily get the information from the cookies. call the cookies using condition i.e. if session lost call for the cookie. use Php to store information in the session and call the cookie
I am using redirectAttributes to pass success or failure messages to redirected url. So that I can show the success or failure message on the redirected page only once. If the same page is refreshed again then the message will not come up again. This is ok and working fine in normal deployment on tomcat.
Now we have setup a clustered environment where we have deployed the web application. But in this case the redirectAttributes are working weirdly. Sometimes it works and sometimes not.
Following is the line of code I am using to add flashAttribute to the redirect attributes.
redirectAttributes.addFlashAttribute("successMsg", message);
I am using Spring 3.1.0.RELEASE version and Tomcat 7 for clustered environment.
I want to know whether there is any workaround for this problem. Does any newer Spring version supports the use of redirectAttributes in clustered environment?
Also you can let me know if there is another way to perform this kind of stuff.
Thanks in advance.
It sounds like your HTTP sessions for a client may not be shared between the Tomcat servers. Since the Spring Flash attributes are stored in the session, you may be experiencing the following:
Initial request goes to serverA, and a flash attribute is set in the session on serverA
A redirect occurs, and the request gets sent to serverB. serverA and serverB have different HTTP sessions for the user (assuming you have no mechanism to share them), so serverB does not see the flash attribute (it has it's own separate HTTP session)
You could experience this problem intermittently if the server to which a client request gets sent is non-deterministic. For example, if both of the above described requests happen to go to serverA, then the flash attribute would work correctly, since the session would be the same.
If this is the case, then you need a mechanism to either:
Provide a 'sticky' session -- guarantee that all requests for a given client get routed to the same Tomcat server. Usually this is accomplished via a load-balancer / routing mechanism (example: nginx ip hash routing)
Implement session replication -- make sessions shared across all Tomcat servers, so that regardless of which Tomcat serves the request for a client, the HTTP session will be the same.
What is the difference between session affinity and sticky session in context of load balancing servers?
I've seen those terms used interchangeably, but there are different ways of implementing it:
Send a cookie on the first response and then look for it on subsequent ones. The cookie says which real server to send to.
Bad if you have to support cookie-less browsers
Partition based on the requester's IP address.
Bad if it isn't static or if many come in through the same proxy.
If you authenticate users, partition based on user name (it has to be an HTTP supported authentication mode to do this).
Don't require state.
Let clients hit any server (send state to the client and have them send it back)
This is not a sticky session, it's a way to avoid having to do it.
I would suspect that sticky might refer to the cookie way, and that affinity might refer to #2 and #3 in some contexts, but that's not how I have seen it used (or use it myself)
As I've always heard the terms used in a load-balancing scenario, they are interchangeable. Both mean that once a session is started, the same server serves all requests for that session.
Sticky session means that when a request comes into a site from a client all further requests go to the same server initial client request accessed. I believe that session affinity is a synonym for sticky session.
They are the same.
Both mean that when coming in to the load balancer, the request will be directed to the server that served the first request (and has the session).
Sticky session means to route the requests of particular session to the same physical machine who served the first request for that session.
This article clarifies the question for me and discusses other types of load balancer persistence.
Dave's Thoughts: Load balancer persistence (sticky sessions)
difference is explained in this article:
https://www.haproxy.com/blog/load-balancing-affinity-persistence-sticky-sessions-what-you-need-to-know/
Main part from this link:
Affinity: this is when we use an information from a layer below the application layer to maintain a client request to a single server. Client's IP address is used in this case. IP address may change during same session and then connection may switch to different server.
Persistence: this is when we use Application layer information to stick a client to a single server. In this case, loadbalancer inject some cookie in response and use same cookie in subsequent request to route to same server.
sticky session: a sticky session is a session maintained by persistence
The main advantage of the persistence over affinity is that it’s much more accurate, but sometimes, Persistence is not doable(when client dont allow cookies like cookie less browser), so we must rely on affinity.
Using persistence, we mean that we’re 100% sure that a user will get redirected to a single server.
Using affinity, we mean that the user may be redirected to the same server…
They are Synonyms.
No Difference At all
Sticky Session / Session Affinity:
Affinity/Stickiness/Contact between user session and, the server to which user request is sent is retained.