Active VLF user

[René Houba]

How can I get the active VLF userID?

I want to do something like this:
#Field := #ActiveVLFuser

[atostaine]

In our VLF for windows connected to Iseries we use *USER

Art

[René Houba]

What I mean is the VLF user (stored in the internal VLF files), not the iSeries or Windows User.

[MarkD]

In what context? VLF-WIN, VLF-ONE or classic VLF-WEB.

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

[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 19355 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.

[MarkD]

Somewhat related - http://vlforum.lansa.com.au/viewtopic.p ... t=62&p=196

[René Houba]

THANKS Mark, I will test this

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