Password Change Requires Rentry

[devinst]

I have a server instance that is authenticating to a validation list rather than an iSeries user/password. I wanted to give users the option to change their password but not open up the additional fields that come with giving the user that option in Atrium.
I created a program that will use the iSeries API calls to allow a change to the password in the validation list. All is working great but with one small issue. When the "Change Password" program ends, and control passes back to the calling program, the user is required to reenter the new password before being able to complete any next steps such as clicking a button. I would assume that the password is being saved someplace in a cookie or an environmental variable that gets checked on each action. Is there a way to update that saved location with the "Change Password" program to equal the new password selected by the user. Or am I way off on my assumption? Thanks..!!!

[Scott Klement]

If you are using a validation list, can I safely assume that you are doing so with HTTP basic authentication? (i.e. you've configured the validation list in your HTTP server's httpd.conf file?)

If so, there's no environment variable or cookie that would help, since the password is saved in the browser. It just remembers that you entered a password, and re-sends it with every single HTTP request.

What you could potentially do is create an HTTP request from JavaScript in a rich display (using an XmlHttpRequest, aka "AJAX" request) and then this should establish the new user/password as the one to send to this site. That's about the only way I know to get it changed in the browser.... but it might be a little involved.

[devinst]

Scott, your assumption would be correct, the validation list is configured in the server's config file.
I am not real clear on the possible solution you mentioned but it does sound involved and may not be something I want to go into. However, I do have another issue I would like to resolve and this could be the solution for it also. Since the user and password are saved in the browser all instances of the browser must be closed before you can totally be logged out. The pages we are creating will have some employee sensitive material and therefor I would like to be able to log out the user without having to shut down all instances of the browser. One real world seneriao I am trying to avoid is a user on a public computer that does not close all the instances. Would using your before mentioned method of changing the current user and password information allow me to send bogus info when atrium is closed to corrupt any user log in information that may be stored in the browser?

[Scott Klement]

That's even trickier :-)

Again, the browser remembers the userid/password. It does that because, with Basic Authentication, the userid/password has to be sent with every single request. So when you view a web page, it has to send one request to download the page, and then other requests for each image, css file, javascript file, etc. So one page might be hundreds of requests. If the browser did not remember and re-use the userid/password, you might have to type the userid/password 100 times to view a single page in the browser. So browsers always remember the userid/password and re-use it automatically on all subsequent requests.

There is no "log out" capability that I'm aware of. But, what you can do is set a different userid/password (just like when you do a password change.) If the server accepts it, the browser should remember the new one and use it going forward.

So you could create a 'fake' userid that has no access to anything, and change the userid/password to that fake userid. The browser will now remember the fake id, and will re-send that... in a way, this is like logging out. You could even have the application understand the fake userid, and when it's used, send back a message like "you must log in first" or something like that.

Getting this to work correctly is not ideal, it requires you to "trick" the browser. This is really the disadvantage of using basic authentication.