Re: You *can!!* overwrite username/password using an HTML form. Also, experts *please* see Q at end

This WebDNA talk-list message is from

2000


It keeps the original formatting.
numero = 34094
interpreted = N
texte = Passwords with the @ symbol should be considered to be bad passwords for HTML forms. In fact, you should probably limit the user to [0-9a-zA-Z] (i.e. alphanumeric only, no symbols at all). Think about what would happen if your user chose a password containing the / character...John PeacockClement Ross wrote: > > Does the redirect work with a password that contains @? > > The reason I ask is that > > http://username:p@ssword@http://www.adomain.com > and > http://username:p%40ssword@http://www.adomain.com > > won't work when typed in the Location field in Netscape. > > Clem. > > John Butler wrote: > > > > For the record... > > Brice Le Blevennec has been vindicated. > > You *can!!* overwrite username/password using a custom HTML form, rather than requiring your users who need to access protected pages to go thru the browser's > > authenticate dialog. > > Brice is using the technique on Mac/Webstar and now it is working for me on Linux/Redhat. > > > > Here's Brices instructions- > > ***** > > It takes 4 pages (1->4) but works decently. Here is my code. > > > > I assume that .tpl pages goes through WC without the > > tag. (I deleted all and tags) > > > > 1) Login.tpl > >
> >
> > > > 2) step1.tpl (this force the WC var in http headers) > > [redirect http://[username]:[password]@http://www.adomain.com/step2.tpl] > > > > 3) step2.tpl (this remove them from the URL) > > [include file=^protect.inc&groups=mygroup] > > > > > > 4) step3.tpl (this redirect to a protected page) > > [redirect http://www.adomain.com/anypage.tpl] > > > > 5) anypage.tpl (can be any page protected by Authenticate). > > [include file=^protect.inc&groups=mygroup] Hello [username], [password]. > > ***** > > > > I couldn't get it to work before because nowhere on MY test step2.tpl (see above) was there an [authenticate] or [protect] tag. One of those tags *must* be on the page > > where the [redirect] goes (the [redirect] you use to construct the URL with the 'username:password' in it - see step1.tpl above) I don't understand why it needs to be > > there, because even if you wrap it in a [showif] which will definately evaluate to false if *just* the username is valid (but the password doesn't have to be valid for > > the [showif] to evaluate false) and login with a proper username but invalid password (thus the [showif] skips over the [authenticate]) it somehow still gets the username > > and password that were input in the HTML form into the browsers's cache (at least that is where you guys tell me username and password live). But without that > > [authenticate] it will never get into the browser's cache - whether the username is valid or not, and whether the password is valid or not (ie- under no circumstances). > > I did tests using [elapsedtime] to see if webcat really does skip over things wrapped in a [showif] which evalutes to false and it does indeed seem to (as opposed to > > reading the code and then removing it 'after the fact') , so then > > > > **** !!! WHY DOES the [authenticate] have to be on step2.tpl even if the user inputs a proper username which would skip over the tag in the first place?? !!! **** > > > > can anyone explain this very bizarre (but in this case advanatgeous) behaviour?? > > ?? > > -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/ > > ------------------------------------------------------------- > 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/------------------------------------------------------------- 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: You *can!!* overwrite username/password using an HTML form. Also, experts *please* see Q at end (Clement Ross 2000)
  2. Re: You *can!!* overwrite username/password using an HTML form. Also, experts *please* see Q at end (John Butler 2000)
  3. Re: You *can!!* overwrite username/password using an HTML form. Also, experts *please* see Q at end (John Peacock 2000)
  4. Re: You *can!!* overwrite username/password using an HTML form. Also, experts *please* see Q at end (Clement Ross 2000)
  5. You *can!!* overwrite username/password using an HTML form. Also, experts *please* see Q at end (John Butler 2000)
Passwords with the @ symbol should be considered to be bad passwords for HTML forms. In fact, you should probably limit the user to [0-9a-zA-Z] (i.e. alphanumeric only, no symbols at all). Think about what would happen if your user chose a password containing the / character...John PeacockClement Ross wrote: > > Does the redirect work with a password that contains @? > > The reason I ask is that > > http://username:p@ssword@http://www.adomain.com > and > http://username:p%40ssword@http://www.adomain.com > > won't work when typed in the Location field in Netscape. > > Clem. > > John Butler wrote: > > > > For the record... > > Brice Le Blevennec has been vindicated. > > You *can!!* overwrite username/password using a custom HTML form, rather than requiring your users who need to access protected pages to go thru the browser's > > authenticate dialog. > > Brice is using the technique on Mac/Webstar and now it is working for me on Linux/Redhat. > > > > Here's Brices instructions- > > ***** > > It takes 4 pages (1->4) but works decently. Here is my code. > > > > I assume that .tpl pages goes through WC without the > > tag. (I deleted all and tags) > > > > 1) Login.tpl > >
> >
> > > > 2) step1.tpl (this force the WC var in http headers) > > [redirect http://[username]:[password]@http://www.adomain.com/step2.tpl] > > > > 3) step2.tpl (this remove them from the URL) > > [include file=^protect.inc&groups=mygroup] > > > > > > 4) step3.tpl (this redirect to a protected page) > > [redirect http://www.adomain.com/anypage.tpl] > > > > 5) anypage.tpl (can be any page protected by Authenticate). > > [include file=^protect.inc&groups=mygroup] Hello [username], [password]. > > ***** > > > > I couldn't get it to work before because nowhere on MY test step2.tpl (see above) was there an [authenticate] or [protect] tag. One of those tags *must* be on the page > > where the [redirect] goes (the [redirect] you use to construct the URL with the 'username:password' in it - see step1.tpl above) I don't understand why it needs to be > > there, because even if you wrap it in a [showif] which will definately evaluate to false if *just* the username is valid (but the password doesn't have to be valid for > > the [showif] to evaluate false) and login with a proper username but invalid password (thus the [showif] skips over the [authenticate]) it somehow still gets the username > > and password that were input in the HTML form into the browsers's cache (at least that is where you guys tell me username and password live). But without that > > [authenticate] it will never get into the browser's cache - whether the username is valid or not, and whether the password is valid or not (ie- under no circumstances). > > I did tests using [elapsedtime] to see if webcat really does skip over things wrapped in a [showif] which evalutes to false and it does indeed seem to (as opposed to > > reading the code and then removing it 'after the fact') , so then > > > > **** !!! WHY DOES the [authenticate] have to be on step2.tpl even if the user inputs a proper username which would skip over the tag in the first place?? !!! **** > > > > can anyone explain this very bizarre (but in this case advanatgeous) behaviour?? > > ?? > > -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/ > > ------------------------------------------------------------- > 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/------------------------------------------------------------- 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 Peacock

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:

Forms Search Questions (1997) WebCat2b13MacPlugIn - [include] doesn't allow creator (1997) Re[2]: 2nd WebCatalog2 Feature Request (1996) Webcat Manual and TeaRoom Examples Uses Different Examples. (1997) Serving Images from SSL (was NT vs Mac) (1997) ExclusiveLock (2000) Looking for a special Image Upload Script (2004) ShowNext Command (1997) [WebDNA] Libmysql.dll error (2009) WebCatalog 2.0 b 15 mac (1997) Problems with [Math] (1998) WebCatalog can't find database (1997) Re1000001: Setting up shop (1997) WebCat2b12--[searchstring] bug (1997) New WebDNA Solutions ... (1997) Listserver problem (1997) Unceremonious Unwanted Unsubscription (1999) Credit Card Number checking (1997) WebCat for mass emailings (1997) Question about Webcatalog and Webstar for Mac OS X (1998)