Ok - C# here...

I have a password input type in a form on my page. Also in the form I have some validation being done that postsback to the server to do the validation. Problem is that on each postback the password field gets erased. This is expected behaviour by the nature of the password input type and I understand that. My question is, is there a way that I can programmatically persist the password field across that postback or is it a browser thing that it clears any password input type on page load?

The form is laid out like this

UserName
Password
NewUserFirstName
NewUserMiddleInitial
NewUserLastName
Submit

The validation post backs occur whenever the text in any of the NewUser fields are changed. So you type in your user name, your password, the NewUserFirstName and it posts back to do validation at the server. When the page comes back, UserName and NewUserFirstName are ok (If validation checks out) but password is cleared. The program does not actually check the password until you SUBMIT the form. so I told my customer just to fill out the password before they actually submit the form. But not having the password persist during the server-side validation is a sticking point for my customer...They want to be able to go straight down the list 1-2-3-4-5 SUBMIT. I had thought about just moving the UserName and Password filed to the bottom of the form right before the SUBMIT button, but then the layout of this form woudl be different from all the other admin forms...

I've tried everything I know of to make it happen...any ideas?

Would storing the password in a hidden text field, or storing it in the referring URL (perhaps scrambling for security), help? Or would that only cause the same issues you're having now, only with more work?

Bryant

Well - the thing is I think it's a browser behavior to clear a password input type whenever it is created - so I have a feeling that unless I do some fancy clientside stuff to use a textbox, capture the keystrokes, change them into *'s and submit it that way - I'm stuck. Even if I stored it in a hidden field etc...according to my customers specs, I'd have to then write some kind of on_load javascript routine to find that hidden field, and repopulate the password box so that the little *'s would stay there. And I don't wanna mess with all of that for something as silly as making the *'s stay in the password field...

What I have elected to do is to move all the validation that was posting back one after the other, to the server on submittal.

So rather than each form item appearing to be smart and correcting itself on the fly - it just does ALL of them in one shot upon submittal. So they will just have to enter their password after each submittal now and sacrifice the immidiate field validation. It's not 100% what they wanted - but it works.

This thread made me curious so I had a look at the TextBox class. The problem is not the browser, but the fact that all rendering for TextBox is handled solely by TextBox.Render. And, TextBox.Render will not render the value attribute to HTML when TextBox.TextMode == TextBoxMode.Password. (I thought that I'd be able to override RenderBeginTag or RenderEndTag to insert the 'missing' value attribute, but TextBox.Render doesn't call them like is usually the case).

It looks like the only solution to get the control to do what you want is to build your own TextBox control that will always render the value attribute.

You could store the value in session before processing, and check to see if there's any value assigned to the variable upon postback. If there is, fill the textbox... if not, whatever.

This is exactly what I tried doing and still it cleared the value for the password textbox which is what made me think it was a browser behavior - I think cpnet's solution is the one and I don't feel like re-writing the gui control - blah - it's not worth it...I'll just leave it blank and tell them it's a security "feature"

Behavior by design... I like giving people that excuse too (if I ever feed anybody that BS, then that's what it is.... BS lol)

In cases like this, I'd prefer if MS gave me the choice of how to handle this, but I assume they're wanting to do everything they can to make sure pages done with their newer technologies are as secure as possible.

I'm sure there's a good workaround, but I'm not clear what exactly the page is doing. Why not wait to do all validation until [Submit] is pressed? Then you can postback to the same page (if there are problems). Hopefully most of the time there won't be problems, and the password is only entered once. The password will only be re-entered if there are problems somewhere. By avoided extra postbacks, the page should be generally easier to use anyway. But maybe you have some reason not to wait until [Submit] is pressed before you start doing your validation?

One other thought... have you tried Forms authentication? (I think that's what it's called). I haven't worked with this much, but as I understand it, the first time the user tried to go to protected page during a single session, the system would check if they'd signed on. If not, they'd be redirected to a sign on page where they'd enter their user name and password. After that the session would remember their login info, and they could use any protected page without signing in again. Then you could avoid having to deal with username and password on the page that has NewUserFirstName. That page would simply deal with NewUserFirstName and whatever other NewUserXXX fields you needed.

Only reason I'm not waiting to have verification done on submit is that hte requirement I got form the customer stated that they wanted each field checked as it was entered...I think what we have is a person writing up a requirement that doesn't really understand the mechanics of what they are asking...


Again - the requirement from the client states that they don't want to "log in" to the system. They want to just fill out the form and if the username and password check out - execute the appropriate function for that page. There are 4 pages in this and all are the same way. It's a funky requirement but...that's what they asked for...

that is funky... have you tried explaining a few things to them, or did you just give the "yes sir" and go with it? I think it may be time to have a talk with them :wacko:

yup - I wanted to go with the forms solution but they didn't want to have yet another system for the idiot girls working in the mail department to have to log into...so they came up wiht this solution, which, in essence is requiring them to log in to do each transaction. Why? This is the government...why do they do half the things they do?

Oh and when I say "idiot girls" I MEAN it...one of these girls, a career employee mind you, is SO dumb she SPELLS her name incorrectly sometimes...now you tell me - how in the fookin world does one spell their own name incorrectly? Her name is Heidi and she flips the ei and ie sometimes...WTF???

"We're from the government and we're here to help..."