Re: [WebDNA] User sessions - cookies only or cookies and a sessions.db?
This WebDNA talk-list message is from 2016
It keeps the original formatting.
numero = 113079
interpreted = N
texte = 667 I too am a bit confused about the new tag.. is there examples of use = somewhere? Passing a session ID in GET / POST is what we did (and do) with the = [ORDERFILE].. in that respect, I don=92t see anything new, except that = session uses a .db where the orderfile uses a file. It was my = recommendation way back when to simply ad a .db option flag to = [orderfile]=85. then user would have an option between file and .db=85 = or both.=20 Sessions are not that difficult and yes, they can be secured using = cookies. You can also have a fallback if cookies are not enabled to = passing the session ID (just like PHP=92s SESSION). I see that =93search engines=94 are listed as a *positive* regarding = passing the session ID. I don=92t see how that is a positive. One of the = biggest problems of passing a session ID is that it either get=92s bookmarked, or stuck in the search engine.. then those links end up = hitting an already used session, purchased cart, or could reveal someone = else=92s session info.=20 Anyway, I=92m not saying it doesn=92t have worth. but I am saying I = don=92t understand it=85 especially without the use of a cookie, which = is more secure in my opinion.=20 for Dales needs, a simple session could be: - [cart], perhaps encrypted with a seed, to a session cookie. - links to the user.db ID.=20 - expires in cookie set as needed.=20 Basically a less involved version of Tom=92s very good description of a = robust session system. my .02=A2 Donovan On Oct 21, 2016, at 4:25 AM, Tom Duke
wrote: > Dale, >=20 > Hi - I use a cookie - set when the user authenticates - and a = session.db. >=20 > Cookies are encrypted and set as HTTP_only and secure if SSL is = available. The session cookie should really only be transmitted over = SSL. >=20 > The session.db links the cookie to the user. There is a session-time = field in the DB which is updated on each page refresh. If session-time = is greater than the idle time setting (usually 30 minutes), then the = user is kicked out and has to re-login. >=20 > I haven't used the new [session] tag. Looks interesting, but unless = I'm reading the spec incorrectly it looks like the [session] has to = passed around as part of the URL - or in post data. That's not = something I really want to do. >=20 > Maybe the [browserIDmatch] tag could be used as an extra check though = - I assume that should be consistent for a specific browser regardless = of the actual session value? >=20 > - Tom >=20 >=20 > --------------------------------------------------------- This message = is sent to you because you are subscribed to the mailing list . To = unsubscribe, E-mail to: archives: = http://mail.webdna.us/list/talk@webdna.us Bug Reporting: = support@webdna.us --------------------------------------------------------- This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: archives: http://mail.webdna.us/list/talk@webdna.us Bug Reporting: support@webdna.us .
Associated Messages, from the most recent to the oldest:
667 I too am a bit confused about the new tag.. is there examples of use = somewhere? Passing a session ID in GET / POST is what we did (and do) with the = [orderfile].. in that respect, I don=92t see anything new, except that = session uses a .db where the orderfile uses a file. It was my = recommendation way back when to simply ad a .db option flag to = [orderfile]=85. then user would have an option between file and .db=85 = or both.=20 Sessions are not that difficult and yes, they can be secured using = cookies. You can also have a fallback if cookies are not enabled to = passing the session ID (just like PHP=92s SESSION). I see that =93search engines=94 are listed as a *positive* regarding = passing the session ID. I don=92t see how that is a positive. One of the = biggest problems of passing a session ID is that it either get=92s bookmarked, or stuck in the search engine.. then those links end up = hitting an already used session, purchased cart, or could reveal someone = else=92s session info.=20 Anyway, I=92m not saying it doesn=92t have worth. but I am saying I = don=92t understand it=85 especially without the use of a cookie, which = is more secure in my opinion.=20 for Dales needs, a simple session could be: - [cart], perhaps encrypted with a seed, to a session cookie. - links to the user.db ID.=20 - expires in cookie set as needed.=20 Basically a less involved version of Tom=92s very good description of a = robust session system. my .02=A2 Donovan On Oct 21, 2016, at 4:25 AM, Tom Duke wrote: > Dale, >=20 > Hi - I use a cookie - set when the user authenticates - and a = session.db. >=20 > Cookies are encrypted and set as HTTP_only and secure if SSL is = available. The session cookie should really only be transmitted over = SSL. >=20 > The session.db links the cookie to the user. There is a session-time = field in the DB which is updated on each page refresh. If session-time = is greater than the idle time setting (usually 30 minutes), then the = user is kicked out and has to re-login. >=20 > I haven't used the new [session] tag. Looks interesting, but unless = I'm reading the spec incorrectly it looks like the [session] has to = passed around as part of the URL - or in post data. That's not = something I really want to do. >=20 > Maybe the [browserIDmatch] tag could be used as an extra check though = - I assume that should be consistent for a specific browser regardless = of the actual session value? >=20 > - Tom >=20 >=20 > --------------------------------------------------------- This message = is sent to you because you are subscribed to the mailing list . To = unsubscribe, E-mail to: archives: = http://mail.webdna.us/list/talk@webdna.us Bug Reporting: = support@webdna.us --------------------------------------------------------- This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: archives: http://mail.webdna.us/list/talk@webdna.us Bug Reporting: support@webdna.us .
Donovan Brooke
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:
IP Address (2001)
Is it possible to pause or wait a process (2000)
What file? (1997)
Serial Number Question (1997)
[WebDNA] Problem with Sendmail (2012)
Date/Time format problems (1997)
Version f1 status (1997)
Searching Multiple Databases (2000)
taxRate is fine but taxTotal isn't (1997)
SETCOOKIE Problems (2003)
Multi Math bug? (2000)
HomePage Caution (1997)
Emailer and encryption (1997)
format_to_days on NT (1997)
Some Questions (1997)
founditem align (1998)
WebCatalog/WebMerchant Manuals Available (1998)
Multiple Newcarts (1996)
WebDNA's portability (2007)
SendTo more emails (1998)