Project

General

Profile

Actions

Feature #17596

open

Ability to set different session expiration time for API

Added by Tomáš Strachota over 7 years ago. Updated over 5 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
Users, Roles and Permissions
Target version:
-
Difficulty:
Triaged:
No
Fixed in Releases:
Found in Releases:

Description

API supports sessions since #17487. The default expiration time is 1 hour, which is reasonable for UI purposes but it's short for automation.

Having the API session expiry time configurable on per user basis would enable using special users with limited permissions only for automation.

Actions #1

Updated by Ohad Levy over 7 years ago

what would the expected behavior should be?

if i think of other api tokens, some of them are active for a very long period (think github tokens) while some other places (e.g. kerb) might default to 24hours.

also, while outside the scope of this ticket, i would love seeing us storing user sessions in the database for visibility - something like https://github.com/blog/1661-modeling-your-app-s-user-session

Actions #2

Updated by Tomáš Strachota over 7 years ago

Thinking of it twice - the automation argument is probably invalid. It doesn't bring any additional functionality over having a special user with basic auth.

Unrelated to the above there still could be some benefit in setting the different timeout value for ui/api but it's low prio.

Actions #3

Updated by Lesley Kimmel over 5 years ago

  • Triaged set to No

To possibly add some context to this for automation...it would be good to have the session_id cookie to at least contain an expiration timestamp. I have an automation scenario where our automation engine, after initial authentication, continues to use this cookie to authenticate. Without an expiration it uses the cookie forever. In practice it only does this until it happens to use the cookie outside of the default timeout window after which it receives a 401 and invalidates the cookie. After that we can retry simple authentication. The downside is that we've had to make a workaround to where we explicitly watch for a 401 and then attempt reauthentication if we get that code. We shouldn't have to do this.

Actions

Also available in: Atom PDF