首页 文章

你能帮我理解一下吗? “常见的REST错误:会话无关紧要”

提问于
浏览
154

免责声明:我是REST学派的新手,我正试着把它包裹起来 .

所以,我正在阅读这个页面,Common REST Mistakes,而我对这些无关紧要的部分感到困惑 . 这就是页面所说的内容:

客户端不需要“登录”或“启动连接” . HTTP验证在每条消息上自动完成 . 客户端应用程序是资源的消费者,而非服务 . 因此没有什么可登录的!假设您在REST网络服务上预订航班 . 您不创建与服务的新“会话”连接 . 而是你要求“行程创建者对象”为你创建一个新的行程 . 您可以开始填充空白,然后在网络上的其他地方获得一些完全不同的组件以填充其他一些空白 . 没有会话,因此在客户端之间迁移会话状态没有问题 . 服务器中也没有“会话亲和性”问题(尽管仍有负载 balancer 问题需要继续) .

好的,我得到HTTP身份验证是在每条消息上自动完成的 - 但是如何?是否每次请求都会发送用户名/密码?那不就是增加攻击面积吗?我觉得我错过了这个难题的一部分 .

拥有一个接受GET请求的REST服务(例如 /session )会不会很糟糕,在这里请求作为请求的一部分传入用户名/密码,如果验证成功则返回会话令牌,这可能是然后传递后续请求?从REST的角度来看,这是否有意义,还是忽略了这一点?

6 回答

  • 3

    要成为RESTful,每个HTTP请求应该自己携带足够的信息,以便其接收者处理它以与HTTP的无状态特性完全协调 .

    好的,我得到HTTP身份验证是在每条消息上自动完成的 - 但是如何?

    是的,用户名和密码随每个请求一起发送 . 这样做的常用方法是 basic access authenticationdigest access authentication . 是的,窃听者可以捕获用户的凭据 . 因此,可以使用 Transport Layer Security (TLS) 加密发送和接收的所有数据 .

    有一个接受GET请求的REST服务(比如/ session)会不会很糟糕,在这里请求作为请求的一部分传入用户名/密码,如果身份验证成功,则返回会话令牌,然后可以随后传递请求?从REST的角度来看,这是否有意义,还是忽略了这一点?

    这不是 RESTful ,因为它带有状态但是它很常见,因为它对用户来说是方便的;用户不必每次都登录 .

    您在"session token"中描述的内容通常被称为 login cookie . 例如,如果您尝试登录Yahoo!帐户有一个复选框,上面写着"keep me logged in for 2 weeks" . 这基本上是在说(用你的话)"keep my session token alive for 2 weeks if I login successfully." Web浏览器会根据你要求它为你做的每个HTTP请求发送这样的登录cookie(可能还有其他的) .

  • 10

    REST服务要求对每个HTTP请求进行身份验证的情况并不少见 . 例如,Amazon S3要求每个请求都具有从用户凭据,要执行的确切请求和当前时间派生的签名 . 此签名很容易在客户端计算,可以由服务器快速验证,并且对截取它的攻击者使用有限(因为它基于当前时间) .

  • 78

    很多人不太清楚REST原理,使用会话令牌并不意味着你总是有状态,每个请求发送用户名/密码的原因仅用于身份验证,发送令牌也是一样(由登录生成)过程)只是为了确定客户端是否有权请求数据,当您使用用户名/密码或会话令牌来决定显示哪些数据时,您只会违反REST会话!相反,你必须只使用它们进行身份验证(显示数据或不显示数据)

    在你的情况下,我说YES这是RESTy,但尝试避免在REST API中使用本机php会话,并开始生成自己的散列令牌,这些令牌在确定的时间周期内到期!

  • 8

    不,它没有't miss the point. Google' s ClientLogin以这种方式工作,但明显的例外是客户端被指示使用HTTP 401响应转到"/session" . 但是这不会创建会话,它只会为客户端创建一种方法(临时)验证自己而不传递明文中的凭据,并且服务器可以根据需要控制这些临时凭证的有效性 .

  • 5

    好的,我得到HTTP身份验证是在每条消息上自动完成的 - 但是如何?

    “授权:”客户端发送的HTTP标头 . 基本(纯文本)或摘要 .

    拥有一个接受GET请求的REST服务(例如/ session)会不会很糟糕,您可以在其中传递用户名/密码请求的一部分,如果身份验证成功,则返回会话令牌,然后可以随后传递请求?从REST的角度来看,这是否有意义,还是忽略了这一点?

    会话的整个想法是通过维护服务器端的状态来使用无状态协议(HTTP)和哑客户端(Web浏览器)来创建 stateful 应用程序 . REST原则之一是"Every resource is uniquely addressable using a universal syntax for use in hypermedia links" . 会话变量是无法通过URI访问的 . 真正的RESTful应用程序将维护客户端的状态,通过HTTP发送所有必需的变量,最好是在URI中 .

    示例:使用分页搜索 . 你的表格中有URL

    http://server/search/urlencoded-search-terms/page_num
    

    它与可收起的URL有很多共同之处

  • 32

    如果您想控制客户端会话的生命周期,我认为您的建议没问题 . 我认为RESTful架构鼓励您开发无状态应用程序 . 正如@ 2pence写道"each HTTP request should carry enough information by itself for its recipient to process it to be in complete harmony with the stateless nature of HTTP" .

    但是,并非总是如此,有时应用程序需要告知客户端何时登录或注销,并根据此信息维护锁或许可证等资源 . 有关此类案例的示例,请参阅我的后续行动question .

相关问题