Login history

May depend on your OE version, but check out connect.connect-time

Works fine for our ABL connections. Connect also has useful fields like _connect-device, _connect-name, _connect-ipaddress.

We're on 10.2b07

Hi, From what I can see in the _connect table, the records in that table are related to users that are still logged in. I am looking for information about the last logins even if the users are not connected anymore. I can't find anything else that the .lg for this !

Oh by the way, we run 102B01

Ah, agreed. I'm normally only concerned with logged on users so I don't have anything set up for connect history.

I suppose you could turn on auditing for the _connect table and run queries on the audit. I've got no experience there, just throwing out a suggestion.

Ok Rob, thanks for your help anyway.

There is info in _user for last login.

FOR EACH _User NO-LOCK
WHERE :
DISPLAY
_User._Userid         FORMAT 'x(12)' COLUMN-LABEL 'Userid'
_User._User-Name      FORMAT 'x(40)' COLUMN-LABEL 'User-Name'
_User._Given_Name     FORMAT 'x(25)' COLUMN-LABEL 'Given_name'
_User._Middle_Initial FORMAT 'x(1)' COLUMN-LABEL 'Middle_initial'
_User._Surname        FORMAT 'x(25)' COLUMN-LABEL 'Surname'
_User._Last_Login     FORMAT '99/99/9999 HH:MM:SS.SSS+HH:MM' COLUMN-LABEL 'Last_login'
_User._Logins         FORMAT '>>>>>>9' COLUMN-LABEL 'Logins'
_User._Max_Logins     FORMAT '>>>>>>9' COLUMN-LABEL 'Max_logins'
_User._Max_Tries      FORMAT '>>>>>>9' COLUMN-LABEL 'Max_tries'
_User._Login_Failures FORMAT '>>>>>>9' COLUMN-LABEL 'Login_failures'
.

I assume none of you are using AppServer in this scenario?

However I am wondering if this information becomes available in AppServer scenarios when we introduce the CLIENT-PRINCIPAL object in our application?

Does anyone have experience with that?

All these fields are empty in my database, does someone know how to tell Progress to populate these fields ?. There has to be a switch or something but I can't find anything out there.

Thanks.

FWIW empty in mine too, just usernames + passwords (encrypted). All ABL connections over here, ERP databases.

There are audit events for login and logout, triggered by the client-principal's state. I think there's also one or more for setdbclient() and maybe set-client() (but I'm speaking off the top of my head here).

I don't know whether that data's available outside of auditing though.

-- peter

My question stems from the everlasting desire to detect if users have exited without logging off.

We are limiting users to login more that so many times on different machines based on their licenses. The challenge is to detect if they are really still logged in so that we do not prevent them from login in after a crash or a terminated browser or terminal server session.

I think this is along the same lines of the question that Julian asked in this http://communities.progress.com/pcom/message/170063#170063 thread.

Basically, this is less about login/authentication/identity management and more about (user) session management.

To do this, on each request (via activate.p) the app's session management code would update something like a Session.LastAccess timestamp.

You'd need a separate (batch) job to regularly loop through all the session records and remove those that have not had an access within N minutes (or hours, seconds, months, years, epochs, etc). The act of closing/removing the user session should also clean up the client-principal appropriately.

Alternatively, instead of removing the session, you could just expire/logout the client-principal which would require a re-login the next time a client with the associated session id tried to run something. That would let you reuse user session data if you wanted.

-- peter

surely from a basic security point of view, if their session has timed out, you should destroy all related session information as well ?

jmls wrote:
surely from a basic security point of view, if their session has timed out, you should destroy all related session information as well ?

Not necessarily: IMO it depends on where you consider the line between "user" and "session" to be.

Think about a shopping cart on something like Amazon. If you put stuff into your cart, it persists across logins (and across re-authorisations for things like checkout).  Is that user data or session data?

-- peter

Yeah, the shopping cart example I would certainly consider as "user"

data , not "session" data

There is no inbuilt feature that records login history. However, in version 11.1 and later, there is a feature known as "4GL authentication callbacks".

These callbacks can be configured so that your 4GL code is called either to do the entire authentication or to supplement the inbuilt authentication mechanisms. I won't go into all the details here, but here are the calling sequences for two callback procedures:

PROCEDURE AuthenticateUser:

DEFINE INPUT PARAMETER hCP AS HANDLE.

DEFINE INPUT PARAMETER cSystemOptions

  AS CHARACTER EXTENT.

DEFINE OUTPUT PARAMETER iPAMStatus

  AS INTEGER INITIAL ?.

DEFINE OUTPUT PARAMETER cErrorMsg AS CHARACTER.

END.

PROCEDURE AfterSetIdentity:

  DEFINE INPUT PARAMETER hCP AS HANDLE.

  DEFINE INPUT PARAMETER cSystemOptions

  AS CHARACTER EXTENT.

END.

The second callback, AfterSetIdentity(),  might be a good place to write your login history information somewhere convenient.

The problem is not the recording of the logins, but the unoffical logoffs.

The problem is not the recording of the logins, but the unoffical logoffs.

>

Understood (I think, anyway), but without knowing that a particular user session has been recently used (note: access <> login), you cannot know that it hasn't.

If you add a batch job to clean up the stale/unused sessions then only those session records that are valid remain.

The batch job might contain pseudo-code like the below. UserSession is the db table that contains user session context.

/* assume that the activate procedure does something like:

Security-policy:set-client(hClientPrincipal). /* ensures LOGIN is still valid */

UserSession.LastAccessTime = now.

*/

for each UserSession where

UserSession.LastAccessTime lt add-interval(now, '-6', 'hours'):

/* you may want to log out the stale/expired session */

create client-principal hClientPrincipal .

hClientPrincipal:import-principal(

/* do whatever else needs doing */

/* remove the session */

delete UserSession.

End.

-- peter