Password Fields

[dwa]

All,

We're trying to determine how to deal with password fields losing their
state on a post back.

We've got a form that implements post backs to carry out server side
processing. As a result of the post back, passwords entered by the user
lose their values and the user gets an error message upon final validation
when they submit. Here's an illustration

1. Password : [ ]
2. Confirm: [ ]
3. Select something from a list: [ ] // this could cause a
post-back, which wipes out the passwords
4. Some other field: [ ]
5. Hit submit key

After hitting the submit key (5), the user gets an error message, because
the passwords are now blank as a result of the post back in step #3. What
techniques should be used to get around this? We've tried fiddling with
the VIEWSTATE, to remember values, but it seems like their should be better
way... (?)

-- dwa

[Suresh]

Textbox of type password are cleared by design after postback. There are ways to get around it using Javascript but it's not a safe/secure thing to do

Suresh

----- dwa wrote: ----

All

We're trying to determine how to deal with password fields losing thei
state on a post back

We've got a form that implements post backs to carry out server sid
processing. As a result of the post back, passwords entered by the use
lose their values and the user gets an error message upon final validatio
when they submit. Here's an illustratio

1. Password : [
2. Confirm: [
3. Select something from a list: [ ] // this could cause
post-back, which wipes out the password
4. Some other field: [
5. Hit submit ke

After hitting the submit key (5), the user gets an error message, becaus
the passwords are now blank as a result of the post back in step #3. Wha
techniques should be used to get around this? We've tried fiddling wit
the VIEWSTATE, to remember values, but it seems like their should be bette
way... (?

-- dw

[Raterus]

Look at it from a security standpoint, if you restored the password, any joe
could look at the source and see the password in cleartext (not like it
isn't transfered that way). If it makes you feel any better, every site
I've come across doesn't save my password across postbacks. Yeah it's
annoying, but probably best way for security reasons. If you do want to
restore it, I'm sure the method you are using works great. If you want to
do it automatically you'll probably have to do some funky
inheritance/overriding of whatever method that matches posted values to
their respective form fields, which probably wouldn't even be worth it (and
I wouldn't even know where to begin)
"dwa" <[e-mail]> wrote in message
news:%2******************@TK2MSFTNGP10.phx.gbl...

All,

We're trying to determine how to deal with password fields losing their
state on a post back.

We've got a form that implements post backs to carry out server side
processing. As a result of the post back, passwords entered by the user
lose their values and the user gets an error message upon final validation
when they submit. Here's an illustration

1. Password : [ ]
2. Confirm: [ ]
3. Select something from a list: [ ] // this could cause a
post-back, which wipes out the passwords
4. Some other field: [ ]
5. Hit submit key

After hitting the submit key (5), the user gets an error message, because
the passwords are now blank as a result of the post back in step #3. What techniques should be used to get around this? We've tried fiddling with the VIEWSTATE, to remember values, but it seems like their should be better way... (?)

-- dwa

[dwa]

Suresh,

I understand the security concerns. Nevertheless, can you point us to one
of those javascript examples?

Thanks,

-- dwa

"Suresh" <an*******@discussions.microsoft.com> wrote in message
news:96**********************************@microsof t.com...

Textbox of type password are cleared by design after postback. There are ways to get around it using Javascript but it's not a safe/secure thing to
do.
Suresh.

----- dwa wrote: -----

All,

We're trying to determine how to deal with password fields losing their state on a post back.

We've got a form that implements post backs to carry out server side
processing. As a result of the post back, passwords entered by the user lose their values and the user gets an error message upon final validation when they submit. Here's an illustration

1. Password : [ ]
2. Confirm: [ ]
3. Select something from a list: [ ] // this could cause a post-back, which wipes out the passwords
4. Some other field: [ ]
5. Hit submit key

After hitting the submit key (5), the user gets an error message, because the passwords are now blank as a result of the post back in step #3. What techniques should be used to get around this? We've tried fiddling with the VIEWSTATE, to remember values, but it seems like their should be better way... (?)

-- dwa

[dwa]

I understand the security concerns.

I have seens sites that do this (asp.net sites if memory serves)

So it's being done... which means that some people want to override the
security issue in favor of improved form behavior. Plus, the security
issue is there regardless of the postback, but that's another story...

Darn!

-- dwa

"Raterus" <raterus@localhost> wrote in message
news:OC***************@TK2MSFTNGP11.phx.gbl...

Look at it from a security standpoint, if you restored the password, any joe could look at the source and see the password in cleartext (not like it
isn't transfered that way). If it makes you feel any better, every site
I've come across doesn't save my password across postbacks. Yeah it's
annoying, but probably best way for security reasons. If you do want to
restore it, I'm sure the method you are using works great. If you want to
do it automatically you'll probably have to do some funky
inheritance/overriding of whatever method that matches posted values to
their respective form fields, which probably wouldn't even be worth it (and I wouldn't even know where to begin)
"dwa" <[e-mail]> wrote in message
news:%2******************@TK2MSFTNGP10.phx.gbl...

All,

We're trying to determine how to deal with password fields losing their
state on a post back.

We've got a form that implements post backs to carry out server side
processing. As a result of the post back, passwords entered by the user lose their values and the user gets an error message upon final validation when they submit. Here's an illustration

1. Password : [ ]
2. Confirm: [ ]
3. Select something from a list: [ ] // this could cause a
post-back, which wipes out the passwords
4. Some other field: [ ]
5. Hit submit key

After hitting the submit key (5), the user gets an error message, because the passwords are now blank as a result of the post back in step #3.

What

techniques should be used to get around this? We've tried fiddling

with

the VIEWSTATE, to remember values, but it seems like their should be

better

way... (?)

-- dwa

[Suresh]

Here you go

Instead of a asp:textbox use html input box of type password and set it to runat server like below

<INPUT id="htxtPWD" type="password" runat="server"

Then in your handler that handles the postback of your dropdown list add the following code

string sJs = "<script language=\"javascript\">\n"
"<!--\n"
"document.myTestForm.htxtPWD.value = \"" + htxtPWD.Value + "\";"
"//-->\n"
"</script>\n"

Page.RegisterStartupScript("", sJs)

NOTE: This WILL leave the password exposed in the source of the HTML file

HTH
Suresh
----- dwa wrote: ----

Suresh

I understand the security concerns. Nevertheless, can you point us to on
of those javascript examples

Thanks

-- dw

"Suresh" <an*******@discussions.microsoft.com> wrote in messag
news:96**********************************@microsof t.com..

Textbox of type password are cleared by design after postback. There ar ways to get around it using Javascript but it's not a safe/secure thing t
do

Suresh
----- dwa wrote: ----
All
We're trying to determine how to deal with password fields losin

thei state on a post back

We've got a form that implements post backs to carry out server sid processing. As a result of the post back, passwords entered by th

use lose their values and the user gets an error message upon fina validatio when they submit. Here's an illustratio

1. Password : [ 2. Confirm: [
3. Select something from a list: [ ] // this could caus

post-back, which wipes out the password
4. Some other field: [
5. Hit submit ke

After hitting the submit key (5), the user gets an error message

becaus the passwords are now blank as a result of the post back in step #3 Wha techniques should be used to get around this? We've trie fiddling wit the VIEWSTATE, to remember values, but it seems like their should b bette way... (?

-- dw

[Jens Hofmann]

You can use JavaScript to do this task,
private void RegisterPasswordScript()
{
string pw= LoadPW();

StringBuilder sb = new StringBuilder();
sb.Append("<script type=text/javascript language=javascript>\n");
sb.Append("\tfunction FillPassword()\n");
sb.Append("\t{\n");

sb.Append("\t\tdocument.all[\""+_passwordTexBox1.ClientID+"\"].value=\""+pw+
"\"\n");

sb.Append("\t\tdocument.all[\""+_passwordTexBox2.ClientID+"\"].value=\""+pw+
"\"\n");
sb.Append("\t}\n");
sb.Append("\t</script>");
this.RegisterStartupScript("PWSCRIPT",sb.ToString( ));
}

and call this for example in Page_Load(). You should encrypt the password
before integrating it into the Script.

You have to inlcude <body onload="javascript:FillPassword();">

Hope this is what you want.

Ci@o Jens
"dwa" <[e-mail]> schrieb im Newsbeitrag
news:%2******************@TK2MSFTNGP10.phx.gbl...

All,

We're trying to determine how to deal with password fields losing their
state on a post back.

We've got a form that implements post backs to carry out server side
processing. As a result of the post back, passwords entered by the user
lose their values and the user gets an error message upon final validation
when they submit. Here's an illustration

1. Password : [ ]
2. Confirm: [ ]
3. Select something from a list: [ ] // this could cause a
post-back, which wipes out the passwords
4. Some other field: [ ]
5. Hit submit key

After hitting the submit key (5), the user gets an error message, because
the passwords are now blank as a result of the post back in step #3. What techniques should be used to get around this? We've tried fiddling with the VIEWSTATE, to remember values, but it seems like their should be better way... (?)

-- dwa

[dwa]

Thanks Suresh.

So basically, we're injecting some code to reinitialize the value explicitly
after the postback.

We'll give it a go.

-- dwa
"Suresh" <an*******@discussions.microsoft.com> wrote in message
news:6A**********************************@microsof t.com...

Here you go:

Instead of a asp:textbox use html input box of type password and set it to runat server like below.
<INPUT id="htxtPWD" type="password" runat="server">

Then in your handler that handles the postback of your dropdown list add the following code.
string sJs = "<script language=\"javascript\">\n" +
"<!--\n" +
"document.myTestForm.htxtPWD.value = \"" + htxtPWD.Value + "\";" +
"//-->\n" +
"</script>\n";

Page.RegisterStartupScript("", sJs);

NOTE: This WILL leave the password exposed in the source of the HTML file.

HTH,
Suresh.
----- dwa wrote: -----

Suresh,

I understand the security concerns. Nevertheless, can you point us to one of those javascript examples?

Thanks,

-- dwa

"Suresh" <an*******@discussions.microsoft.com> wrote in message
news:96**********************************@microsof t.com...

> Textbox of type password are cleared by design after postback. There are

ways to get around it using Javascript but it's not a safe/secure thing to do. >> Suresh.
>> ----- dwa wrote: -----
>> All,
>> We're trying to determine how to deal with password fields

losing

their

> state on a post back.

>> We've got a form that implements post backs to carry out

server side > processing. As a result of the post back, passwords entered

by the user

> lose their values and the user gets an error message upon

final validation

> when they submit. Here's an illustration

>> 1. Password : [ ] > 2. Confirm: [ ]
> 3. Select something from a list: [ ] // this could

cause a

> post-back, which wipes out the passwords
> 4. Some other field: [ ]
> 5. Hit submit key

>> After hitting the submit key (5), the user gets an error

message, because

> the passwords are now blank as a result of the post back in

step #3. What

> techniques should be used to get around this? We've tried fiddling with

> the VIEWSTATE, to remember values, but it seems like their

should be better

> way... (?)

>> -- dwa
>>>

[dwa]

Jens,

Looks pretty close to the suggestion from Suresh. So by majority vote,
we'll try it out.

Thanks,

-- dwa

"Jens Hofmann" <bu*****@gmx.de> wrote in message
news:40***********************@newsread2.arcor-online.net...

You can use JavaScript to do this task,
private void RegisterPasswordScript()
{
string pw= LoadPW();

StringBuilder sb = new StringBuilder();
sb.Append("<script type=text/javascript language=javascript>\n");
sb.Append("\tfunction FillPassword()\n");
sb.Append("\t{\n");

sb.Append("\t\tdocument.all[\""+_passwordTexBox1.ClientID+"\"].value=\""+pw+ "\"\n");

sb.Append("\t\tdocument.all[\""+_passwordTexBox2.ClientID+"\"].value=\""+pw+ "\"\n");
sb.Append("\t}\n");
sb.Append("\t</script>");
this.RegisterStartupScript("PWSCRIPT",sb.ToString( ));
}

and call this for example in Page_Load(). You should encrypt the password
before integrating it into the Script.

You have to inlcude <body onload="javascript:FillPassword();">

Hope this is what you want.

Ci@o Jens
"dwa" <[e-mail]> schrieb im Newsbeitrag
news:%2******************@TK2MSFTNGP10.phx.gbl...

All,

We're trying to determine how to deal with password fields losing their
state on a post back.

We've got a form that implements post backs to carry out server side
processing. As a result of the post back, passwords entered by the user lose their values and the user gets an error message upon final validation when they submit. Here's an illustration

1. Password : [ ]
2. Confirm: [ ]
3. Select something from a list: [ ] // this could cause a
post-back, which wipes out the passwords
4. Some other field: [ ]
5. Hit submit key

After hitting the submit key (5), the user gets an error message, because the passwords are now blank as a result of the post back in step #3.

What

techniques should be used to get around this? We've tried fiddling

with

the VIEWSTATE, to remember values, but it seems like their should be

better

way... (?)

-- dwa