For one of our requirements I am talking between two servers using HTTP protocol. The interaction is long running, where a user might not interact with the other site for pretty long intervals.
When they come to the page, the log in into the remote site. Every time user tried to interact with the remote site, internally I make a HTTP call (authetication is done based on sessionId).
I was wondering if there is a way to also refresh the session and ensure that it does not expire.
As per my limited understanding, browser handles this by passing keep-alive in header or cookie (which I don't understand completely). Can anyone suggest a programmatic way in Java to achieve keep-alive behavior
1.
<session-config>
<session-timeout>-1</session-timeout>
</session-config>
Simply paste this piece if code in your deployment descriptor (DD).
If you want to keep your session alive for a particular duration of time replace -1 with any positive numeric value.
Time specified here is in minutes.
2.
If you want to change session timeout value for a particular session instance without affecting the timeout length of any other session in the application :
session.setMaxInactiveInterval(30*60);
**********************
Note :
1.In DD, the time specified is in minutes.
2.If you do it programatically, the time specified is in seconds.
Hope this helps :)
I guess below code can help you, if you can pass JSESSIONID cookie then your container will take responsibility to keep the session alive if its same session that might be created from some other browser.
find the link below that explained a lot.
Click Here
Code snippet from the link above
BasicCookieStore cookieStore = new BasicCookieStore();
BasicClientCookie cookie = new BasicClientCookie("JSESSIONID", "97E3D1012B3802114FA0A844EDE7B2ED");
cookie.setDomain("localhost");
cookie.setPath("/CookieTest");
cookieStore.addCookie(cookie);
HttpClient client = HttpClientBuilder.create().setDefaultCookieStore(cookieStore).build();
final HttpGet request = new HttpGet("http://localhost:1234/CookieTest/CookieTester");
HttpResponse response = client.execute(request);
Take a look of Apache HttpClient and see its tutorial. HttpClient supports keep alive headers and other features that should enable you to programmatically make an HTTP call.
Related
What steps do I need to take to implement user login?
I am using PUR & REST modules. I was able to successfully login using REST endpoint using MgnlContext.login, but if I try to access another endpoint I get 401.
What I have so far:
CredentialsCallbackHandler handler = new PlainTextCallbackHandler(username, password.toCharArray(), "public");
SecuritySupport securitySupport = Components.getComponent( SecuritySupport.class );
LoginResult result = securitySupport.authenticate(handler, SecuritySupportBase.DEFAULT_JAAS_LOGIN_CHAIN);
MgnlContext.login(result.getSubject());
I think I need to get session cookie (that's configured in web.xml) to send with any subsequent request, but where do I get it in the endpoint? And do I need to preserve it myself? Or is it something else entirely?
Both Magnolia and frontend run on localhost, but on different ports.
Magnolia was sending the cookie all the time (as Set-Cookie header), it just never got saved. I had to process it manually for my FE to set the cookie and send it back in every subsequent request.
Suppose in my Java app I do
Cookie myCookie = new Cookie("myCookie", "someValue");
myCookie.setMaxAge(3); // 3-seconds
When a cookie is sent in the response it must have an Expiration Date. My understanding is it will expire on CreationDate + 3 sec (maxAge). maxAge is the delta.
If I create a cookie at 1/1/2020 16:08:00, is its Expiration Date 1/1/2020 16:08:03 ?
Then who sets the original Creation Timestamp of the cookie, is it the constructor? How is the overall date tracked?
The cookie creation time is not stored in the cookie. The client keeps the cookie for the given time, starting when it receives the cookie.
In addition to what #JB Nizet said, clients can also update any cookie-related information it receives from the server's Set-Cookie response header.
Test it yourself in Chrome's Dev Tools, "Application" tab, there's a "Cookies" node in the left panel. For every domain, it allows you to see and/or modify any cookies you have stored in your browser. If you choose to update the "Expires/Max-Age" to a date in the past, the browser will automatically remove that cookie. You can also update it to sometime further out in the future.
Therefore, it's ultimately up to the server to know if a cookie is actually "valid." You should never rely on the max-age/expires data coming from the client to determine true validity. Clients use this to simply know when to delete it from it's local storage.
I am trying to learn how caching works in REST. I know all headers like Cache control, Max-age, Expires etc. I was going through example mentioned in this post.
What I know about Http cache is (I may be wrong), browser sends Http request to server, and if it has cache headers, browser will store the response in local cache. If client hits another request for the same response, browser will check the cache and if response is not expired, then it will return from cache instead of requesting to server.
Example given in this link, client hits server every time and server checks if client has expired copy or not. In this case, we hit server every time instead of retrieving data from cache.
Am I missing something here?
In mentioned post server side cache is used.
In other words:
RESTEasy Cache can avoid calling UserDatabase if it already contains requested User (by EntityTag key, based on user ID).
Everything is done on server side. It has no any connection with expire date/time request/response headers.
This might be of some help :
Cache response only for GET request when response is 200 OK,
Test environment : Jboss6.4 and maven 3.0
Dependency :
<dependency>
<groupId>org.jboss.resteasy</groupId>
<artifactId>resteasy-cache-core</artifactId>
<version>Any version after 3.0</version>
</dependency>
Code Changes : Add singleton for ServerCacheFeature in your application class.
singletons.add(new ServerCacheFeature());
Add this annotation to your function :
#Cache(maxAge=15, mustRevalidate = false, noStore = false, proxyRevalidate = false, sMaxAge = 15)
noStore can be use to enable/disable to cache resp
Even for me it seems quite odd to raise this question, as it contradicts my initial understanding.
Problem
Tomcat creates jsessionid on the first request (request1) and sends response (response1-with JSessionID) to the client. And client sends the same via cookies to the server on the next request (request2-with JSessionID). Now server understands that this is on the same session and responds, but the response doesn't contain JSessionID(response2-without JSessionID).
So now the client doesn't get any JSessionID, so the next request from that client seems to be a new one for the server, so server creates another session, which is wrong.
Relative Posts
http://lazyjavadev.blogspot.ie/2013/04/servlet-session-tracking-with-cookies.html
Why isn't getSession() returning the same session in subsequent requests distanced in short time periods? Under what conditions is a JSESSIONID created?
http://grokbase.com/t/tomcat/users/084pdye7fz/tomcat-not-sending-jsessionid-servlet-session-cookie-with-new-sessions
Attempted Solutions
Solution1
Add all cookies from the request to response - IT WORKS, but i think this is tomcat's job.
// Add cookies from request
Cookie[] cookies = req.getCookies();
if(cookies != null){
for (int i = 0; i < cookies.length; i++) {
resp.addCookie(cookies[i]);
}
}
Solution2
Add JSessionID cookie from client from the time of session initiation till session destruction (no matter whether server sends the session id in the response or not) - But this is a workaround and can't be the solution because clients are out of control in real time situation.
Question - ?
It's clear that tomcat maintain's session based on JSessionID via cookies or URL Rewriting or Hidden form fields. I have no special case like disableing cookies. Now the questions are
Why my tomcat doesn't send JSessionID on the subsequent response?
If that's a normal behaviour how tomcat maintains session integrity?
Or is it client's responsibility to send JSessionId cookiee to server untill the cookiee expires?
Thanks for your time in helping me.. :)
Architecture is midTier Liberty server that receives http requests and brokers to various back ends, some REST, some just JSON. When I configure for SSL (only thru envVars which is quite cool) ... it appears I get a full handShake w/every request. Additionally, the server side uses a different thread with each request (may be related). This is Liberty so it is multiThreaded. Servlet has static ref to POJO that does all apache httpClient work. Not using HttpClientContext (in this case). Basic flow is at end (struggling w/formatting for post legality)
EnvVars are:
-Djavax.net.ssl.keyStore=/root/lWasServers/certs/zosConnKey.jks
-Djavax.net.ssl.trustStore=/root/lWasServers/certs/zosConnTrust.jks
-Djavax.net.ssl.keyStorePassword=fredpwd
-Dhttp.maxConnections=40
Looked at many similar problems, but again, right now this flow does not use client context. Hoping I'm missing something simple. Code being appended on first response as I continue to struggle here w/FF in RHEL.
private static PoolingHttpClientConnectionManager cm = null ;
private static CloseableHttpClient httpClient = null ;
// ....
cm = new PoolingHttpClientConnectionManager();
cm.setMaxTotal(512);
cm.setDefaultMaxPerRoute(256) ;
httpClient = HttpClients.custom().setConnectionManager(cm).build() ;
// ...
responseBody = httpClient.execute(httpGet, responseHandler);
If a persistent HTTP connection is stateful and is associated with a particular security context or identity, such as SSL key or NTLM user name, HttpClient tries to make sure this connection cannot be accidentally re-used within a different security context or by a different user. Usually the most straight-forward way of letting HttpClient know that requests are logically related and belong to the same session is by executing those requests with the same HttpContext instance. See HttpClient tutorial for details. One can also disable connection state tracking if HttpClient can only be accessed by a single user or within the same security context. Use with caution.
OK, while I'm not exactly an expert at reading the ssl trace, I do believe I have resolved it. I am on a thread but that is controlled by the server. I now pass the HttpSession in and keep a reference to the HttpClientConnection that I now create for each session. I pool these HttpClientConnection objects (rudimentary pooling, basically just get/release). So all calls w/in an http session use the same HttpClientContext. Now it appears that I am NOT handShaking all the time. There may have been a better way to do it, but this does indeed work, I have a few gremlins to look into (socket timeouts in < 1 millisecond?) ... but I'm confident that I'm non longer handShaking with each request (only each time I end up creating a new context) ... so this is all good. Thanks,