Hey, Raul. I realized later that the "iexplorer.exe" process was kept even when I closed the Internet Explorer window and opened it again several times... it used the same instance with the same thread (or program) id. That bug did not allowed the "helloname" window (or tab) to create another cookie, since it was tecnicaly the same instance. After I killed the process, the problem had gone for good.
I wander what are the implications of this bug in a production environment... Eeeeewww. Thanks. Gabriel 2008/10/27 raul parolari <[EMAIL PROTECTED]> > > Hi, Gabriel > > you raise an interesting question; although I did not understand > everything in your post, let's see if this helps. > > First, a bit of background information: > > a) the 'session' is implemented by a cookie sent to the browser; eg the > cookie name is (in our case) *'_helloname_session*'. When the session is > implemented via the database, the cookie contains the session_id, so that > Rails can access the db and then populate our friend *session[ ]*. > b) When should the browser delete the cookie? Well, the cookie is expected > "*to expire at end of session*".. we will soon see what it means. Notice > that all this is a bit vague, as there is no real session between browser > and server, but just sad tricks to give us that illusion (with all the > downsides that those tricks come with). > > All right, we can now experiment. > > 1) if we direct Safari to our rails 'helloname', and then we quit Safari > (and I really mean quit, ie there is no unix process with Safari in its > name), when we restart Safari and we direct it again to 'helloname', the > cookie is gone in the browser. > Notice: what may be a bit confusing is that in Rails instead, if we are > using the database to store the session, the record remains, although it > will not be used (but Rails of course has no idea if it will be used or not, > so it will remain in the db). This problem does not happen if we use the > cookie store. > > 2) If we do the same in Firefox, we may (I use 'may' because it depends, > see below) see that Firefox still remembers the session, even after restart. > In this case, Rails does NOT generate a new session, as it receives the > session cookie from the browser. > > This should explain what you saw. Now, if you don't like this behaviour in > Firefox, there is a privacy setting that you can change, by selecting: > > "Accept cookies from sites" -> "Keep until" -> "I close Firefox" > > This should perhaps get the behaviour that you expected.. > > Raul > > > > On Mon, Oct 27, 2008 at 7:31 AM, Gabriel <[EMAIL PROTECTED]> wrote: > >> >> Hi there. >> >> I'm going through exercise 3, when I follow the step 3.2 (Use >> ActiveRecordStore to mantain session data) everything works as >> expected, but when I go to step 3.3 (Use Flash), the session data is >> maintained and used when I run the application. >> >> This occurs even if I restart the server, close and open the browser, >> delete the browser's temp files and so on... >> I can delete the record directly from the database, but WHAT'S THE >> POINT? I mean, how could the browser get the "old" session, specially >> when it contains "secret-crypted-hashed-protected-from-forgery" >> information? Doesn't it creates a new "session_id"? >> >> I'm using Windows XP SP3, IE7, NetBeans 6.1 with Rails 2.0.2. >> >> Why does it happens? How to avoid it? >> >> Thanks in advance, >> Gabriel. >> >> >> > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "ruby-on-rails-programming-with-passion" group. To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/ruby-on-rails-programming-with-passion?hl=en?hl=en -~----------~----~----~----~------~----~------~--~---
