From: Jamis Buck Date: 2004-05-08T12:21:13+09:00 Subject: Re: What is Borges? Carl Youngblood wrote: > Julian Fitzell wrote: > >>> - Can it work with mod_fastcgi/ruby? >>> - Does the sessioning stuff support automatic fallback to GET-based >>> session ID propagation if the user has disabled cookies? >> >> >> Seaside/Borges use GET parameters for session. Avi and I do not like >> using cookies for session keys, not just because of the obvious >> problem that some people disable cookies but also because it prevents >> the user from having two windows open in two different sessions at the >> same time. > > > I personally don't see a big need for running > multiple sessions simultaneously, but I can see why someone might want > to do it. I prefer to use cookies for sessioning and have the web app > automatically fall back to GET propagation if the user has cookies > disabled. It's not even the need to support multiple sessions that make using cookies for session management evil. I work as a programmer at BYU, and we have been putting all of our applications (student registration, grade submission, class scheduling, etc, etc) all online for several years. (Not using Ruby, alas, but I'm making some inroads to increasing Ruby's acceptance here... that's another story, though...) Two big problems we had when using cookies for session management: One. Picture two students, roommates, with one computer between them. Student "A" logs into the online registration app and registers for a few classes, and then minimizes the browser window without logging out. Shortly thereafter, Student "B" comes along, opens a new browser window (not realizing that there is already a window open, but minimized) and logs into the online registration app. He then registers for a few classes, and closes his window (without logging out). Student "A" returns, and restores his browser window, intending to add a few more classes. AT THIS POINT, THE SESSION REFLECTS THE ACTIVITY OF STUDENT B, NOT STUDENT A. When Student A adds a class, he inadvertantly adds it to Student B's schedule, which may not actually be realized until the semester starts. This problem actually bit us hard a few years ago. Two. Picture an administrative employee. They are editing a student's grade history when they get a phone call. It is another student with a question about their grades, so the employee (not wishing to lose their place) opens a new window and uses it to answer the student's question. Then, they close that new window to return to their place. THE SESSION NOW REFLECTS THE CALLER'S IDENTITY, NOT THE ORIGINAL STUDENT'S IDENTITY. Thus, when the employee changes a grade, it goes to the caller's record, not the original student's! This also bit us hard a few years ago. We got around this by using what we have called a "brownie." It is the encoded and encrypted session information, stored in a hidden field on the page itself and propogated via POSTs. (Another problem with using GET, in addition to what I've read in this thread, is that GETs are technically limited to 1k of data, which--in our case--is often insufficient to transmit the brownie.) This solution has served us well, though imperfectly. It required quite a bit of infrastructure code to be written to support, which has resulted in some maintenance and training headaches, but such is the nature of web development, I guess. -- Jamis Buck jgb3@email.byu.edu http://www.jamisbuck.org/jamis ruby -h | ruby -e 'a=[];readlines.join.scan(/-(.)\[e|Kk(\S*)|le.l(..)e|#!(\S*)/) {|r| a << r.compact.first };puts "\n>#{a.join(%q/ /)}<\n\n"'