database 如何处理数据库中用户的身份验证/授权？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/9965708/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
How to handle authentication/authorization with users in a database?
提问by whizzkid
Currently, I am working on a web project using JSF 2.0, Tomcat 7 and MongoDB. I have a big question of how to handle the session management and authentication/authorization with users in a database.
目前，我正在使用 JSF 2.0、Tomcat 7 和 MongoDB 进行 Web 项目。我有一个关于如何处理数据库中用户的会话管理和身份验证/授权的大问题。
The structure I want is as follows: only logged in users can create events and everyone can see the created events.
我想要的结构是这样的：只有登录的用户才能创建事件，每个人都可以看到创建的事件。
create.xhtml--> only for logged in users.events.xhtml--> public for everyone.
create.xhtml--> 仅适用于登录用户。events.xhtml--> 对所有人公开。
The basic structure I'm planning is:
我计划的基本结构是：
- Check if the page requires logged in user (e.g.
create.xhtml) - If yes, check if user is logged in
- If user is not logged in, go to
login.xhtml - If successfully logged in, come back to requested page
- Keep the "User is logged in" information unless user clicks log out
button. (there I guess
@SessionScopedgets into play)
- 检查页面是否需要登录用户（例如
create.xhtml） - 如果是，检查用户是否登录
- 如果用户未登录，请转到
login.xhtml - 如果登录成功，返回请求页面
- 除非用户单击注销按钮，否则保留“用户已登录”信息。（我想
@SessionScoped在那里发挥作用）
The question is:
问题是：
- What is the less complicated way of doing this?
- Where should I use the
@SessionScopedannotation? InCreate.javaorLoginManager.java? - Spring security looks kind of complicated for my issue, do I really need it? if yes, can you explain a little bit of how the implementation works together with JSF 2.0 and Mongo DB?
- 这样做的不太复杂的方法是什么？
- 我应该在哪里使用
@SessionScoped注释？在Create.java或LoginManager.java？ - 对于我的问题，Spring 安全性看起来有点复杂，我真的需要它吗？如果是，您能否解释一下该实现如何与 JSF 2.0 和 Mongo DB 一起工作？
回答by BalusC
There are several options. Which to choose is fully up to you. Just objectively weigh the concrete advantages and disadvantages conform your own situation.
有几种选择。选择哪个完全取决于您。只是客观地权衡具体的优缺点符合你自己的情况。
1. Use Java EE provided container managed authentication
1. 使用 Java EE 提供的容器管理认证
Just declare a <security-constraint>in web.xmlwhich refers a security realm which is configured in servletcontainer. You can for your webapp specify URL pattern(s) which should be checked for login and/or role(s), e.g. /secured/*, /app/*, /private/*, etc.
只需声明一个<security-constraint>in web.xmlwhich 指的是在 servletcontainer 中配置的安全领域。你可以为你的web应用指定应登录和/或角色（一个或多个），例如检查URL模式（S） ，/secured/*，/app/*，/private/*等。
Before Java EE 8, you unfortunately still need to configure a security realm in a servletcontainer-specific way. It's usually described in servletconainer-specific documentation. In case of Tomcat 8, that's the Realm HOW-TO. For example, a database based realm based on users/roles tables is described in section "JDBCRealm".
在 Java EE 8 之前，不幸的是，您仍然需要以特定于 servletcontainer 的方式配置安全领域。它通常在 servletconainer 特定文档中描述。如果是 Tomcat 8，那就是Realm HOW-TO。例如，“JDBCRealm”部分描述了基于用户/角色表的基于数据库的领域。
Since Java EE 8, there will finally be a standard API based on JSR-375.
从 Java EE 8 开始，最终会有一个基于JSR-375的标准 API 。
Advantages:
好处：
- Relatively quick and easy to setup and use.
- Since Java EE 8 there's finally a robust and flexible standard API.
- 相对快速且易于设置和使用。
- 从 Java EE 8 开始，终于有了一个健壮且灵活的标准 API。
Disadvantages:
缺点：
- Before Java EE 8, realm configuration is container-specific. In Java EE 8, the new JSR-375 Security Specshould solve that with help of JASPIC.
- Before Java EE 8, , there is no fine grained control.
- Before Java EE 8, it's very spartan; no "remember me", poor error handling, no permission based restriction.
- 在 Java EE 8 之前，领域配置是特定于容器的。在 Java EE 8 中，新的JSR-375 安全规范应该在JASPIC 的帮助下解决这个问题。
- 在 Java EE 8 之前，没有细粒度控制。
- 在 Java EE 8 之前，它非常简陋；没有“记住我”，糟糕的错误处理，没有基于权限的限制。
See also:
也可以看看：
- Performing user authentication in Java EE / JSF using j_security_check- contains complete code examples
- Java EE kickoff application- example web application (developed by me) which also demonstrates Java EE 8 authentication with Soteria(the JSR-375 RI).
- 使用 j_security_check 在 Java EE / JSF 中执行用户身份验证- 包含完整的代码示例
- Java EE 启动应用程序- 示例 Web 应用程序（由我开发），它还演示了使用Soteria（JSR-375 RI）的Java EE 8 身份验证。
2. Homegrow a servlet filter
2. 自己开发一个servlet 过滤器
This allows for much more fine grained control, but you're going to need to write all the code yourself and you should really know/understand how you should implement such a filter to avoid potential security holes. In JSF side, you could for example just put the logged-in user as a session attribute by sessionMap.put("user", user)and check in the filter if session.getAttribute("user")is not null.
这允许进行更细粒度的控制，但是您将需要自己编写所有代码，并且您应该真正知道/理解应该如何实现这样的过滤器以避免潜在的安全漏洞。例如，在 JSF 方面，您可以将登录用户作为会话属性 bysessionMap.put("user", user)并检查过滤器 if session.getAttribute("user")is not null。
Advantages:
好处：
- Fine grained control.
- Completely container independent.
- 细粒度控制。
- 完全独立于容器。
Disadvantages:
缺点：
- Reinvention of the wheel; new features require a lot of code.
- As starter, you're never sure if your code is 100% robust.
- 轮子的再造；新功能需要大量代码。
- 首先，您永远不确定您的代码是否 100% 健壮。
See also:
也可以看看：
- Is there any easy way to preprocess and redirect GET requests?- contains introducory explanation and kickoff example for authentication
- Authorization redirect on session expiration does not work on submitting a JSF form, page stays the same- contains more extended kickoff example for authentication which also covers ajax requests
- How control access and rights in JSF?- contains kickoff example for authorization
- 有没有简单的方法来预处理和重定向 GET 请求？- 包含身份验证的介绍性解释和启动示例
- 会话到期时的授权重定向不适用于提交 JSF 表单，页面保持不变- 包含更多扩展启动示例进行身份验证，其中也涵盖了 ajax 请求
- 如何控制 JSF 中的访问和权限？- 包含授权启动示例
3. Adapt a 3rd party framework
3. 调整第 3 方框架
For example, Apache Shiro, Spring Security, etc. This offers usually much more fine grained configuration options than standard container managed authentication and you don't need to write any code for this yourself, expect of the login page and some (XML) configuration of course.
例如，Apache Shiro、Spring Security等。这通常提供比标准容器管理的身份验证更细粒度的配置选项，您不需要自己为此编写任何代码，除了登录页面和一些 (XML) 配置之外当然。
Advantages:
好处：
- Fine grained control.
- Completely container independent.
- No reinvention of the wheel; minimum of own code.
- Thoroughly developed and tested by lot of users, so most likely 100% robust.
- 细粒度控制。
- 完全独立于容器。
- 无需重新发明轮子；最少自己的代码。
- 由大量用户彻底开发和测试，因此很可能 100% 健壮。
Disadvantages:
缺点：
- Some learning curve.
- 一些学习曲线。
See also:
也可以看看：
- JSF2 - Shiro tutorial- an extensive tutorial on integrating Shiro in JSF2 webapp
- JSF2 - Shiro 教程- 关于在 JSF2 webapp 中集成 Shiro 的广泛教程
