设计RESTful登录服务 [英] Designing RESTful login service

问题描述

我在此处遇到了类似的问题.但是我对概念还不清楚.这是我的情况...

I went through a similar question here. But I am yet not clear over concepts. Here is my scenario...

我的客户端(移动设备应用程序)具有一个登录屏幕，用于输入用户名和密码.提交后，他应该会看到数据库中的书籍清单以及该用户订阅的书籍清单.

My client (a mobile device app) has a login screen to enter username, password. After submission, he should see the list of books in the database plus the list of books subscribed by that user.

我有一个/LoginService，它接受用户名，密码和&检查mysql数据库以进行凭据验证.只有经过授权....我有一个/BookService； GET返回数据库中的所有书籍.

I am having a /LoginService which accepts username, password & checks a mysql database for credential validation. Only after authorization....I have a /BookService ; GET on which returns all the books in database.

1. 我应该在我的登录服务上使用GET，POST还是PUT?由于登录请求是只读操作，因此我应该使用GET-但这对于浏览器来说是愚蠢的(因为提交的数据可见).

1. Should I use GET, POST or PUT on my loginservice ? Since a login request is a read-only operation, I should use GET - but this sounds stupid for browser(as the submitted data is visible).

什么是访问令牌(在上面的链接答案中提到)，以及如何使用Java生成它们?我正在使用Jersey进行开发.它们是安全的授权方式吗?

What are accesstokens (mentioned in the linked answer above), and how to generate them using Java ? I am using Jersey for development. Are they a secure way of authorization ?

谢谢！

推荐答案

据我了解，您正在尝试在客户端和服务器之间实现Stetefull通信.因此，您使用第一个请求登录，然后使用某种令牌进行进一步的请求.

As far as I understand you are trying to implement stetefull communication between client and server. So you login with first request and then use some kind of token to make further requests.

通常，我可以建议您进行无状态通信.这意味着您对每个请求进行身份验证和授权.在这种情况下，您不需要LoginRestService.这里的重点是:

Generally I can recommend you to have stateless communication. This means, that you authenticate and authorize each request. In this scenario you don't need LoginRestService. Important points here are:

1. 客户端可以通过HTTP标头提供用户名和密码(非标准，类似于 UserName:user 和 Password:secret ).
2. 在服务器端，您可以使用

1. Client can provide userName and password through HTTP Headers (non-standard, something like UserName: user and Password: secret).
2. At the server side you can use

1. 使用AOP:只需将BooksService用AuthAdvice包装(您应该自己写).在建议您以某种方式(具有Jersey功能)访问HTTP请求中，从中获取相应的标头，对用户(从DB加载)进行身份验证和授权，然后将用户放入ThreadLocal(这样它就可用于应用程序的其余部分) )(如果需要)，则只需调用对应的方法，或者在凭据出现问题时抛出异常.
2. 使用Jersey功能:(对不起，我不太熟悉Jersey，我使用的是CXF，但从概念上讲应该是相同的)，只需创建某种AuthHendler并将其放入在请求预处理管道中.在此处理程序中，您需要使其与AuthAdvice
中的完全相同

1. Use AOP: just wrap you BooksService with AuthAdvice (which you should write yourself). In advise you access somehow (with Jersey functionality) HTTP request, take correspondent headers from it, authenticate and authorize user (that you load from DB), put user in ThreadLocal (so that it would be available to the rest of your app) if needed and just invoke correspondent method or throw exception if something wrong with credentials.
2. Use Jersey functionality: (sorry I'm not very familliar with Jersey, I'm using CXF, but conceptually it should be the same) just create some kind of AuthHendler and put it in request pre-processing pipeline. In this handler you need tho make exactly the same as in AuthAdvice

现在，当您的每个请求到达BooksService时，都将进行身份验证和授权.通常，无状态实现对于可伸缩性要好得多.

Now each of your request would be authenticated and authorized when it reaches BooksService. Generally stateless implementation is much better for scalability.

如果您想进入全状态状态，则只能使用HttpSession. LoginService.login()应该是POST请求，因为您实际上在服务器上产生了一些副作用.服务将根据提供的用户名和密码对您的用户执行身份验证，并将装入的User对象放入会话.此时，将创建服务器端会话，并且客户端在cookie中具有会话ID.因此，其他请求应自动将其发送到服务器.为了授权对BooksService的请求，您仍然需要某种Handler的Advice(请参阅无状态解决方案).唯一的区别是:这次用户是从HttpSession中获取的(您应该检查您是否已登录！).

If you want to go statefull way, than you can just use HttpSession. LoginService.login() should be POST request because you actually making some side-effects at the server. Service will perform authentication of your user according to provided username and password and put loaded User object to session. At this point, the server side session is created and client has session ID in the cookies. So further requests should automatically send it to the server. In order to authorize requests to BooksService you still need some kind of Advice of Handler (see stateless solution). The only difference: this time user is taken from the HttpSession (you should check that you are logged in!).

更新:并使用 HTTPS ！ :)

这篇关于设计RESTful登录服务的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！