Uploaded image for project: 'Bitbucket Data Center'
  1. Bitbucket Data Center
  2. BSERV-4117

Provide authentication dates on the administration GUI

XMLWordPrintable

    • We collect Bitbucket feedback from various sources, and we evaluate what we've collected when planning our product roadmap. To understand how this piece of feedback will be reviewed, see our Implementation of New Features Policy.

      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.

            [BSERV-4117] Provide authentication dates on the administration GUI

            Renata Dornelas made changes -
            Remote Link Original: This issue links to "Page (Atlassian Documentation)" [ 122732 ]
            Francisco Crespo Smith made changes -
            Assignee Original: Francisco Crespo Smith [ d001924c850a ]
            Francisco Crespo Smith made changes -
            Assignee New: Francisco Crespo Smith [ d001924c850a ]
            Katherine Yabut made changes -
            Workflow Original: JAC Suggestion Workflow [ 3398095 ] New: JAC Suggestion Workflow 3 [ 3625072 ]
            Status Original: RESOLVED [ 5 ] New: Closed [ 6 ]
            Monique Khairuliana (Inactive) made changes -
            Workflow Original: BSERV Suggestions Workflow [ 3392385 ] New: JAC Suggestion Workflow [ 3398095 ]
            Monique Khairuliana (Inactive) made changes -
            Workflow Original: Stash Workflow - Restricted [ 1447915 ] New: BSERV Suggestions Workflow [ 3392385 ]
            Issue Type Original: Story [ 16 ] New: Suggestion [ 10000 ]
            Priority Original: Low [ 4 ]
            Status Original: Closed [ 6 ] New: Resolved [ 5 ]
            Owen made changes -
            Workflow Original: Stash Workflow [ 584369 ] New: Stash Workflow - Restricted [ 1447915 ]

            Jeff Grimmett added a comment -

            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

            Jeff Grimmett added a comment - 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

            Bryan Turner (Inactive) added a comment -

            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

            Bryan Turner (Inactive) added a comment - 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

            Jeff Grimmett added a comment - - edited

            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).

            Jeff Grimmett added a comment - - edited 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).

              Unassigned Unassigned
              pkoczan Peter Koczan (Inactive)
              Votes:
              27 Vote for this issue
              Watchers:
              23 Start watching this issue

                Created:
                Updated:
                Resolved: