使用 JPA 将哈希存储为字节数组

发布于 2024-09-25 13:16:23 字数 524 浏览 7 评论 0原文

我的 User 实体类包含密码哈希字段,它是一个固定长度的字节数组(32,因为它是 SHA-256 哈希)。

@Entity
public class User {
    @Column(nullable=false)
    private byte[] passwordHash;
    ...
}

正如你所看到的,我没有用任何特殊的东西来注释它,只是一个 NOT NULL。

这可行,但它会执行吗?我的模式是由 Hibernate 生成的,但我不知道它到底生成什么(我当前正在使用内存 HSQL 数据库)。

我担心,因为它不知道它是一个固定长度的数组(Column 注释的 length 字段仅适用于字符串),所以它会存储这个BLOB 字段中的哈希值作为指针添加到记录中(如果我正确理解数据库的工作原理)。

这是真的吗?我该如何改变?我是否应该将哈希编码为字符串(使用 Base64 或十六进制),接受其对性能/正确性的微小影响?

My User entity class contains password hash field, which is a byte array with a fixed length (32 since it's an SHA-256 hash).

@Entity
public class User {
    @Column(nullable=false)
    private byte[] passwordHash;
    ...
}

As you can see, I haven't annotated it with anything special, just a NOT NULL.

This works, but will it perform? My schema is generated by Hibernate, but I don't know exactly what it generates (I'm currently using an in-memory HSQL database).

I'm concerned that, since it doesn't know that it's a fixed length array (the length field of the Column annotation applies to strings only), it will store this hash in a BLOB field which is added in the record as a pointer (if I understand correctly how databases work).

Is this true, and how can I change this? Should I just encode the hash as a string, with base64 or hex, accepting the small performance/correctness impact of that?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

往日 2024-10-02 13:16:24

我担心的是,因为它不知道它是一个固定长度的数组(Column 注释的长度字段仅适用于字符串),(...)

如果您指定列长度,Hibernate将使用此信息来确定要生成的 SQL 列类型(TINYBLOBBLOBMEDIUMBLOBLONGBLOB)。

我需要的是 BINARY(32)

你尝试过这个吗?

@Column(columnDefinition="BINARY(32) NOT NULL")
private byte[] passwordHash;

I'm concerned that, since it doesn't know that it's a fixed length array (the length field of the Column annotation applies to strings only), (...)

If you specify the column length, Hibernate will use this information to determine the SQL column type to generate (TINYBLOB, BLOB, MEDIUMBLOB, LONGBLOB) though.

What I need is BINARY(32)

Did you try this?

@Column(columnDefinition="BINARY(32) NOT NULL")
private byte[] passwordHash;
温暖的光 2024-10-02 13:16:24

tinyblob 是一个很好的乐趣(mysql 类型参考),但我所有的应用程序都可以与字符串一起正常工作。
如果您确实关心毫秒,请在分析器中尝试这两个版本,看看哪个版本效果最好。我首选的分析器是 netbeans 中包含的分析器。

tinyblob is a good joice (mysql types reference), but all my apps work fine with Strings.
If you really care about milli-seconds try both versions in a profiler and see what works best. My preferred profiler is the one included in netbeans.

爱,才寂寞 2024-10-02 13:16:24

据我所知,SHA-256 哈希始终只是可打印字符(如果不是,则对其进行 base64 编码),因此解决方案是您可以将其存储为字符串,然后使用 length 字段Column 注释的。

然后你就得到了固定的长度并且毫无疑问的性能。

As far as I know, a SHA-256 hash is always only printable characters (and if not, encode it base64), so the solution is that you CAN store it as string, then use the length field of the Column annotation.

Then you've got your fixed length and no doubt about performance.

陌上芳菲 2024-10-02 13:16:24

它可能没有那么高效,但我建议您使用 String 作为存储类型,并根据需要使用 getter 和 setter 方法进行转换。这允许 JPA 在不同数据库之间实现最大程度的可移植性。

我对日期/时间使用类似的技术,通过存储表示自 UTC 纪元以来的时间的长整型,这使我能够避免时区问题(时区信息不可移植到所有数据库的数据库日期中)。

It may not be as efficient, but I suggest you use String as the storage type and translate as needed with the getter and setter methods. This allows maximum portability for JPA between different databases.

I use a similar technique with Date/Time by storing longs that represent time since epoch in UTC which allows me to avoid timezone issues (timezone information is not portable in database dates across all databases).

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文