I have a question about the SYSENV records for user accounts in ARev 3.02.

We would like to start tracking how long a user account has been inactive. My thought was to add a field or two to the user's SYSENV record, at the end of the record obviously. A program executed during the login script would attach the SYSENV table, read the user's account record, and update the field(s) with login date and/or time.

This application, HR-1, is a "static" application in that we have absolutely no plans of upgrading the ARev or application version.

Are there any issues, concerns, or problems with my above idea? For security purposes, I will save of the tcl command stack and restore it at the end of the program so that the SYSPROG password will not be exposed in the command stack.

TIA,

msorrel@greyhound.com

Greyhound Lines, Inc.

I did this same thing when we were converting from HR-1 to Seeker. However, instead of using the SYSENV table, I created a new table. Tracking logins was also helpful in identifying usage of the application. At one point it was thought that nobody had further reason to get into HR-1, but investigation into subsequent logins turned up some fields that didn't get converted.

When I first saw your post I thought I was going to respond that the record itself is encrypted. Well, not exactly encrypted. More like a checksum is stored with the record. Inspecting a few sample records, this does not seem to be the case. Sprez. put out an article on this a few years ago, (how to call SEC to encode the record properly, etc.), I think.

The articles I referred to are Revmedia V1I6A7 and V4I6A2. I remembered right about the encrypted records. I guess it is the encrypted passwords that were not on the records I inspected (since the records I looked at do not have associated passwords).

So the point of all this is that if you are going to add onto the record, you will have to make sure the record gets encoded properly using SEC calls.

Victor,

I appreciate the information. I have already made some proof-of-concept changes in my Dev environment, without using the SEC function, and have not noticed any ill effects.

Mayhap I've just been lucky. I shall go read the Sprezz articles right now. Thanks!!

msorrel@greyhound.com

Greyhound Lines, Inc.

HR-1 has custom software regarding those routines, and I haven't really delved into that part of HR-1. The SEC articles may not actually apply.

Victor,

And my other thought was that because I'm adding extra fields, that the system doesn't use, then the normal SEC stuff doesn't apply as well.

I will test this by using the SECUREUSER window to update my account and see if my custom data still exists, and if the account is still usable.

Thanks!!

Matt Sorrell

Okay, not sure what happened there. Ignore that other post.

So, here are the results. I brought up my account in SECUREUSER, changed the password, saved the account, changed the password back, saved the account again, logged out and then logged back in.

One of my extra fields, which I'm using as a counter, was reset. So, the system is still controlling the structure of a SYSENV user record.

Looks like I'll take another approach. We have a custom table already for tracking log-ins, so I'll just write my data to this table.

Actually, the data I already need is in this table.

*thud*

Oh well, good idea anyway.

Thanks for the heads up!!

msorrel@greyhound.com

Greyhound Lines, Inc.

Using SYSENV to store custom user info is not a good idea.

If I recall correctly SECUREUSER strips off everything but the 8 or 9 fields that the USER records are defined for.

It also means that the SYSENV has to be attached and exposed to mischief intentional or otherwise where v3.x took pains not to have this file exposed as early versions did.

View this thread on the forum...