Re: login via cookies

This WebDNA talk-list message is from

2006


It keeps the original formatting.
numero = 67080
interpreted = N
texte = Lester wrote: > After I search the db and they have in fact entered > the correct user/pass I do: > > [SETCOOKIE > name=siteblogger&value=[cart]&domain=site.com] > Blogger Admin > > Am I then incorporating the cookie just set within > MemberChecker on all other protected pages to see if > it exists and if so they continue onward??? Yes, that sounds about right. Just keep in mind that subdomain names may count, so a cookie with domain=site.com may not work on a page at www.site.com and vice versa. > ....or another way > > Is using [cart] as a cookie a good idea? That depends. Remember the user can access and read the value the cookie is set to. If that's OK, there shouldn't be any problem. The only important thing is that the cookie is set to a value that's easily identifiable/retievable throughtout the time the cookie lasts. In low-security setups you can simply use a constant string, such as "OK" (without the quotes of course) as the cookie value. I use the username and password for each member as the cookie's value. That way I can be sure the it doesn't give away any info the user doesn't already know. I actually have the name/password value stored in a separate field in the members database, although that's not necessary of course. Just a result of fuzzy thinking when I wrote the script in the first place - and no urgent need to change anything afterwards. For maximum security you can assign a random correct cookie value for each member of course - and even set up some algorithm to create a new correct value each time a member logs on (your [CART] solution seems to do exactly that). Just remember that the cookie value must always be retrievable, that is the server has to know what value is the right one each and every time it encounters a [GETCOOKIE] tag! > Anyone have some simple example code with cookies for > login??? Once you've set the cookie it should be fairly easy going. Just retrieve the cookie value using the [GETCOOKIE] tag and [HIDEIF]/[SHOWIF] contexts to display and/or hide page content depending on whether the cookie is correctly set. Something like: [HIDEIF/SHOWIF {correct cookie value}=[GETCOOKIE {cookiename}] The code I actually use is slightly more complicated: [HIDEIF/SHOWIF OK=[LOOKUP db={members database}&lookInField=CCODE&value=[GETCOOKIE {cookiename}]&returnField=STATUS¬Found=no]] My members database includes (among others) two fields named CCODE and STATUS CCODE is the field with the individual cookie value for each member tat I mentioned earlier. STATUS is - well the status of that particular member. If the value there is "OK" the membership is still valid, if not it's expired. Frank Nordberg http://www.musicaviva.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://webdna.smithmicro.com/ Associated Messages, from the most recent to the oldest:

    
  1. Re: login via cookies ( Frank Nordberg 2006)
  2. Re: login via cookies ( "Dan Strong" 2006)
  3. Re: login via cookies ( Bob Minor 2006)
  4. Re: login via cookies ( "Dan Strong" 2006)
  5. Re: login via cookies ( Lester 2006)
  6. Re: login via cookies ( Frank Nordberg 2006)
  7. Re: login via cookies ( Gary Krockover 2006)
  8. login via cookies ( Lester 2006)
Lester wrote: > After I search the db and they have in fact entered > the correct user/pass I do: > > [SETCOOKIE > name=siteblogger&value=[cart]&domain=site.com] > Blogger Admin > > Am I then incorporating the cookie just set within > MemberChecker on all other protected pages to see if > it exists and if so they continue onward??? Yes, that sounds about right. Just keep in mind that subdomain names may count, so a cookie with domain=site.com may not work on a page at www.site.com and vice versa. > ....or another way > > Is using [cart] as a cookie a good idea? That depends. Remember the user can access and read the value the cookie is set to. If that's OK, there shouldn't be any problem. The only important thing is that the cookie is set to a value that's easily identifiable/retievable throughtout the time the cookie lasts. In low-security setups you can simply use a constant string, such as "OK" (without the quotes of course) as the cookie value. I use the username and password for each member as the cookie's value. That way I can be sure the it doesn't give away any info the user doesn't already know. I actually have the name/password value stored in a separate field in the members database, although that's not necessary of course. Just a result of fuzzy thinking when I wrote the script in the first place - and no urgent need to change anything afterwards. For maximum security you can assign a random correct cookie value for each member of course - and even set up some algorithm to create a new correct value each time a member logs on (your [cart] solution seems to do exactly that). Just remember that the cookie value must always be retrievable, that is the server has to know what value is the right one each and every time it encounters a [GETCOOKIE] tag! > Anyone have some simple example code with cookies for > login??? Once you've set the cookie it should be fairly easy going. Just retrieve the cookie value using the [GETCOOKIE] tag and [hideif]/[showif] contexts to display and/or hide page content depending on whether the cookie is correctly set. Something like: [HIDEIF/SHOWIF {correct cookie value}=[GETCOOKIE {cookiename}] The code I actually use is slightly more complicated: [HIDEIF/SHOWIF OK=[LOOKUP db={members database}&lookInField=CCODE&value=[GETCOOKIE {cookiename}]&returnField=STATUS¬Found=no]] My members database includes (among others) two fields named CCODE and STATUS CCODE is the field with the individual cookie value for each member tat I mentioned earlier. STATUS is - well the status of that particular member. If the value there is "OK" the membership is still valid, if not it's expired. Frank Nordberg http://www.musicaviva.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://webdna.smithmicro.com/ Frank Nordberg

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:

Showif date range comparison (1999) Format of Required fields error message (1997) E-mailer error codes (1997) [WebDNA] New 7.1.702 version (2012) taxTotal, grandTotal (1997) Where's Cart Created ? (1997) I give up!! (1997) [WebDNA] =?windows-1252?Q?Re=3A_=5BWebDNA=5D_Anyone_got_Panic_CODA_2_up_a?= (2013) Serial Number Question (1997) [WebDNA] unix timestamp in WebDNA (2009) Press Release hit the NewsWire!!! (1997) Search in 2 or more catalogs (1997) What abobut variables named max ??? (2000) How can I record purchases to a database? (1998) [append] vs. [appendfile] delta + question? (1997) Multiple Pulldowns (1997) how to use WebCat w. SSL & CyberCash (1998) Too Much Rootbeer Free Offer (1997) aloha! (2002) WC1.6 to WC2 date formatting -FIXED! (1997)