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.
Related
Context: I have an application which communicates with a server of the owner. This application requests certain information from the server by accessing some URL's. I don't know these URL's, except for a few, but once I know them, I can manually visit them in the browser and obtain said information.
Goal: Figuring out the URLs of those requests, i.e., what are the requests being made by the application when I'm using it, so that I can, in the future, make them manually myself.
Progress:
Since the communications are in HTTPS, reading the packets with Wireshark while using the application was unsuccessfull since they are encrypted.
However, I was able to find where in the binary of the application is the URL of the server located. Thus, I can theoretically redirect the requests of the application to any other server. Hence, I thought a good idea to be able to receive the unencrypted requests would be to set up a proxy server, redirect the application to it, and then execute the application and obtain the results.
Problem: I don't know how to implement this idea in practice though, and it is here where I'd appreciate your help. I suppose that, ideally, I would be able to both receive the requests made by the application (and thus read them), as well as redirect them to the server and read the received information.
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
Our Spring application is running on several different servers. For one of those servers POST requests do not seem to be working. All site functionality that uses GET requests works completely fine; however, as soon as I hit something that uses a POST request (ex. form submit) the site just hangs permanently. The server won't give any response. We can see the requests in Tomcat Manager but they don't time out.
Has anyone ever seen this?
We have found the problem. Our DBA accidentally deleted the MySQL database files on that particular server (/sigh). In our Spring application we use GET requests for record retrieval and the records we were trying to retrieve must have been cached by MySQL. This made it seem as if GET requests were working. When trying to add new data to the database, which we use POST requests to do, Tomcat would wait for a response, which never came, from MySQL.
In my experience if you're getting a timeout error it's almost always due to not having correct ports open for your application. For example, go into your virtual machine's rules and insure port 8080, 8443 or 80, 443 are open for http and https traffic.
In google cloud platform: its under VPC networking -> firewall rules. Azure and AWS are similar.
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.