Re: The Form authentication trick

This WebDNA talk-list message is from

2000


It keeps the original formatting.
numero = 35402
interpreted = N
texte = Note to others - This is all regarding using Netscape. At least on Mac, IE has no problems at all using the form-login to get thru [protect].> I tried it. Here's what happens when no previous username/password > values have been cached by the browser: > > 1- If I enter an invalid username/password, I get the browser's > authentication failed, try again dialog box. This is bad, because > the whole idea is to avoid the authentication dialog box, but it's > going to come up anyways if the visitor fails to enter the proper > username/password values the first time.yes. This is also my experience. But I myself still prefer it over forcing the authenticate dialog on all my admin users no matter what.> > 2- If I enter a valid username/password, it works -- or it fails. > This doesn't seem to make any sense, right?right.> well, here's what > happened: > > The first time I tried it, it *seemed* to work, sort of ... (see #3 > below). But every other time I tried it since the first time today, I > have not been able to get it to work again. Now it ALWAYS pops up the > browser's authentication dialog box, even when a valid username and > password are entered --Yes. This is the downside to using the trick. Once invalid values are set, then the user cannot get in w/NN using the form login (the trick). But at least the user can still get in via the authentiace dialog - same as he will need to anyway if you do not use the trick. I am just now about to make it so after a failed login from the form-login it goes to a retry page and if they click to retry it takes 'em straight to the authenticate dialog... That's the best way I can figure to handle this. You just force the authenticate dialog when they want to retry after a failed attempt. > and even after the browser is quit and > relaunched in order to insure that no values remain cached.I don't believe this. If NN is quit and relaunched, then the cache is cleared and can be reset using the trick in discussion. > > > In fact, the only way to get past the authentication dialog in this > situation is to re-enter the valid username/password *again* in the > dialog box, after first entering them into the form on the ligin.html > page.after NN has values in cache the only way to overwrite them I can find is to go thru the authenticate dialog. Yes. But the alternative is to not use the trick and force everyone to use that dialog anyway. So what's the loss?> > > 3- Even when it actually worked the *one and only time* I managed to > get it to work today, there was still a serious problem: > > When I tried to use an invalid username/password -- after using valid > values successfully -- the valid values remained in the browser's > cache and were never replaced by the invalid ones. This is bad, > because the visitor can never switch from one username/password value > to another -- instead he is always stuck with the FIRST valid values > enters, until he quits the browser.username/password are stored for each domain, it seems to me. You can go to another site (that requires a different username/password) and get in that site's protected pages, then come back to your domain and back into your protected pages without doing anything at all. It remembers what you used to get in with when you were last there. This is the same whether you use Brice's trick or the standard authenticate dialog. So once a user gets in they stay in... unless you build a login time-out function.If you need to switch the values you can simply force the authenticate dialog on them. (Sorry Vince for any misguidance. I guess you can't use this trick for what you need... I guess you have to use the authenticate dialog to change the values - or else switch to a more involved timeout mechanism.)Overall it seems Brice's trick simply offers some pleasant options. It does not take away anything. If you want to use the authenticate dialog all the time, then sure why not. I have no need to convince you of anything... I only post this one so others who have been following could see what it boiled down to...-John ------------------------------------------------------------- This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: To switch to the DIGEST mode, E-mail to Web Archive of this list is at: http://search.smithmicro.com/ Associated Messages, from the most recent to the oldest:

    
  1. Re: The Form authentication trick (John Butler 2000)
  2. Re: The Form authentication trick (Kenneth Grome 2000)
  3. Re: The Form authentication trick (John Butler 2000)
  4. Re: The Form authentication trick (Glenn Busbin 2000)
  5. Re: The Form authentication trick (Kalin Mintchev 2000)
  6. Re: The Form authentication trick (ShrPAUL1@aol.com 2000)
  7. Re: The Form authentication trick (Kalin Mintchev 2000)
  8. Re: The Form authentication trick (John Butler 2000)
  9. Re: The Form authentication trick (Kalin Mintchev 2000)
  10. Re: The Form authentication trick (Kalin Mintchev 2000)
  11. Re: The Form authentication trick (Webcat 2000)
  12. Re: The Form authentication trick (John Butler 2000)
  13. Re: The Form authentication trick (Kalin Mintchev 2000)
  14. Re: The Form authentication trick (Kalin Mintchev 2000)
  15. Re: The Form authentication trick (Kalin Mintchev 2000)
  16. Re: The Form authentication trick (John Butler 2000)
  17. Re: The Form authentication trick (Kalin Mintchev 2000)
  18. Re: The Form authentication trick (John Butler 2000)
  19. Re: The Form authentication trick (Kalin Mintchev 2000)
  20. Re: The Form authentication trick (John Peacock 2000)
  21. Re: The Form authentication trick (Bob Minor 2000)
  22. Re: The Form authentication trick (John Butler 2000)
  23. Re: The Form authentication trick (Kalin Mintchev 2000)
  24. Re: The Form authentication trick (Brice Le Blevennec 2000)
  25. Re: The Form authentication trick (John Butler 2000)
  26. Re: The Form authentication trick (Kenneth Grome 2000)
  27. Re: The Form authentication trick (John Butler 2000)
  28. Re: The Form authentication trick (Kenneth Grome 2000)
  29. Re: The Form authentication trick (John Butler 2000)
  30. The Form authentication trick (Brice Le Blevennec 2000)
