-
Suggestion
-
Resolution: Fixed
-
None
Problem Definition
For licensing purposes, Stash administrators sometimes want to delete/deactivate users that have not used their account ever (or for a very long time in fact). For this, they would need to see these login dates,
Workaround
Until Stash 3.7 was released, that is currently only possible by querying directly the database as described on the KB below (with the exception of "Delegated LDAP users"):
Implementation
Stash 3.7 will include a last authentication time in the UI regardless of which directory type they belong to. It is important to notice that the timestamp is also included in the REST payload for /rest/api/latest/admin/users. Hence, there is no more need to query the database.
For example:
$ curl -H "Content-Type:application/json" --user admin:admin -H "Accept:application/json" -X GET http://localhost:7990/bitbucket/rest/api/1.0/admin/users { "size":3, "limit":25, "isLastPage":true, "values":[ { "name":"admin", "emailAddress":"admin@example.com", "id":1, "displayName":"Administrator", "active":true, "slug":"admin", "type":"NORMAL", "directoryName":"Bitbucket Internal Directory", "deletable":true, "lastAuthenticationTimestamp":1450221817844, "mutableDetails":true, "mutableGroups":true, "links":{ "self":[ { "href":"http://localhost:7990/bitbucket/users/admin" } ] } }, { "name":"user", "emailAddress":"user@example.com", "id":2, "displayName":"User", "active":true, "slug":"user", "type":"NORMAL", "directoryName":"Bitbucket Internal Directory", "deletable":true, "mutableDetails":true, "mutableGroups":true, "links":{ "self":[ { "href":"http://localhost:7990/bitbucket/users/user" } ] } }, { "name":"user2", "emailAddress":"user@2.com", "id":51, "displayName":"User 2", "active":true, "slug":"user2", "type":"NORMAL", "directoryName":"Bitbucket Internal Directory", "deletable":true, "lastAuthenticationTimestamp":1449467319385, "mutableDetails":true, "mutableGroups":true, "links":{ "self":[ { "href":"http://localhost:7990/bitbucket/users/user2" } ] } } ], "start":0 }
Important info:
This information can't be gleaned retroactively, so it will be maintained from the upgrade on. Until a user first logs in after the upgrade their last timestamp will show as "Unknown" in the UI.
Each time a user authenticates via HTTP or SSH (including accessing a Git repository over HTTP or SSH, push or pull), or via the login page, their timestamp will be updated. If a user selects "Remember me" on the login screen, each time their session times out (generally ~30 minutes of inactivity unless reconfigured), when they get a new session using their remember me token their timestamp will also be updated.
- duplicates
-
- Closed
- is incorporated by
-
- Gathering Interest
- mentioned in
-
![[Atlassian Documentation] Page](/images/icons/generic_link_16.png "[Atlassian Documentation] Page")
Page
No Confluence page found with the given URL.
-
Page
No Confluence page found with the given URL.
-
Page
No Confluence page found with the given URL.
-
Wiki Page Loading...
-
[BSERV-4117] Provide authentication dates on the administration GUI
Jeff,
Setting the last authentication timestamp to the account's creation date is misleading. It makes it appear that that user has already signed into the system, which is not true. That's why creating a new account does not set that date (and why it likely never will). If an administrator creates a new account for a user and that user never uses it, the last authentication timestamp should remain empty, not mislead the administrator by implying that the user did use the account at one point.
Best regards,
Bryan Turner
Atlassian Bitbucket
I'm surprised that the date of creation is not included, or alternatively that the last auth date is set to the date of creation retroactively. Right now, an account that was created yesterday looks exactly like an account that was created 3 years ago and never used.
This is definitely an improvement - parsing access logs doesn't capture GIT logins, for example. As long as the creation date in the database is accurate, I can at least grab that if needed.
(this is for a weekly automated report, so looking at web pages is not really helpful).
Stash 3.7 will include a last authentication time in the UI. That time will also be included in the REST payload for /rest/api/latest/admin/users.
This information can't be gleaned retroactively, so it will be maintained from the upgrade on. Until a user first logs in after the upgrade their last timestamp will show as "Unknown" in the UI.
Each time a user authenticates via HTTP or SSH (including accessing a Git repository over HTTP or SSH, push or pull), or via the login page, their timestamp will be updated. If a user selects "Remember me" on the login screen, each time their session times out (generally ~30 minutes of inactivity unless reconfigured), when they get a new session using their remember me token their timestamp will also be updated.
Consider also this;
Customer satisfaction (be more efficient in license usage) vs. selling more licences to customers running out of them.
-> I hope the prioritization is well chosen here 
Consider the following:
I have stash connected to crowd. I'm running out of stash licenses and I approach management with a request to increase stash licensing.
Their response will be:
- How many users are remaining
- Are all of those users actually using stash
The first one is easy to answer. The second question results in an apology and my referencing this issue.
Thanks. REST API would be optimal, but even something accurate in the DB (like Jira does it) at this point would be usable.
We don't have a timeframe for this, but I'll see whether we can schedule something to help with this.
We're using Crowd as well, and the database does NOT contain last authentication data. Is there a timeframe for improvement, here? I'm afraid I'm going to have to come up with a really ugly solution (i.e. sniffing access logs) in order to weed out the active users from the ones that we can scavenge licenses from. This is an extremely critical issue for us.
Bryan,
I do agree, and think having the stash account creation date available in the REST data package would be useful for that reason. That way, the consumer of the data would be able to decide what to do with it, rather than make assumptions about just what that means
Regards,
Jeff