与排球令牌认证 [英] Token authentication with Volley
问题描述
如果我有我的身份验证的用户名/密码，获得身份验证令牌后续请求的服务器，这将是最好的方法解决这个问题呢？
流程应该是这样的： - 启动要求 - 如果我们没有身份验证令牌 - 让它使用用户名和密码 - 请与身份验证令牌请求 - 如果请求失败，因为令牌过期，获得与用户名和密码的新身份验证令牌 - 重试新的身份验证令牌的请求 - 完成
我已经注意到，排球已经可以有一些可以解决这个问题 - 身份验证<一href="https://android.googlesource.com/platform/frameworks/support/+/4474bc11f64b2b274ca6db5a1e23e8c1d143d5fa/volley/src/com/android/volley/toolbox/Authenticator.java">https://android.googlesource.com/platform/frameworks/support/+/4474bc11f64b2b274ca6db5a1e23e8c1d143d5fa/volley/src/com/android/volley/toolbox/Authenticator.java它包含getAuthToken（）和invalidateAuthToken（）方法，这将是正是我想要的。但似乎它从来没有使用过的库都没有。
解决方案我用凌空抽射，使用龙力（LLT）和shortlive（SLT）令牌认证系统
我手工做的，但它确实是没有太多的工作，一旦你得到这一切奠定了。
让所有的安全要求子类baseSecureRequest，可以处理常见的所有安全性要求令牌机制在其onResponse（）和onErrorResponse（）。
就显得有点Node.js的风格，在请求发送其他请求，并等待回调。
这是应用程序可能有十几个画面，只有一半需要身份验证的访问 - 所以每个屏幕应该是无知到其请求的要求。
方案A
- 我们试图发送一个安全性的要求。我们注意到我们没有一个SLT在 内存，这样做TokenRequest。
- TokenRequest的onResponse（）保存 该令牌内存（让单会话管理器不放，或 类似的全向present类）
- 现在，回调到原来的 继续与新更新的令牌具体类请求对象。
方案B
-
我们发送的安全要求，但我们的SLT是陈旧的（过期）
-
服务器返回一个错误，code或味精，你可以在catch 您baseSecureRequest一般onErrorResponse（）。
-
在此的onError（），您发送refreshTokenRequest（）对象 尝试使用LLT从服务器请求新的SLT刷新SLT在存储器
-
在refreshTokenRequest的onResponse（）现在可以回调到 原始请求重发。
- 但是onErrorResponse（）或许应该放弃所有的事情，因为机会 任何不是连接错误 - 是由错误 无效的LLT。如果你不断尝试刷新一个坏LLT你将永远不会离开。
If I have a server where I authenticate with username/password and get auth token for subsequent requests, what would be the best approach addressing this problem?
The flow should be like this: - Start request - If we don't have auth token - get it with username and password - Make request with auth token - If request failed because token expired, get new auth token with user name and password - Retry request with new auth token - Finish
I've noticed that Volley already might have something that might solve this issue - Authenticator https://android.googlesource.com/platform/frameworks/support/+/4474bc11f64b2b274ca6db5a1e23e8c1d143d5fa/volley/src/com/android/volley/toolbox/Authenticator.java It contains getAuthToken() and invalidateAuthToken() methods which would be exactly what I want. But it seems that it's never used in the library at all.
I used volley for an authentication system using longlive (LLT) and shortlive (SLT) tokens.
I did it manually but it really wasn't much work once you get it all laid out.
Have all secure requests subclass a baseSecureRequest that can handle this token mechanism common to all secure request in its onResponse() and onErrorResponse().
It becomes a little node.js style, where requests send other requests and await callbacks.
An app may have a dozen screens, with only half requiring auth access - so each screen should be ignorant as to the requirements of its request.
Scenario A
- We attempt to send a secure request. We notice we don't have a SLT in memory, so make a TokenRequest.
- TokenRequest's onResponse() saves that token to memory (let a singleton session manager hold onto it or similar omni-present class)
- Now callback to the original concrete-class request object to continue with the newly updated token.
Scenario B
We send a secure request but our SLT is stale (expired)
The server returns an error code or msg that you can catch in the general onErrorResponse() of your baseSecureRequest.
In this onError(), you send a refreshTokenRequest() object that attempts to refresh the SLT in memory by requesting a new SLT from the server using the LLT.
the onResponse() of the refreshTokenRequest can now callback to the original request to resend.
- however the onErrorResponse() should probably abandon the entire thing because chances are anything that isn't a connectivity error - is an error caused by invalid LLT. If you keep trying to refresh with a bad LLT you will never get out.
这篇关于与排球令牌认证的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
