Re: Subject: Re: Authenticating users without dialog box

This WebDNA talk-list message is from

1997

It keeps the original formatting. numero = 14513
interpreted = N
texte = That's purely a browser issue: the reason the username and password stick is because the browser sends them to the server with every request. You could always create your own authentication system if you wanted to keep the username and password out of the URL. This would require some work and you would still have to pass something through the URL (like id=123XYZ). Our NT product uses forms based passwords and we've provided an easy way to override the way [authenticate] works. If WebCatalog finds a file named AuthenticateChecker in the WebCatalog folder, it executes the WebDNA contained in that file whenever the [authenticate] tag is processed (and [protect]). This still requires passing the information through the URL. Another option, which at this point is purely experimental so I wouldn't do it if it has to be implemented today, is to set the username and password back to the browser as a cookie. I personally don't like this method too well. I would stick to the browser's authentication dialog box and find a way to work that into your entry page nicely.Perhaps more information on what exactly you'd like to do would give me some more ideas. I hope this helps.John.>>>>Is there any way to pass username and password information without having>>>>to enter it into the browser's authentication dialog box? I'd like to>>>>take the information as entered into a page's form and have that treated>>>>the same as if it was entered through the browser's dialog (ie, I want to>>>>be able to select users from a pop-up menu).>>>>>>Sure, just put form variables into your form named username and>>>password. These values override any values that might be in the>>>browser's authentication dialog cache.>>>>Don't forget, though ... if you want to use those same values on the>>following pages instead of having the browser revert back to its>>cached username and password values, you will *also* have to put the>>username=[username] and password=[password] parameters into your>>forms and URLs so these values can be passed along ... :)>>So, there's no way for these form-entered variables to stick and be >treated *exactly* as if they were entered via the browser's >authentication dialog? What about for subsequent pages in the protected >realm that aren't accessed by using a form? And I'd rather not have the >password visible in the URL...>>Rob Marquardt>>Designer/Resident Wirehead, Toast Design>>www.toastdesign.comJohn A. HillPacific Coast Softwarehttp://www.smithmicro.com Associated Messages, from the most recent to the oldest:

That's purely a browser issue: the reason the username and password stick is because the browser sends them to the server with every request. You could always create your own authentication system if you wanted to keep the username and password out of the URL. This would require some work and you would still have to pass something through the URL (like id=123XYZ). Our NT product uses forms based passwords and we've provided an easy way to override the way [authenticate] works. If WebCatalog finds a file named AuthenticateChecker in the WebCatalog folder, it executes the WebDNA contained in that file whenever the [authenticate] tag is processed (and [protect]). This still requires passing the information through the URL. Another option, which at this point is purely experimental so I wouldn't do it if it has to be implemented today, is to set the username and password back to the browser as a cookie. I personally don't like this method too well. I would stick to the browser's authentication dialog box and find a way to work that into your entry page nicely.Perhaps more information on what exactly you'd like to do would give me some more ideas. I hope this helps.John.>>>>Is there any way to pass username and password information without having>>>>to enter it into the browser's authentication dialog box? I'd like to>>>>take the information as entered into a page's form and have that treated>>>>the same as if it was entered through the browser's dialog (ie, I want to>>>>be able to select users from a pop-up menu).>>>>>>Sure, just put form variables into your form named username and>>>password. These values override any values that might be in the>>>browser's authentication dialog cache.>>>>Don't forget, though ... if you want to use those same values on the>>following pages instead of having the browser revert back to its>>cached username and password values, you will *also* have to put the>>username=[username] and password=[password] parameters into your>>forms and URLs so these values can be passed along ... :)>>So, there's no way for these form-entered variables to stick and be >treated *exactly* as if they were entered via the browser's >authentication dialog? What about for subsequent pages in the protected >realm that aren't accessed by using a form? And I'd rather not have the >password visible in the URL...>>Rob Marquardt>>Designer/Resident Wirehead, Toast Design>>www.toastdesign.comJohn A. HillPacific Coast Softwarehttp://www.smithmicro.com John Hill

DOWNLOAD WEBDNA NOW!

Re: Subject: Re: Authenticating users without dialog box

1997

Top Articles:

Related Readings: