在状态保存方法设置为客户端且用户会话有效的情况下，在集群环境中获取ViewExpiredException [英] Getting ViewExpiredException in clustered environment while state saving method is set to client and user session is valid

问题描述

我有一个使用Mojarra 2.2.9的JSF应用程序 并在集群环境中部署在WebSphere 8.5.5.4上 并且javax.faces.STATE_SAVING_METHOD设置为client.

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.

即使我所有的应用Bean都具有请求范围，有时，当用户会话有效且用户在页面上执行发布请求时，他仍会得到ViewExpiredException.是什么导致此问题，如何解决? 将javax.faces.STATE_SAVING_METHOD更改为server可以解决吗?如果是这样，这样做对内存有什么影响?

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?

此外，这是否与集群环境有关，也许Websphere上缺少一些配置可以解决该问题?

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?

推荐答案

如果客户端状态由一台服务器加密并由另一台服务器解密，并且服务器为此不使用相同的AES密钥，则会发生这种情况.通常，您还应该在服务器日志中看到以下警告:

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:

错误:MAC无法验证

ERROR: MAC did not verify

您需要确保使用固定的AES密钥在web.xml中设置了jsf/ClientSideSecretKey，否则每个服务器将在启动/重新启动(加密视图状态时使用)期间(重新)生成自己的AES密钥.

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>

您可以使用此代码段生成Base64格式的随机AES256(32位)密钥.

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.

如果您收到 Java安全性:密钥大小或默认参数非法?错误，请按照链接中的指示安装加密扩展. ，否则会生成一个随机的AES128(16位)密钥.

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.

此外，您还需要确保在web.xml中添加了<distributable />标记，以便JSF将执行更具攻击性的会话弄脏，并且HTTP会话(包括视图范围的bean本身！)在服务器之间正确同步.

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.

保存客户端状态的ViewExpiredException的另一个可能原因是，您已在web.xml中设置了Mojarra特定的上下文参数com.sun.faces.clientStateTimeout，它表示传入的客户端状态被视为过期之前的时间(以秒为单位).但是，这里的情况不太可能，因为上下文参数有一个相当不言自明的名称，您只需浏览web.xml就会发现它.

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.

• com.sun.faces.ClientStateSavingPassword-实际密码的建议?
• javax.faces.application.ViewExpiredException:视图无法恢复

• com.sun.faces.ClientStateSavingPassword - recommendations for actual password?
• javax.faces.application.ViewExpiredException: View could not be restored

这篇关于在状态保存方法设置为客户端且用户会话有效的情况下，在集群环境中获取ViewExpiredException的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！