Add a query parameter to the get-session-key endpoint to allow returning an existing key

[jeremystretch]

Currently, a POST request to the /api/secrets/get-session-key/ endpoint will always generate a new SessionKey. This can be disruptive if a user is working in both the web UI and the API, as generating a new SessionKey will invalidate the cookie stored in the user's web browser. We should provide a mechanism to retrieve the existing SessionKey rather than generating a new one, to avoid this disruption.

[jsenecal]

I know this is kinda off-topic but we could use JsonWebTokens for API views. There is a well supported package for drf. That way, you don't have to store session keys or share them across devices.

…

On Wed, Mar 22, 2017, 16:47 Jeremy Stretch, ***@***.***> wrote: Currently, a POST request to the /api/secrets/get-session-key/ endpoint will always generate a new SessionKey. This can be disruptive if a user is working in both the web UI and the API, as generating a new SessionKey will invalidate the cookie stored in the user's web browser. We should provide a mechanism to retrieve the existing SessionKey rather than generating a new one, to avoid this disruption. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#985>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABfg5i5C2jb27OIP8ys0YiqWIKXIwDzlks5roYjOgaJpZM4MlzJ3> .

[lampwins]

@jsenecal beat me to the punch, JWT's really seem like the way forward here. No more sessions/cookies. So true RESTfulness.

[jeremystretch]

To be clear, a session key is an entirely separate entity from the API token. Tokens are used for authentication across the entire API, whereas a session key (a new concept in v2.0) is used only for the encryption and decryption of secret data within the secrets endpoint. It doesn't really matter how the session key is stored (it can be passed as a cookie or as a header). The issue is that a user can only have one active session key at any point in time, and using multiple interfaces (or the same interface from multiple clients) introduces the possibility where one session invalidates the key another session is using.