starred/netbox
1
0
Fork 0
mirror of https://github.com/netbox-community/netbox.git synced 2026-01-11 21:10:29 +01:00
Code Issues 273 Packages Projects Releases 10 Wiki Activity

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

New Issue
Closed
opened 2025-12-29 16:25:50 +01:00 by adam · 3 comments
adam commented 2025-12-29 16:25:50 +01:00
Owner
Copy Link

Originally created by @jeremystretch on GitHub (Mar 22, 2017).

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.

Originally created by @jeremystretch on GitHub (Mar 22, 2017). 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.
adam added the type: feature label 2025-12-29 16:25:50 +01:00
adam closed this issue 2025-12-29 16:25:50 +01:00
adam commented 2025-12-29 16:25:51 +01:00
Author
Owner
Copy Link

@jsenecal commented on GitHub (Mar 22, 2017):

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, notifications@github.com
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
https://github.com/digitalocean/netbox/issues/985, or mute the thread
https://github.com/notifications/unsubscribe-auth/ABfg5i5C2jb27OIP8ys0YiqWIKXIwDzlks5roYjOgaJpZM4MlzJ3
.

@jsenecal commented on GitHub (Mar 22, 2017): 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, <notifications@github.com> 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 > <https://github.com/digitalocean/netbox/issues/985>, or mute the thread > <https://github.com/notifications/unsubscribe-auth/ABfg5i5C2jb27OIP8ys0YiqWIKXIwDzlks5roYjOgaJpZM4MlzJ3> > . >
adam commented 2025-12-29 16:25:51 +01:00
Author
Owner
Copy Link

@lampwins commented on GitHub (Mar 22, 2017):

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

@lampwins commented on GitHub (Mar 22, 2017): @jsenecal beat me to the punch, JWT's really seem like the way forward here. No more sessions/cookies. So true RESTfulness.
adam commented 2025-12-29 16:25:51 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Mar 23, 2017):

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.

@jeremystretch commented on GitHub (Mar 23, 2017): 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.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
beta
breaking change
complexity: high
complexity: low
complexity: medium
needs milestone
netbox
pending closure
plugin candidate
pull-request
Mirrored from GitHub Pull Request
 severity: high
severity: low
severity: medium
status: accepted
status: backlog
status: blocked
status: duplicate
status: needs owner
status: needs triage
status: revisions needed
status: under review
topic: GraphQL
topic: Internationalization
topic: OpenAPI
topic: UI/UX
topic: cabling
topic: event rules
topic: htmx navigation
topic: industrialization
topic: migrations
topic: plugins
topic: scripts
topic: templating
topic: testing
type: bug
type: deprecation
type: documentation
type: feature
type: housekeeping
type: translation
No Label type: feature
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/netbox#788
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?