Page 1 of 1
Active VLF user
Posted: Thu Dec 01, 2016 2:05 am
by René Houba
How can I get the active VLF userID?
I want to do something like this:
#Field := #ActiveVLFuser
Re: Active VLF user
Posted: Thu Dec 01, 2016 6:10 am
by atostaine
In our VLF for windows connected to Iseries we use *USER
Art
Active VLF user
Posted: Thu Dec 01, 2016 8:04 am
by René Houba
What I mean is the VLF user (stored in the internal VLF files), not the iSeries or Windows User.
Re: Active VLF user
Posted: Thu Dec 01, 2016 8:20 am
by MarkD
In what context? VLF-WIN, VLF-ONE or classic VLF-WEB.
Re: Active VLF user
Posted: Thu Dec 01, 2016 8:34 am
by René Houba
Hi Mark,
This is a VLF ONE environment in V14 SP1. All in Windows.
I want to make it possible to let the end user change their password.
I created a user defined file. In the VLF IIP I use this to check if the user logon is correct.
See attachments.
Re: Active VLF user
Posted: Thu Dec 01, 2016 9:10 am
by MarkD
On the client side you can access #uSystem.FrameworkLoggedOnVisibleUserProfile which is what you logon validation routine returned and #uSystem,FrameworkPlatformU which is what the actual user profile was on the sign on dialog.
Sending client side values to the server carries a small risk of tampering of course – either by someone using a JS debugger, or the usual in transit tampering risk.
To avoid that you can do what this shipped example suggests ……….

- Capture.PNG (55.4 KiB) Viewed 19350 times
Your server logon validator puts the user profile into persistent string 1 (say), which then makes it available to all server modules within the session, including your password changer. Since this value never actually leaves the server it should be much more tamper resistant.
Re: Active VLF user
Posted: Thu Dec 01, 2016 9:15 am
by MarkD
Re: Active VLF user
Posted: Thu Dec 01, 2016 9:24 am
by René Houba
THANKS Mark, I will test this

Re: Active VLF user
Posted: Thu Dec 01, 2016 9:48 am
by MarkD
A very basic way to store passwords is in a data base table keyed by user profile and with an encrypted composite password key and a date of last update.
The composite password key is formatted something like UserProfile=PlainTextPassword=DateUpdated (say) and then the whole thing is encrypted using the supplied password, and maybe something else, and stored as the composite password key.
So in theory the only way, without cracking tools, to find out what the password is is to first know what the password is - which is a Catch-22 situation.
I think this is part of the reason that good systems (like the IBM i) can never tell you what your old password was – they can only give you a new one.
When validating you get a user profile and password passed in as parameters.
Lookup that data base row and decrypt the password key with the password supplied + whatever else.
The result must decrypt to UserProfile=PlainTextPassword=DateUpdated and the decomposed parts of that must match the user profile parameter supplied, the password parameter supplied, and the date update stored in the table row.
That should also protect you from someone tampering with the user profile key of the table.