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:
PSC recommends what date format yr 2000??? (1997)
NT vs Mac (1997)
Upgrading old WebCat Database Files (1997)
Running _every_ page through WebCat ? (1997)
WebCat2 - [format thousands] (1997)
DON'T use old cart file! (1997)
RE: [WebDNA] WebDNA not running after 10.6.3 update (2010)
[format xs] freeze (1997)
new PurgeDatabase command? (was NT vs Mac) (1997)
[shownext max=?] armed (1997)
[WebDNA] unused database fields. . . . (2014)
formula??? (2000)
Platform Switch (1997)
wow (1998)
OK, here goes... (1997)
Date question (2003)
Why WebDNA is not popular (2002)
Using Applescript to process WebCatalog functions (1998)
ConverChars (1999)
[SearchString] problem with [search] context (1997)