Session management using cookies has one notable drawback: a user can''t have to concurrent sessions. At least not when using the same browser instance. This can at times result in confusing behavior when what the user does in one window affects how the application behaves in another window. Has anyone implemented session tracking without cookies, e.g. using URL rewriting? Michael -- Michael Schuerig I am the sum total of the parts mailto:michael-q5aiKMLteq4b1SvskN2V4Q@public.gmane.org I control directly. http://www.schuerig.de/michael/ --Daniel C. Dennett, Elbow Room
On 10/21/05, Michael Schuerig <michael-q5aiKMLteq4b1SvskN2V4Q@public.gmane.org> wrote:> > > Session management using cookies has one notable drawback: a user can''t > have to concurrent sessions. At least not when using the same browser > instance. This can at times result in confusing behavior when what the > user does in one window affects how the application behaves in another > window. >By two concurrent sessions you mean logged in under different usernames using the same browser? If it''s the same username it''s all the same session so that wouldn''t cause any problems. If you want to login as two separate users using the same browser, yes you can do it, it''s not a limit of cookies it''s a limit imposed by the implementation. And query strings are not necessary. For example, just use the username as part of the cookie name. As for how to mess with stuff like that in rails, I''m not sure. Chris _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
On 10/21/05, snacktime <snacktime-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > > > On 10/21/05, Michael Schuerig <michael-q5aiKMLteq4b1SvskN2V4Q@public.gmane.org> wrote: > > > > > > Session management using cookies has one notable drawback: a user can''t > > have to concurrent sessions. At least not when using the same browser > > instance. This can at times result in confusing behavior when what the > > user does in one window affects how the application behaves in another > > window. > > > > By two concurrent sessions you mean logged in under different usernames > using the same browser? If it''s the same username it''s all the same session > so that wouldn''t cause any problems. If you want to login as two separate > users using the same browser, yes you can do it, it''s not a limit of cookies > it''s a limit imposed by the implementation. And query strings are not > necessary. For example, just use the username as part of the cookie name. >To explain a bit more how you would do this. When someone creates an account you store the session id in the database along with their username, etc.. When someone logs in you get the session id from the database and reset the current session contents to the session associated with your stored session id. This gets you user specific cookies, and it also works around the issue of people deleting their cookies, since you are essentially resetting their session to the last known state. We use this all the time with mod perl. We also throw query strings in the mix so that even if they have cookies turned off they can login and have their session restored. Chris _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
On Saturday 22 October 2005 02:42, snacktime wrote:> On 10/21/05, Michael Schuerig <michael-q5aiKMLteq4b1SvskN2V4Q@public.gmane.org> wrote: > > Session management using cookies has one notable drawback: a user > > can''t have to concurrent sessions. At least not when using the same > > browser instance. This can at times result in confusing behavior > > when what the user does in one window affects how the application > > behaves in another window. > > By two concurrent sessions you mean logged in under different > usernames using the same browser? If it''s the same username it''s all > the same session so that wouldn''t cause any problems.I really mean the same user -- username, password and all. And, well, there is a problem, at least in my case. I''m keeping some context of where the user has been in the session to enable navigation. Say, the user has just run a query, then I allow them to go through the found records one by one. To do this, I keep a list of ids in the session. Now, if the user opens another window, runs another query, the context of the first window is lost. To my mind, it''s a sensible expectation from a user''s point of view, to be able to open two windows, and, say, in one of them step through all employees matching some criteria, and in the other stepping through projects matching entirely different criteria. Ideally, a user needs to log in just once, but then can open as many windows as they like, each with its own conversational state. Michael -- Michael Schuerig Not only does lightning not strike mailto:michael-q5aiKMLteq4b1SvskN2V4Q@public.gmane.org twice, it usually doesn''t strike once. http://www.schuerig.de/michael/ --Salman Rushdie, Fury
So why don''t you store the query results in the database? Say in a view (or something similar), or in a temporary table (which is the same I think), and use that to walk the user through the results? - Ivan V. Michael Schuerig wrote:> On Saturday 22 October 2005 02:42, snacktime wrote: > >> On 10/21/05, Michael Schuerig <michael-q5aiKMLteq4b1SvskN2V4Q@public.gmane.org> wrote: >> >>> Session management using cookies has one notable drawback: a user >>> can''t have to concurrent sessions. At least not when using the same >>> browser instance. This can at times result in confusing behavior >>> when what the user does in one window affects how the application >>> behaves in another window. >>> >> By two concurrent sessions you mean logged in under different >> usernames using the same browser? If it''s the same username it''s all >> the same session so that wouldn''t cause any problems. >> > > I really mean the same user -- username, password and all. And, well, > there is a problem, at least in my case. I''m keeping some context of > where the user has been in the session to enable navigation. Say, the > user has just run a query, then I allow them to go through the found > records one by one. To do this, I keep a list of ids in the session. > Now, if the user opens another window, runs another query, the context > of the first window is lost. > > To my mind, it''s a sensible expectation from a user''s point of view, to > be able to open two windows, and, say, in one of them step through all > employees matching some criteria, and in the other stepping through > projects matching entirely different criteria. > > Ideally, a user needs to log in just once, but then can open as many > windows as they like, each with its own conversational state. > > Michael > >
On Saturday 22 October 2005 04:30, Iván Vega R. wrote:> So why don''t you store the query results in the database? Say in a > view (or something similar), or in a temporary table (which is the > same I think), and use that to walk the user through the results?How does this help with keeping the conversational state of two windows by the same user apart? How do you access a temporary table/view from ActiveRecord? How and when do you clean up temporary tables/views that are no longer needed? Michael -- Michael Schuerig They tell you that the darkness mailto:michael-q5aiKMLteq4b1SvskN2V4Q@public.gmane.org Is a blessing in disguise http://www.schuerig.de/michael/ --Janis Ian, From Me To You
> Has anyone implemented session tracking without cookies, e.g. using > URL > rewriting?I worked on a game for mobile phones last year in rails and had to use url based session management. It''s certainly feasible, but at the moment In your views: Add the session_id to every link like this: link_to "somewhere", { ..., :params => { "_session_id" => @session.session_id }} and in your forms, add a hidden field to carry the session id like this: <input name="_session_id" type="hidden" value="<%= @session.session_id %>"/> that''s basically all there is to it. It would be nice, if this could be auto-generated by rails, but I haven''t gotten around to investigate this further. cu jc -- InVisible GmbH, Langgrütstrasse 172, 8047 Zürich Phone: +41 44 401 09 30 http://www.invisible.ch http://not.invisible.ch
snacktime wrote:> > > On 10/21/05, *snacktime* <snacktime-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org > <mailto:snacktime-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>> wrote: > > > > On 10/21/05, *Michael Schuerig* < michael-q5aiKMLteq4b1SvskN2V4Q@public.gmane.org > <mailto:michael-q5aiKMLteq4b1SvskN2V4Q@public.gmane.org>> wrote: > > > Session management using cookies has one notable drawback: a > user can''t > have to concurrent sessions. At least not when using the same > browser > instance. This can at times result in confusing behavior when > what the > user does in one window affects how the application behaves in > another > window. > > > By two concurrent sessions you mean logged in under different > usernames using the same browser? If it''s the same username it''s > all the same session so that wouldn''t cause any problems. If you > want to login as two separate users using the same browser, yes you > can do it, it''s not a limit of cookies it''s a limit imposed by the > implementation. And query strings are not necessary. For example, > just use the username as part of the cookie name. > > > To explain a bit more how you would do this. When someone creates an > account you store the session id in the database along with their > username, etc.. When someone logs in you get the session id from the > database and reset the current session contents to the session > associated with your stored session id. This gets you user specific > cookies, and it also works around the issue of people deleting their > cookies, since you are essentially resetting their session to the last > known state. > > We use this all the time with mod perl. We also throw query strings in > the mix so that even if they have cookies turned off they can login and > have their session restored. >Now you are describing how to implement a per-user long-running session. What Michael is after is a way for a user to have multiple concurrent sessions. This is a common requirement - e.g. when a user is in the middle of long task when the phone rings - he or she has to run some queries in order to answer the caller''s question, without losing work in progress. regards Justin
On Saturday 22 October 2005 13:15, Jens-Christian Fischer wrote:> Add the session_id to every link like this: > > link_to "somewhere", { ..., :params => { "_session_id" => > @session.session_id }} > > and in your forms, add a hidden field to carry the session id like > this: > > <input name="_session_id" type="hidden" value="<%> @session.session_id %>"/> > > that''s basically all there is to it. It would be nice, if this could > be auto-generated by rails, but I haven''t gotten around to > investigate this further.Looks good. I''ll give it a try some time. I think it''s possible to redefine link_to and start_form_tag in such a way that they insert the session parameter automatically. Michael -- Michael Schuerig Failures to use one''s frontal lobes mailto:michael-q5aiKMLteq4b1SvskN2V4Q@public.gmane.org can result in the loss of them. http://www.schuerig.de/michael/ --William H. Calvin
> Add the session_id to every link like this: > > link_to "somewhere", { ..., :params => { "_session_id" => > @session.session_id }} >> and in your forms, add a hidden field to carry the session id like > this: > > <input name="_session_id" type="hidden" value="<%= > @session.session_id %>"/>Unfortunately, this doesn''t work for forms that have an enctype="multipart/form-data" yet (i.e. file upload forms). See bug report at http://dev.rubyonrails.com/ticket/210 Rob
Easier to redefine url_for, which both link_to and start_form_tag both reply upon. -- -- Tom Mornini On Oct 22, 2005, at 9:28 AM, Michael Schuerig wrote:> On Saturday 22 October 2005 13:15, Jens-Christian Fischer wrote: > > >> Add the session_id to every link like this: >> >> link_to "somewhere", { ..., :params => { "_session_id" => >> @session.session_id }} >> >> and in your forms, add a hidden field to carry the session id like >> this: >> >> <input name="_session_id" type="hidden" value="<%>> @session.session_id %>"/> >> >> that''s basically all there is to it. It would be nice, if this could >> be auto-generated by rails, but I haven''t gotten around to >> investigate this further. >> > > Looks good. I''ll give it a try some time. I think it''s possible to > redefine link_to and start_form_tag in such a way that they insert the > session parameter automatically. > > Michael > > -- > Michael Schuerig Failures to use one''s frontal lobes > mailto:michael-q5aiKMLteq4b1SvskN2V4Q@public.gmane.org can result in the loss of them. > http://www.schuerig.de/michael/ --William H. Calvin > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
I do this:
class ActionController::Base
def default_url_options(options)
{ ''_session_id'' => session.session_id }
end
end
But here again bug #210 strikes back. Rails doesn''t seem to
"absorb"
the _session_id param when POSTing. So you can''t do:
<form action="/some_controller/some_action?_session_id=XXXXX">
Just doesn''t work (at least for me, when I tested it).
I tried finding the bug myself, but to no avail.
With Rails, I don''t know, I''m just a beginner... But I''m guessing you could use a single table for all "temp" data for example. You create a controller and model for that table and access it from your other code to build your queries. You know, I was going to write an example of how you could do it, but while writing it I realized it would be exactly the same if you just allowed the user to have simultaneous open sessions, and store the sessions in the database, and access those sessions like this: http://example.com/controller/action/<sessionid> The route would be something like ''/blah/bleh/:sessionid''. Instead of sessionid you could use whatever you want, instead of the usual long and cryptic session ids. Since each user has to be logged in to use your feature, you can use simple ids, like /search1. So, in your code, you''d do something like: Session.find(params[:sessionid]). Then you''d access the session info from that object. I don''t know if I''m making sense, because I''m new to Rails, and I don''t use sessions, but the idea I think it''s valid and applies to your issue. If you want me to extend on some point, I''ll be happy to elaborate. Regards, Ivan V. Michael Schuerig wrote:> On Saturday 22 October 2005 04:30, Iván Vega R. wrote: > >> So why don''t you store the query results in the database? Say in a >> view (or something similar), or in a temporary table (which is the >> same I think), and use that to walk the user through the results? >> > > How does this help with keeping the conversational state of two windows > by the same user apart? > > How do you access a temporary table/view from ActiveRecord? > > How and when do you clean up temporary tables/views that are no longer > needed? > > Michael > >