Note to others - This is all regarding using Netscape. At least on Mac, IE has no problems at all using the form-login to get thru [protect].> I tried it. Here's what happens when no previous username/password > values have been cached by the browser: > > 1- If I enter an invalid username/password, I get the browser's > authentication failed, try again dialog box. This is bad, because > the whole idea is to avoid the authentication dialog box, but it's > going to come up anyways if the visitor fails to enter the proper > username/password values the first time.yes. This is also my experience. But I myself still prefer it over forcing the authenticate dialog on all my admin users no matter what.> > 2- If I enter a valid username/password, it works -- or it fails. > This doesn't seem to make any sense, right?right.> well, here's what > happened: > > The first time I tried it, it *seemed* to work, sort of ... (see #3 > below). But every other time I tried it since the first time today, I > have not been able to get it to work again. Now it ALWAYS pops up the > browser's authentication dialog box, even when a valid username and > password are entered --Yes. This is the downside to using the trick. Once invalid values are set, then the user cannot get in w/NN using the form login (the trick). But at least the user can still get in via the authentiace dialog - same as he will need to anyway if you do not use the trick. I am just now about to make it so after a failed login from the form-login it goes to a retry page and if they click to retry it takes 'em straight to the authenticate dialog... That's the best way I can figure to handle this. You just force the authenticate dialog when they want to retry after a failed attempt. > and even after the browser is quit and > relaunched in order to insure that no values remain cached.I don't believe this. If NN is quit and relaunched, then the cache is cleared and can be reset using the trick in discussion. > > > In fact, the only way to get past the authentication dialog in this > situation is to re-enter the valid username/password *again* in the > dialog box, after first entering them into the form on the ligin.html > page.after NN has values in cache the only way to overwrite them I can find is to go thru the authenticate dialog. Yes. But the alternative is to not use the trick and force everyone to use that dialog anyway. So what's the loss?> > > 3- Even when it actually worked the *one and only time* I managed to > get it to work today, there was still a serious problem: > > When I tried to use an invalid username/password -- after using valid > values successfully -- the valid values remained in the browser's > cache and were never replaced by the invalid ones. This is bad, > because the visitor can never switch from one username/password value > to another -- instead he is always stuck with the FIRST valid values > enters, until he quits the browser.username/password are stored for each domain, it seems to me. You can go to another site (that requires a different username/password) and get in that site's protected pages, then come back to your domain and back into your protected pages without doing anything at all. It remembers what you used to get in with when you were last there. This is the same whether you use Brice's trick or the standard authenticate dialog. So once a user gets in they stay in... unless you build a login time-out function.If you need to switch the values you can simply force the authenticate dialog on them. (Sorry Vince for any misguidance. I guess you can't use this trick for what you need... I guess you have to use the authenticate dialog to change the values - or else switch to a more involved timeout mechanism.)Overall it seems Brice's trick simply offers some pleasant options. It does not take away anything. If you want to use the authenticate dialog all the time, then sure why not. I have no need to convince you of anything... I only post this one so others who have been following could see what it boiled down to...-John ------------------------------------------------------------- This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: To switch to the DIGEST mode, E-mail to Web Archive of this list is at: http://search.smithmicro.com/ John Butler

DOWNLOAD WEBDNA NOW!

Top Articles:

Talk List

The WebDNA community talk-list is the best place to get some help: several hundred extremely proficient programmers with an excellent knowledge of WebDNA and an excellent spirit will deliver all the tips and tricks you can imagine...

Related Readings:

WebCatalog vs WebDNA (2002) Multiple SSL Keys (1998) [countWords]? (1997) SQL db type (2006) displaying New products (using [date]) (1997) RE: Emailer Set Up (1997) [WebDNA] Installation problem (Debian 6 64bit + Lighttpd) (2011) [applescript] (1999) Authorize.Net and AIM (2004) gremlins? (2000) Access Denied! But why? (1997) Re:listfiles-looking for slick solution (1997) Cart Question (1998) [WebDNA] calling a webDNA tmpl from PHP? (2008) [taxrate] question (1997) My recent WebDNA support inquiry (2006) Emailer (1997) Cannot calculate prices (1997) Mozilla/4. and Browser Info.txt (1997) Unzip + ddos attack?? (2005)