We are deploying our Java web app on Weblogic 12c (12.1.2.0.0). The value of the JSESSIONID cookie differs from the value in the server. The cookie has not the last part. This causes an error in one of our methods.
The value of the cookie:
1lPNJjJR-izDn1LQy8Lo69_jujcgCcBtPPCz9jS9zVkE2N4_m5JM!1969913142
And the value on the server for the same session:
1lPNJjJR-izDn1LQy8Lo69_jujcgCcBtPPCz9jS9zVkE2N4_m5JM!1969913142!1493733119155
The last exclamation mark and the following value are not present in the cookie.
We are aware of this format but why does not Weblogic send whole value?
Is this on purpose (a security measure for session fixation) or have we configured something wrong?
The session is identified by the part before the first exclamation point.
The values after the excalamation point are references to the WebLogic server that owns the session.
You can have up to three values after the first exclamation point depending on the replication of the session. These values can change via Set-Cookie header when the primary/secondary servers shuts down.
Related
I have a JSF application that uses Mojarra 2.2.9
and is deployed on WebSphere 8.5.5.4 on clustered environement
and javax.faces.STATE_SAVING_METHOD is set to client.
Even though all my application beans are request scoped, sometimes when the user session is valid and the user is doing post request on a page he gets ViewExpiredException. What may be causing this issue and how can I solve it?
Will changing the javax.faces.STATE_SAVING_METHOD to server solve it? If so, what is the impact of doing this on memory?
Also, does this have anything to do with cluster environement and maybe there's some missing configuration on the Websphere that will solve the issue?
This will happen if the client side state is encrypted by one server and decrypted by other server and the servers don't use the same AES key for this. Normally, you should also have seen below warning in server log:
ERROR: MAC did not verify
You need to ensure that you have set jsf/ClientSideSecretKey in web.xml with a fixed AES key, otherwise each server will (re)generate its own AES key during startup/restart (which is used during encrypting view state).
<env-entry>
<env-entry-name>jsf/ClientSideSecretKey</env-entry-name>
<env-entry-type>java.lang.String</env-entry-type>
<env-entry-value>[AES key in Base64 format]</env-entry-value>
</env-entry>
You can use this snippet to generate a random AES256 (32bit) key in Base64 format.
KeyGenerator keyGen = KeyGenerator.getInstance("AES");
keyGen.init(256); // Use 128 for 16bit key.
String key = Base64.getEncoder().encodeToString(keyGen.generateKey().getEncoded());
System.out.println(key); // Prints AES key in Base64 format.
In case you get Java Security: Illegal key size or default parameters? error, install the cryptography extension as instructed in the link, or else generate a random AES128 (16bit) key instead.
After having the key, make absolutely sure you don't publish/opensource your key.
Further you also need to ensure you have added <distributable /> tag to web.xml so JSF will perform more agressive session dirtying and the HTTP sessions (including view scoped beans themselves!) are properly synced across servers.
Another probable cause of ViewExpiredException with client side state saving is that you've set the Mojarra-specific context param com.sun.faces.clientStateTimeout in web.xml which represents the time in seconds before an incoming client side state is considered expired. This is however unlikely the case here as that context param has a rather self-explaining name which you would have spotted by just glancing over web.xml.
See also:
com.sun.faces.ClientStateSavingPassword - recommendations for actual password?
javax.faces.application.ViewExpiredException: View could not be restored
You must have the distributable tag in your web.xml as mentioned by balusc
I enabled user authentication on Node Red. but when I restart the service the user is still logged in
I have done some searches. there is some suggestions around changing the machine key every time the service restarts.
does anyone have any suggestions about what exactly should I do ?
As mentioned in the docs on securing Node-RED the authentication tokens generated last for 7 days.
You can change this by editing the settings.js file
The expiration time can be customised by setting the sessionExpiryTime
property of the adminAuth setting. This defines, in seconds, how long
a token is valid for. For example, to set the tokens to expire after 1
day:
adminAuth: {
sessionExpiryTime: 86400,
...
}
EDIT:
The session tokens on the backend are (when using the default storage plugin) stored in a file called .sessions.json in the userDir (as logged on startup). If you want to log out all users on a restart then you will need to delete this file before starting Node-RED.
Hi i have a Redis configured on my Spring project to use Spring Session, i'm using Jedis 2.9.0 and it works well. The problem I have is with the Sticky session on the Websphere Server, we have 2 main servers and 10 clones of each, with normal httpSession it uses the cookie to handle the request of that cookie to the same server again, good, but with Spring Session it doesn't work the same.
Spring create the cookie with the name "SESSION" and the Load Balancing of Websphere doesn't know where to redirect the request because the session is not on the JVM but is ditributed in Redis Cluster.
i need to (for log order porpuse) handle every request of cookie "abc123" to the server 1 clon 3 for example, and if that instance of the application goes down track that cookie to another instance and stay on that instance until the server goes down again or the user logout...
Searching here and the Spring Session doc, i found something that might be useful but I dont know how it works.
#Bean
public CookieSerializer cookieSerializer() {
DefaultCookieSerializer serializer = new DefaultCookieSerializer();
serializer.setCookieName("JSESSIONID");
serializer.setCookiePath("/");
serializer.setDomainNamePattern("^.+?\\.(\\w+\\.[a-z]+)$");
serializer.setJvmRoute("123");
return serializer;
}
The atribute Jvm Route adds a suffix to the cookie to know whats the JVM that handle that cookie, but i don't know how it works and I haven't been lucky finding examples or explanation about it.
if anyone have the answer or another workaround that i could use it will be great.
We have developed an application where after a successful request, session has to be destroyed. This is working fine, when we have a single tomcat.
But, this is not happening when we use multiple tomcats under Apache simple load balancer (We are using Load Balancer, for balancing the requests between two tomcats, which are hosting the same application).
The SessionID that is created and have processed successfully, can be used for one more transaction, after which it is getting killed.
Moreover, the SessionID value is being appended with either 'n1' or 'n2' (SessionID-n1). I am not sure of why is this happening.
Please help me to resolve this issue.
We have a configuration setup as below:
Load Balancer
/ \
Cluster1 Cluster2
| |
Tomcat1 Tomcat2
Thanks,
Sandeep
If you have configured each Tomcat node to have a "jvmRoute", then the string you specify there will be appended to the session identifier. This can help your load-balancer determine which back-end server should be used to serve a particular request. It sounds like this is exactly what you have done. Check your CATALINA_BASE/conf/server.xml file for the word "jvmRoute" to confirm.
If you only use a session for a single transaction, why are you bothering to create the session in the first place? Is a request == transaction?
If you are sure you are terminating the session when the transaction is complete, you should be okay even if the client wants to try to make a new request with the same session id. It will no longer be valid and therefore useless to the client.
It's not clear from your question whether there is an actual problem with the session because you claim it is "getting killed" which sounds like what you want it to do. If you provide more detail on the session expiration thing, I'll modify my answer accordingly.
I am working on session replication with two server instances in a cluster.
Session id is not getting replicated to the second server and hence it always creates a new one, and my open application gets errored out and gets closed. How to handde this failover of server instance so that the user will not be aware if the server instance is down. Here are the settings i am using in weblogic.xml
<?xml version="1.0" encoding="ISO-8859-1"?>
<weblogic-web-app xmlns="http://www.bea.com/ns/weblogic/weblogic-web-app">
<session-descriptor>
<session-param>
<param-name>URLRewritingEnabled</param-name>
<param-value>true</param-value>
</session-param>
<session-param>
<param-name>PersistentStoreType</param-name>
<param-value>replicated</param-value>
</session-param>
</session-descriptor>
<context-root>#CONTEXT_ROOT#</context-root>
</weblogic-web-app>
Now that you know that going to the app server directly does not alleviate appear to alleviate your session id issue, you need to do deeper debugging:
Install Firebug in Firefox (https://getfirebug.com/)
Go to your website in Firefox
Turn on Firebug in Firefox (and make sure that the Firefox's Net tab, which might be grayed-out, is enabled)
Log in to your website
Look at the Net tab in firebug and expand the plus sign for the request.
Look at the Request Headers section -- Do you see anything in the cookie field that looks like the JSESSIONID? If so, does the JSESSIONID stay the same or does it change when you navigate to other pages on your site?
I'm attaching a screenshot of using Firebug to look at the cookie that gets set and re-sent on every request when you have logged in to the weblogic admin console for comparison (rather than ADMINCONSOLESESSION, you'd see JSESSIONID as the cookie key)