认证，授权和会话管理传统Web应用程序和API [英] Authentication, Authorization and Session Management in Traditional Web Apps and APIs

问题描述

纠正我，如果我错了：在传统的web应用程序，浏览器会自动追加会话信息进入到服务器的请求，这样服务器可以知道该请求来自谁。究竟实际追加？

Correct me if I am wrong: In a traditional web application, the browser automatically appends session information into a request to the server, so the server can know who the request comes from. What exactly is appended actually?

然而，在一个基于API的应用程序，这个信息不会自动发送，因此开发一个API的时候，我必须，如果请求来自例如身份验证的用户检查自己？这是如何正常执行？

However, in a API based app, this information is not sent automatically, so when developing an API, I must check myself if the request comes from an authenticated user for example? How is this normally done?

推荐答案

HTTP协议是无状态的设计，每个请求都分别进行，并在一个单独的上下文中执行。

HTTP Protocol is stateless by design, each request is done separately and is executed in a separate context.

会话管理背后的想法是把请求来自同一客户端在相同的上下文。这是通过由服务器发出的识别符，并把它发送到客户机完成的，然后在客户端将保存此标识和重新发送在后续请求，因此服务器可以识别它。

The idea behind session management is to put requests from the same client in the same context. This is done by issuing an identifier by the server and sending it to the client, then the client would save this identifier and resend it in subsequent requests so the server can identify it.

在一个典型的浏览器的服务器的情况下;浏览器管理键/值对，被称为Cookie的列表，每个域：

In a typical browser-server case; the browser manages a list of key/value pairs, known as cookies, for each domain:

• Cookie可以由服务器来管理（创建/修改/删除）使用设置Cookie HTTP响应报头。


• 缓存可以由服务器（读）通过解析饼干 HTTP请求头访问。

• Cookies can be managed by the server (created/modified/deleted) using the Set-Cookie HTTP response header.
• Cookies can be accessed by the server (read) by parsing the Cookie HTTP request header.

网页针对性的编程语言/框架提供的函数来处理上一个台阶饼干，例如PHP提供 的setcookie / $ _ COOKIE 读/写饼干。

Web-targeted programming languages/frameworks provide functions to deal with cookies on a higher level, for example, PHP provides setcookie/$_COOKIE to write/read cookies.

返回会议，在一个典型的浏览器 - 服务器的情况下（再次），服务器端的会话管理需要客户端的cookie管理的优势。 PHP的会话管理设置一个会话cookie，并用它来识别后续的请求。

Back to sessions, In a typical browser-server case (again), server-side session management takes advantage of client-side cookie management. PHP's session management sets a session id cookie and use it to identify subsequent requests.

现在回到你的问题;因为你是负责设计的API和记录它之一，实现将是你的决定。你基本上要

Now back to your question; since you'd be the one responsible for designing the API and documenting it, the implementation would be your decision. You basically have to

1. 给客户端的标识，无论是通过设置Cookie HTTP响应头，响应体（XML / JSON响应AUTH）内。


2. 有一个机制来维护标识符/客户端关联。例如该关联标识符 00112233445566778899aabbccddeeff 客户端/用户＃ 1337 。
数据库表

3. 有客户端重新发送的所有后续请求在（1）发送给它的标识，无论是在HTTP 饼干请求头，一个？SID = 00112233445566778899aabbccddeeff 参数（*）。


4. 查找所接收的标识符，使用该机制在（2），检查是否有效的验证，并授权的请求的操作，然后用代表在auth'd用户的操作进行。

1. give the client an identifier, be it via a Set-Cookie HTTP response header, inside the response body (XML/JSON auth response).
2. have a mechanism to maintain identifier/client association. for example a database table that associates identifier 00112233445566778899aabbccddeeff with client/user #1337.
3. have the client resend the identifier sent to it at (1.) in all subsequent requests, be it in an HTTP Cookie request header, a ?sid=00112233445566778899aabbccddeeff param(*).
4. lookup the received identifier, using the mechanism at (2.), check if a valid authentication, and is authorized to do requested operation, and then proceed with the operation on behalf on the auth'd user.

当然你也可以建立在现有的基础设施，你可以使用PHP的会话管理（即会照顾1./2，和4认证的一部分）在您的应用程序，并要求客户端实现做饼干管理（这将照顾3），然后在该做你的应用程序逻辑的其余部分。

Of course you can build upon existing infrastructure, you can use PHP's session management (that would take care of 1./2. and the authentication part of 4.) in your app, and require that client-side implementation do cookie management(that would take care of 3.), and then you do the rest of your app logic upon that.

（*），每种方法都有其缺点和优点，例如，使用GET请求参数更容易实现，但可能有安全隐患，因为GET请求将被记录。您应该使用HTTPS关键（所有？）的应用程序。

(*) Each approach has cons and pros, for example, using a GET request param is easier to implement, but may have security implications, since GET requests are logged. You should use https for critical (all?) applications.

这篇关于认证，授权和会话管理传统Web应用程序和API的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！