You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There is a bug, causing that each authentication request clears the previous authenticated tokens.
Wherever there is a need to use more individual "sessions/tokens" (i.e. multiple devices, multiple applications) this results into defect of effectivelly disconnecting(invalidating token) all previously authenticated devices/apps, whenever a new authentication request is made.
This also differs from the behaviour of the PROD robots, where it is possible to have multiple sessions / multiple authenticated devices or apps.
Replication steps:
use the go-sdk escape-pod-login example to generate new token hash/guid
use this token hash/guid to test it withthe go-sdk speak example ... success
use the go-sdk escape-pod-login example again to genereate new token, but dont use it this time
run the go-sdk speak example again with the original token received in step 1 .... failure - unauthenticated.
Cause
As seen in the current go-sdk's example of EscapePod Authentication, any dummy value can be used as a session_id to create a request with to the UserAuthentication grpc. Considering the need of deprecating the use of anki services for the ep and ep+prod robots, that could be alright however, better approach here would perhaps be to request the session from the EscapePod, to at least partially replicate the commication logic and the authentication process for the Prod robots.
This rpc authentication call is processed in the vic-gateway UserAuthentication method and seems that from there it is passed to switchboard for further processing. When a successful authentication response is received from the switchboard, auth response with new token is processed further by the token manager as seen in this following implementation of the UserAuthentication method.
There, this ForceUpdate method efectivelly clears and overwrites all previous tokens with a new auth response/token.
That (for me) does not make any sence as as stated above, will in matter of fact disconnect all other clients.
Suggested Resolution:
Each unique and valid session_id (or perhaps unique combination of session_id + user_client?) used in the UserAuthentication request should generate and return valid token, which will persist valid until the used session expires, or is logged out.
The text was updated successfully, but these errors were encountered:
Description
There is a bug, causing that each authentication request clears the previous authenticated tokens.
Replication steps:
Cause
As seen in the current go-sdk's example of EscapePod Authentication, any dummy value can be used as a session_id to create a request with to the UserAuthentication grpc. Considering the need of deprecating the use of anki services for the ep and ep+prod robots, that could be alright however, better approach here would perhaps be to request the session from the EscapePod, to at least partially replicate the commication logic and the authentication process for the Prod robots.
This rpc authentication call is processed in the vic-gateway UserAuthentication method and seems that from there it is passed to switchboard for further processing. When a successful authentication response is received from the switchboard, auth response with new token is processed further by the token manager as seen in this following implementation of the UserAuthentication method.
There, this ForceUpdate method efectivelly clears and overwrites all previous tokens with a new auth response/token.
That (for me) does not make any sence as as stated above, will in matter of fact disconnect all other clients.
Suggested Resolution:
The text was updated successfully, but these errors were encountered: