Does anyone knows if Progress keeps an entry somewhere with the login history or at least the user's last login? I know the .lg file can be used by it's a pain. Anything in the _tables I would have thought !
Found _user._last_login but field is always blank for all users. Any help would be appreciated.
GL&V Canada Inc.
Programmeur Analyste / Programmer Analyst
Tél./Tel.: +1 819-373-5731 ext 324
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.
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.
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.
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?
Yeah, the shopping cart example I would certainly consider as "user"
data , not "session" data