I am looking for some pointers about how to best manage session state between a main page (which requires a login and carries a session around) and various elements which are injected into that page using Prototype''s Ajax goodies. Are there any techniques for session management that are considered to be safer/better/whatever-er than others? The application is a sort of Google Groups clone for a set of mailing lists. I have already been bitten by one issue with using sessions for everything -- several of my users love their tabs, and so I had to move some of my variables into hidden form elements in order to keep from getting the session confused about which thread they were replying to. The back-end is PHP4 (not my choice), not that it matters much to this question, but I thought it might be prudent to nip the Ruby or Rails suggestions in the bud. Thanks in advance, Walter --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
Walter Lee Davis wrote:> The application is a sort of Google Groups clone for a set of mailing > lists. I have already been bitten by one issue with using sessions > for everything -- several of my users love their tabs, and so I had > to move some of my variables into hidden form elements in order to > keep from getting the session confused about which thread they were > replying to.To tackle this in Krang we used just an extra cookie which indicates the window/tab being used. Each person/window combination get''s their own session so you can edit your content in one window without worrying about the session in the other. This let''s you still keep the session data in the session without having to worry about so many hidden inputs. -- Michael Peters Developer Plus Three, LP --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
Great idea. As a usability question though, since I know about session states and such, I often will force a site to give me two browsers on the same session - by ctrl-[n|t] rather than starting a brand new browser instance, especially if i''m looking at multiple things at once - a development site which has multiple potential logins and trying to compare data between them is a good example; say i included the unique-session-per-tab code. What would the preferred way for a user to instantiate/not instantiate a new session be? Hope that makes sense, sorry to hijack thread. Gareth On 11/28/07, Michael Peters <mpeters-aUYv5hkjw45l57MIdRCFDg@public.gmane.org> wrote:> > > Walter Lee Davis wrote: > > > The application is a sort of Google Groups clone for a set of mailing > > lists. I have already been bitten by one issue with using sessions > > for everything -- several of my users love their tabs, and so I had > > to move some of my variables into hidden form elements in order to > > keep from getting the session confused about which thread they were > > replying to. > > To tackle this in Krang we used just an extra cookie which indicates the > window/tab being used. Each person/window combination get''s their own > session so > you can edit your content in one window without worrying about the session > in > the other. This let''s you still keep the session data in the session > without > having to worry about so many hidden inputs. > > -- > Michael Peters > Developer > Plus Three, LP > > > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
This is all OK in theory... The thing is, I just tried to login to a site of mine, which uses sessions only to auth users and opened another tab in FF BEFORE I logged in in the first tab. After logging in in the #1 tab, I refreshed #2 tab, and I was magically logged in! OMG! :D This means that the Session cookie is shared across all tabs AND windows in FF. If I were you, I''d leave the logic to be done by the browser. Just tested it in IE, FF with tabs, FF with windows, FF with new instance of the program. Try examining your login procedures, cause this looks pretty strange to me... On Nov 27, 8:33 pm, "Gareth Evans" <agr...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> Great idea. > > As a usability question though, since I know about session states and such, > I often will force a site to give me two browsers on the same session - > by ctrl-[n|t] rather than starting a brand new browser instance, especially > if i''m looking at multiple things at once - a development site which has > multiple potential logins and trying to compare data between them is a good > example; say i included the unique-session-per-tab code. > > What would the preferred way for a user to instantiate/not instantiate a new > session be? > > Hope that makes sense, sorry to hijack thread. > > Gareth > > On 11/28/07, Michael Peters <mpet...-aUYv5hkjw45l57MIdRCFDg@public.gmane.org> wrote: > > > > > Walter Lee Davis wrote: > > > > The application is a sort of Google Groups clone for a set of mailing > > > lists. I have already been bitten by one issue with using sessions > > > for everything -- several of my users love their tabs, and so I had > > > to move some of my variables into hidden form elements in order to > > > keep from getting the session confused about which thread they were > > > replying to. > > > To tackle this in Krang we used just an extra cookie which indicates the > > window/tab being used. Each person/window combination get''s their own > > session so > > you can edit your content in one window without worrying about the session > > in > > the other. This let''s you still keep the session data in the session > > without > > having to worry about so many hidden inputs. > > > -- > > Michael Peters > > Developer > > Plus Three, LP--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
To answer your question more accurately, Ajax should send the SID cookie with each and every request, so the server sees it just like a regular HTTP request to it. The only difference is that (if your server supports it) the Ajax.Request sends also a X-Requested-With: XMLHttpRequest header to the server, so you can differentiate it server-side. But the server sees the request with all the cookies. Get a FireBug (http://www.getfirebug.com/) and examine the headers/ cookies sent to the browser, also by XHR (Ajax). The best way to go is to make sure for yourself! On Nov 27, 4:38 pm, Walter Lee Davis <wa...-HQgmohHLjDZWk0Htik3J/w@public.gmane.org> wrote:> I am looking for some pointers about how to best manage session state > between a main page (which requires a login and carries a session > around) and various elements which are injected into that page using > Prototype''s Ajax goodies. > > Are there any techniques for session management that are considered > to be safer/better/whatever-er than others? > > The application is a sort of Google Groups clone for a set of mailing > lists. I have already been bitten by one issue with using sessions > for everything -- several of my users love their tabs, and so I had > to move some of my variables into hidden form elements in order to > keep from getting the session confused about which thread they were > replying to. > > The back-end is PHP4 (not my choice), not that it matters much to > this question, but I thought it might be prudent to nip the Ruby or > Rails suggestions in the bud. > > Thanks in advance, > > Walter--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
I think at the end of the day, it''s up to the web server (applicaiton server) and how it assigns session cookies. I am pretty sure iis/asp will assign a new session cookie to a user who doesnt pass one in to begin with, which might explain why the ''new tab'' scenario for my application results in the same session, and a new browser instance will give me a new session. maybe apache/php assigns based the same session cookie based on ip address & user agent & something else [?] if no cookie is passed in, or some other scheme... Gareth On Nov 29, 2007 1:37 AM, LexNonScripta <lex.non.scripta-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > To answer your question more accurately, Ajax should send the SID > cookie with each and every request, so the server sees it just like a > regular HTTP request to it. > > The only difference is that (if your server supports it) the > Ajax.Request sends also a X-Requested-With: XMLHttpRequest header to > the server, so you can differentiate it server-side. But the server > sees the request with all the cookies. > > Get a FireBug (http://www.getfirebug.com/) and examine the headers/ > cookies sent to the browser, also by XHR (Ajax). The best way to go is > to make sure for yourself! > > On Nov 27, 4:38 pm, Walter Lee Davis <wa...-HQgmohHLjDZWk0Htik3J/w@public.gmane.org> wrote: > > I am looking for some pointers about how to best manage session state > > between a main page (which requires a login and carries a session > > around) and various elements which are injected into that page using > > Prototype''s Ajax goodies. > > > > Are there any techniques for session management that are considered > > to be safer/better/whatever-er than others? > > > > The application is a sort of Google Groups clone for a set of mailing > > lists. I have already been bitten by one issue with using sessions > > for everything -- several of my users love their tabs, and so I had > > to move some of my variables into hidden form elements in order to > > keep from getting the session confused about which thread they were > > replying to. > > > > The back-end is PHP4 (not my choice), not that it matters much to > > this question, but I thought it might be prudent to nip the Ruby or > > Rails suggestions in the bud. > > > > Thanks in advance, > > > > Walter > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
Good argument! But AFAIK, PHP uses COOKIE / SID only! If no cookies are supported it checks all links in the output buffer for the same domain and appends href.php?myParam=xyz&SID=xyz65sde...(sessionID) This really baffles me.. Someone put a stop to this debate! On Nov 29, 12:19 am, "Gareth Evans" <agr...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> I think at the end of the day, it''s up to the web server (applicaiton > server) and how it assigns session cookies. > I am pretty sure iis/asp will assign a new session cookie to a user who > doesnt pass one in to begin with, which might explain why the ''new tab'' > scenario for my application results in the same session, and a new browser > instance will give me a new session. > maybe apache/php assigns based the same session cookie based on ip address & > user agent & something else [?] if no cookie is passed in, or some other > scheme... > > Gareth > > On Nov 29, 2007 1:37 AM, LexNonScripta <lex.non.scri...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > To answer your question more accurately, Ajax should send the SID > > cookie with each and every request, so the server sees it just like a > > regular HTTP request to it. > > > The only difference is that (if your server supports it) the > > Ajax.Request sends also a X-Requested-With: XMLHttpRequest header to > > the server, so you can differentiate it server-side. But the server > > sees the request with all the cookies. > > > Get a FireBug (http://www.getfirebug.com/) and examine the headers/ > > cookies sent to the browser, also by XHR (Ajax). The best way to go is > > to make sure for yourself! > > > On Nov 27, 4:38 pm, Walter Lee Davis <wa...-HQgmohHLjDZWk0Htik3J/w@public.gmane.org> wrote: > > > I am looking for some pointers about how to best manage session state > > > between a main page (which requires a login and carries a session > > > around) and various elements which are injected into that page using > > > Prototype''s Ajax goodies. > > > > Are there any techniques for session management that are considered > > > to be safer/better/whatever-er than others? > > > > The application is a sort of Google Groups clone for a set of mailing > > > lists. I have already been bitten by one issue with using sessions > > > for everything -- several of my users love their tabs, and so I had > > > to move some of my variables into hidden form elements in order to > > > keep from getting the session confused about which thread they were > > > replying to. > > > > The back-end is PHP4 (not my choice), not that it matters much to > > > this question, but I thought it might be prudent to nip the Ruby or > > > Rails suggestions in the bud. > > > > Thanks in advance, > > > > Walter--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
> But AFAIK, PHP uses COOKIE / SID only! If no cookies are supported it > checks all links in the output buffer for the same domain and appends > href.php?myParam=xyz&SID=xyz65sde...(sessionID)I''m not sure what is really baffling about it.... Here is a sample of the session data from an active session I had yesterday (switching to cookies saved in a database really opens your eyes up to more of what is involved with session storage) ''c5b5d8dbd5eb2d244446eda6c9645952'', ''2007-11-30 20:52:44'', ''2007-11-30 20:52:30'', ''id|s:2:"20";first_name|s:4:"demo";last_name|s:4:"demo";email|s:4:"demo";level|s:1:"1";timeout|i:1196481164;'', ''61.85.69.000'', ''Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)''); the first line is the server generated session_id 2nd & 3rd lines are session_time and session_date 4th is the various session values set from the login funcion - notice there is also information regarding the length of the variable ( session var name | session var length : length value : "actual_value" ) IP address and finally user agent so there is more involved than just the PHPSESSID cookie sitting in the browser. but ultimately on the user side... the session is dependant upon that PHPSESSID. if the browser doesn''t send one to the server in some manner whether it be through cookie or through the GET or the POST then the server says, "hey, its a newbie, give it a new session id" Apache and PHP are default configured to automatically assign a Session Cookie and can also be configured to auto-append the session id to the URL -- but with SEO suggestions and "friendly" URLs this is now really frowned upon to restart a PHP session you simply have to use session_start();at the beginning of your php file. if you use named sessions (and this is might be the answer to the OP) you could put an if statement such as the really convoluted example below if($_POST[level] == ''admin'' && $account->checkUserRightsSecondary($_POST[user],$_POST[pass],$_SERVER[PHP_SELF]){ $group_id = $group->getGroupId($_SERVER[PHP_SELF]); session_name(/*some way to put a unique (non-random) id*/ .''_''.$group_id); session_start(); //do function to set all session values to allow for the user to do whatever }else{ //just start a regular session to do whatever else session_start() } (please note this is off the top of my head, I have never tried to do something like this and probably will require an advanced infrastructure to pull something like this off correctly, and I haven''t even really considered what this would do to the already existing session id assigned to the browser) check out http://www.php.net/manual/en/function.session-start.php for more info. additionally for the OP - you could make it a LOT easier on yourself and use iframes in a tabbed gui and then use an autoupdater inside the iframe - contrary to popular believe there is nothing wrong with iframes - gmail uses them, gotapi uses them, loads of sites use them. On Dec 1, 2007 11:20 AM, LexNonScripta <lex.non.scripta-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > Good argument! > > But AFAIK, PHP uses COOKIE / SID only! If no cookies are supported it > checks all links in the output buffer for the same domain and appends > href.php?myParam=xyz&SID=xyz65sde...(sessionID) > > This really baffles me.. Someone put a stop to this debate! > > On Nov 29, 12:19 am, "Gareth Evans" <agr...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > I think at the end of the day, it''s up to the web server (applicaiton > > server) and how it assigns session cookies. > > I am pretty sure iis/asp will assign a new session cookie to a user who > > doesnt pass one in to begin with, which might explain why the ''new tab'' > > scenario for my application results in the same session, and a new browser > > instance will give me a new session. > > maybe apache/php assigns based the same session cookie based on ip address & > > user agent & something else [?] if no cookie is passed in, or some other > > scheme... > > > > Gareth > > > > > On Nov 29, 2007 1:37 AM, LexNonScripta <lex.non.scri...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > > > > > > To answer your question more accurately, Ajax should send the SID > > > cookie with each and every request, so the server sees it just like a > > > regular HTTP request to it. > > > > > The only difference is that (if your server supports it) the > > > Ajax.Request sends also a X-Requested-With: XMLHttpRequest header to > > > the server, so you can differentiate it server-side. But the server > > > sees the request with all the cookies. > > > > > Get a FireBug (http://www.getfirebug.com/) and examine the headers/ > > > cookies sent to the browser, also by XHR (Ajax). The best way to go is > > > to make sure for yourself! > > > > > On Nov 27, 4:38 pm, Walter Lee Davis <wa...-HQgmohHLjDZWk0Htik3J/w@public.gmane.org> wrote: > > > > I am looking for some pointers about how to best manage session state > > > > between a main page (which requires a login and carries a session > > > > around) and various elements which are injected into that page using > > > > Prototype''s Ajax goodies. > > > > > > Are there any techniques for session management that are considered > > > > to be safer/better/whatever-er than others? > > > > > > The application is a sort of Google Groups clone for a set of mailing > > > > lists. I have already been bitten by one issue with using sessions > > > > for everything -- several of my users love their tabs, and so I had > > > > to move some of my variables into hidden form elements in order to > > > > keep from getting the session confused about which thread they were > > > > replying to. > > > > > > The back-end is PHP4 (not my choice), not that it matters much to > > > > this question, but I thought it might be prudent to nip the Ruby or > > > > Rails suggestions in the bud. > > > > > > Thanks in advance, > > > > > > Walter > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---