【问题标题】:GWT + JBoss + MessageDigest + "SHA-512 not supported"GWT + JBoss + MessageDigest +“不支持 SHA-512”
【发布时间】:2014-08-01 08:45:56
【问题描述】:

我刚刚发现了一些奇怪的行为,我认为在这里报告它会很有趣,所以它可能会帮助其他人(因为我在询问谷歌时没有找到关于这个问题的任何线索)。

所以,我的环境是:

Java 7.25

GWT 2.5.1

Jboss 7.1.1

我做了一些登录工作流以这种方式工作:

1) 客户端输入登录名/密码

2) 密码在客户端经过 SHA-512 哈希处理

3) 刚刚在客户端散列的密码被加盐,然后在服务器端散列 SHA-512。

仅供参考,这是在客户端和服务器端散列 SHA-512 的相同函数。用于选择哈希算法的代码是这样的:

MessageDigest digest = MessageDigest.getInstance("SHA-512");

当我在 GWT 开发模块(带有嵌入码头容器的模块)上运行我的项目时,一切都运行良好。

然后我生成我的项目的战争,并将其部署在 JBoss 上,并且出现了问题: MessageDigest.getInstance("SHA-512") 方法使用 e.getMessage() => "SHA-512 not supported" 触发 NoSuchAlgorithmException。但仅限于客户端。服务器端散列是可以的(所以基本上,RPC 方法向服务器发送一个空密码而不是 SHA-512)

我不认为这是预期的行为,我想知道是否有人对此有所了解。 ATM 我不知道问题的根源是什么,我要深入检查一下:

  • 尝试使用 gwt 2.6.1(即使更改日​​志未提及此类内容)
  • 尝试使用其他 JBoss 版本
  • 尝试使用其他哈希算法
  • 检查战争构建日志(可能是 maven 问题?我对此表示怀疑,但谁知道)

任何建议将不胜感激:)

【问题讨论】:

    标签: gwt hash jboss


    【解决方案1】:

    我认为这是预期的行为。如果您查看supported packages for GWT 的列表,java.security.* 不存在。它在开发模式下工作,因为它在真正的 JVM 中运行,而不是在编译后的 javascript 中运行。

    但是为什么您甚至需要在客户端中进行密码散列呢?恕我直言,这应该在服务器端完成。

    【讨论】:

    • 你说得对。我很困惑,因为即使在不支持包的开发​​模式下,我也会遇到一些典型的异常。关于客户端哈希,目的是避免在客户端和服务器之间传输纯数据,我想我现在应该使用一些 HTTPS 的东西
    猜你喜欢
    • 1970-01-01
    • 2013-02-01
    • 1970-01-01
    • 1970-01-01
    • 2013-06-04
    • 1970-01-01
    • 2018-03-12
    • 2018-09-26
    • 1970-01-01
    相关资源
    最近更新 更多