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 = 113093
interpreted = N
texte = 681 Another part to this is that it breaks from standards. Most languages all have =91session=92.. and it follows similar standards = that programmers just simply need for session ability=85 such as the = ability to write a name:value to it (as our [Orderfile] context already = does) Here is a good breakdown from someone for RAILS session: http://www.justinweiss.com/articles/how-rails-sessions-work PHP Session: http://www.w3schools.com/php/php_sessions.asp Both solutions, and many others, have similar features=85 and they are = not that unlike WebDNA [orderfile] tag. Again, I would update WebDNA=92s [orderfile] system in the following = way: - Make use of WebDNA=92s newer [function] conventions. - Add additional storage options: (database and cookies.. maybe set as a preference in the WebDNA = prefs, and overwrite able in the tags themselves. ) - standard operating procedure for secure cookies (hash=92ed or = encrypted values), etc. - change or alias the cart=3D[cart] param to something like =93id=3D=93. = (currently there is =91cart=3D=91 and =91file=3D=91.. simply make =91id=3D= =91 an alias of =91cart=3D=91 - Alias the name [session] to [orderfile]=85 so, in final, it would = look something like this: - maybe deprecate setheader (see below) Viewing session info: [session id=3D[unique]] [FirstName] [LastName] [address] =20 [lineitems] [index], [SKU] [/lineitems] [/session] Setting Session info (instead of setHeader): [session id=3D[uniqueid]&FirstName=3DChristophe] End a session [sessionend id=3D[uniqueid]] That=92s just quickly some ideas off the top of my head=85 probably = other ways to skin the cat.=20 For the current [session] implementation.. maybe simplify it and call it = [fingerprint]=85 if it worked you could use it with my above method for = the unique id and not use cookies: [session id=3D[fingerprint]] [/session] That=92s only if it worked reliably Sincerely, Donovan On Oct 24, 2016, at 2:15 AM, Tom Duke
wrote: > Hi, >=20 > I have just been playing around with the [session] tag. =20 >=20 > I was hoping that the 'browserID' could be used to uniquely identify = the users's browser / platform, so if that changed you could perhaps ask = them for additional security measures - maybe a code sent by SMS etc. I = have seen this used on SalesForce and a few other sites. >=20 > I created sessions using three browsers on the same Mac and got the = following in the 'reserved.db' >=20 > from to > = b8209467353258d27f2103a6a9cee1a0cf3576ec368c9d58a3da63774bdab69f95816e539c= fa8b9dc7a65bdfe097d0e3 = 47fc3abacbfdcc8a93246650b8228f73e4e810c720711a36a06de0672b8b8cf4 > = 7f3ec9a0208d0c744e81e3f23b3630989233511a49bfd5b51e55d6767194635b51acef8a11= 97f194d756a7c2877bd3f6 = 47fc3abacbfdcc8a93246650b8228f73e4e810c720711a36a06de0672b8b8cf4 > = 3b406cd34ccfc83771a24673250c2098114acffb2086f5305f90742d662b73ce4b030284d6= 5fc18bfce57e423a0d392c = 47fc3abacbfdcc8a93246650b8228f73e4e810c720711a36a06de0672b8b8cf4 >=20 > It looks like the same browserID was generated for sessions created by = Safari, Chrome and Firefox. Am I missing something here, should there = not be a different browserID for different browsers? >=20 > - Tom >=20 >=20 >=20 >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Digital Revolutionaries > 1st Floor, Castleriver House > 14-15 Parliament Street > Temple Bar,Dublin 2 > Ireland > ---------------------------------------------- > [t]: + 353 1 4403907 > [e]: > [w]: > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > On 23 October 2016 at 20:02, Michael Davis = wrote: > What about the case where a company, school or organization has its = network behind a single NAT'd address? There would be an unknown number = of unique visitors with the same IP address, and for some companies, the = same exact browser is also a requirement. >=20 >=20 > -MD >=20 > > On Oct 21, 2016, at 11:55 AM, christophe.billiottet@webdna.us wrote: > > > > Yes, or you can capture the IP and reload the session without = passing anything: you just compare the IP with the stored session IP and = if it matches then you can reload the session individually for each = page. Or you can use browserID. > > > > > > > > > > > >> On Oct 21, 2016, at 21:46, Kenneth Grome = wrote: > >> > >> Don't you have to pass a parameter in links and forms to make it = work? > >> > >> Regards, > >> Kenneth Grome > >> WebDNA Solutions > >> http://www.webdnasolutions.com > >> Web Database Systems and Linux Server Administration > >> > >> > >> > >> On 10/21/2016 01:27 PM, christophe.billiottet@webdna.us wrote: > >>> [session] is a built-in WebDNA process that very simply allows to = build a session. Compared to a cookie, it is easier to use (You don=92t = have to care about the technical aspects of the cookie like date format = etc=85), safer (nothing is written on the visitor side), faster (RAM = based instead of being read and written to the browser), and gives you a = better control (you can kill a session very easily, or move it from one = browser to another if necessary) > >>> Instead of just being a serial number like the [ORDERFILE], if = follows without showing and keep information about the visitor. > >>> Information about a session is stored and can be used later. > >>> > >>> - chris > > > > > > > > > > > > --------------------------------------------------------- > > 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 >=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 >=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:
681 Another part to this is that it breaks from standards. Most languages all have =91session=92.. and it follows similar standards = that programmers just simply need for session ability=85 such as the = ability to write a name:value to it (as our [orderfile] context already = does) Here is a good breakdown from someone for RAILS session: http://www.justinweiss.com/articles/how-rails-sessions-work PHP Session: http://www.w3schools.com/php/php_sessions.asp Both solutions, and many others, have similar features=85 and they are = not that unlike WebDNA [orderfile] tag. Again, I would update WebDNA=92s [orderfile] system in the following = way: - Make use of WebDNA=92s newer [function] conventions. - Add additional storage options: (database and cookies.. maybe set as a preference in the WebDNA = prefs, and overwrite able in the tags themselves. ) - standard operating procedure for secure cookies (hash=92ed or = encrypted values), etc. - change or alias the cart=3D[cart] param to something like =93id=3D=93. = (currently there is =91cart=3D=91 and =91file=3D=91.. simply make =91id=3D= =91 an alias of =91cart=3D=91 - Alias the name [session] to [orderfile]=85 so, in final, it would = look something like this: - maybe deprecate setheader (see below) Viewing session info: [session id=3D[unique]] [FirstName] [LastName] [address] =20 [lineitems] [index], [SKU] [/lineitems] [/session] Setting Session info (instead of setHeader): [session id=3D[uniqueid]&FirstName=3DChristophe] End a session [sessionend id=3D[uniqueid]] That=92s just quickly some ideas off the top of my head=85 probably = other ways to skin the cat.=20 For the current [session] implementation.. maybe simplify it and call it = [fingerprint]=85 if it worked you could use it with my above method for = the unique id and not use cookies: [session id=3D[fingerprint]] [/session] That=92s only if it worked reliably Sincerely, Donovan On Oct 24, 2016, at 2:15 AM, Tom Duke wrote: > Hi, >=20 > I have just been playing around with the [session] tag. =20 >=20 > I was hoping that the 'browserID' could be used to uniquely identify = the users's browser / platform, so if that changed you could perhaps ask = them for additional security measures - maybe a code sent by SMS etc. I = have seen this used on SalesForce and a few other sites. >=20 > I created sessions using three browsers on the same Mac and got the = following in the 'reserved.db' >=20 > from to > = b8209467353258d27f2103a6a9cee1a0cf3576ec368c9d58a3da63774bdab69f95816e539c= fa8b9dc7a65bdfe097d0e3 = 47fc3abacbfdcc8a93246650b8228f73e4e810c720711a36a06de0672b8b8cf4 > = 7f3ec9a0208d0c744e81e3f23b3630989233511a49bfd5b51e55d6767194635b51acef8a11= 97f194d756a7c2877bd3f6 = 47fc3abacbfdcc8a93246650b8228f73e4e810c720711a36a06de0672b8b8cf4 > = 3b406cd34ccfc83771a24673250c2098114acffb2086f5305f90742d662b73ce4b030284d6= 5fc18bfce57e423a0d392c = 47fc3abacbfdcc8a93246650b8228f73e4e810c720711a36a06de0672b8b8cf4 >=20 > It looks like the same browserID was generated for sessions created by = Safari, Chrome and Firefox. Am I missing something here, should there = not be a different browserID for different browsers? >=20 > - Tom >=20 >=20 >=20 >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Digital Revolutionaries > 1st Floor, Castleriver House > 14-15 Parliament Street > Temple Bar,Dublin 2 > Ireland > ---------------------------------------------- > [t]: + 353 1 4403907 > [e]: > [w]: > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > On 23 October 2016 at 20:02, Michael Davis = wrote: > What about the case where a company, school or organization has its = network behind a single NAT'd address? There would be an unknown number = of unique visitors with the same IP address, and for some companies, the = same exact browser is also a requirement. >=20 >=20 > -MD >=20 > > On Oct 21, 2016, at 11:55 AM, christophe.billiottet@webdna.us wrote: > > > > Yes, or you can capture the IP and reload the session without = passing anything: you just compare the IP with the stored session IP and = if it matches then you can reload the session individually for each = page. Or you can use browserID. > > > > > > > > > > > >> On Oct 21, 2016, at 21:46, Kenneth Grome = wrote: > >> > >> Don't you have to pass a parameter in links and forms to make it = work? > >> > >> Regards, > >> Kenneth Grome > >> WebDNA Solutions > >> http://www.webdnasolutions.com > >> Web Database Systems and Linux Server Administration > >> > >> > >> > >> On 10/21/2016 01:27 PM, christophe.billiottet@webdna.us wrote: > >>> [session] is a built-in WebDNA process that very simply allows to = build a session. Compared to a cookie, it is easier to use (You don=92t = have to care about the technical aspects of the cookie like date format = etc=85), safer (nothing is written on the visitor side), faster (RAM = based instead of being read and written to the browser), and gives you a = better control (you can kill a session very easily, or move it from one = browser to another if necessary) > >>> Instead of just being a serial number like the [orderfile], if = follows without showing and keep information about the visitor. > >>> Information about a session is stored and can be used later. > >>> > >>> - chris > > > > > > > > > > > > --------------------------------------------------------- > > 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 >=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 >=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:
Pgp&emailer (1997)
2.0 Info (1997)
Misc Stuff That Might Help (1997)
Embedded [Search] Context Snippets (Very Useful) (1998)
CMSBuilder (2004)
Refreshing Javascript (2001)
PSC recommends what date format yr 2000??? (1997)
WebCat B13 Mac CGI -- Frames question (1997)
help with autenticate (1998)
[dos] command question (1997)
# of real domains on 1 web server (1997)
RE: Remote administration (1998)
[WebDNA] Error installing v6.2 on Ubuntu 10.10 ... (2010)
Smith Micro - no competition (2000)
Re[2]: Re[2]: Re[2]: OT: Amazon Patents (2000)
Replace context problem ... (1997)
Two SynchThreads prefs (2000)
Auto Unsubscribe (2000)
[showif] / [hideif] (1997)
orderfile and setlineitems (1998)