Ok then. Have a good time!
On Jun 16, 9:39 am, Frederick Cheung <[email protected]> wrote: > On Jun 16, 7:39 am, Mario <[email protected]> wrote:> Turning off the > session for one action was the solution for me > > finally. I'm very happy! > > > In the future, would your smart_session_store plugin also be an option > > here? > > That's what it's designed to do. It's easier to just not use a session > if you don't need it though (and the cookie store is inherently pretty > speedy too) > > Fred > > > Thanks again Fred, > > Mario > > > On Jun 15, 12:31 pm, Frederick Cheung <[email protected]> > > wrote: > > > > On Jun 15, 10:44 am, Mario <[email protected]> wrote:> Oh my... a > > > signature! Didn't know this one. Thanks very much! > > > > > So basically the situation is that send_file is sending the same > > > > cookie with different signatures over and over again, but does no harm > > > > to the rest of the application, right? > > > > In the traces that you have captured, yes. > > > > > My question then is, why do I receive Error 401 when the flash file is > > > > timely loaded in between (I'm using firebug to verify that) other > > > > send_file responses. > > > > > This is a debug sample page where such a flash file is > > > > included:http://www.vidmap.de/?dev_route=true > > > > > "Unfortunately" it's working 100% from were I'm at the moment (fast > > > > internet connection) because all Images (send_file) are already > > > > delivered before the flash starts loading itself. > > > > This really does make it sound like a race condition to me - the > > > cookies loaded by some requests are overwriting the cookie set by the > > > page generating the authenticity token (there is a random identifier > > > stored in the session that is used to create the authenticity token). > > > You may be able to work around this by forcing this bit of the session > > > to get earlier, by making the requests that are currently getting 401 > > > use gets (if csrf is not a problem) or by turning off the session for > > > some requests > > > > Fred > > > > > On Jun 15, 11:04 am, Frederick Cheung <[email protected]> > > > > wrote: > > > > > > On Jun 15, 9:40 am, Mario <[email protected]> wrote: > > > > > > > You mean this > > > > > > > BAh7CDoOcmV0dXJuX3RvIgYvOhB2bV9sYW5ndWFnZSIHZGUiCmZsYXNoSUM6%0AJ0FjdGlvbkNv > > > > > > bnRyb2xsZXI6OkZsYXNoOjpGbGFzaEhhc2h7AAY6CkB1c2Vk > > > > > > %0AewA%3D--8afcd7d5a8f2f64804ca01de1d32b2129152ece8 > > > > > > > is de-based the same as this > > > > > > > BAh7CDoOcmV0dXJuX3RvIgYvIgpmbGFzaElDOidBY3Rpb25Db250cm9sbGVy > > > > > > %0AOjpGbGFzaDo6Rmxhc2hIYXNoewAGOgpAdXNlZHsAOhB2bV9sYW5ndWFnZSIH%0AZGU > > > > > > %3D--c173d4fdc20a0a81eefa9969a83b335f436098a9 > > > > > > Yes, but you need to not include the -- and what follows (that's a > > > > > signature) and turn the %0A into carriage returns, strip the spaces > > > > > and turn the %3D into = signs. with that I get > > > > > > BAh7CDoOcmV0dXJuX3RvIgYvOhB2bV9sYW5ndWFnZSIHZGUiCmZsYXNoSUM6J0FjdGlvbkNvbnR > > > > > yb2xsZXI6OkZsYXNoOjpGbGFzaEhhc2h7AAY6CkB1c2VkewA= > > > > > > => ["\004\b{\b:\016return_to\"\006/:\020vm_language\"\ade > > > > > \"\nflashIC:'ActionController::Flash::FlashHash{\000\006:\...@used > > > > > {\000"] > > > > > > BAh7CDoOcmV0dXJuX3RvIgYvIgpmbGFzaElDOidBY3Rpb25Db250cm9sbGVyOjpGbGFzaDo6Rmx > > > > > hc2hIYXNoewAGOgpAdXNlZHsAOhB2bV9sYW5ndWFnZSIHZGU= > > > > > > => ["\004\b{\b:\016return_to > > > > > \"\006/\"\nflashIC:'ActionController::Flash::FlashHash{\000\006:\...@used > > > > > {\000:\020vm_language\"\ade"] > > > > > > This is a marshaled ruby object , and they look the same to me: it's a > > > > > hash so ordering of key-value pairs does not matter > > > > > > Fred > > > > > > > ?? > > > > > > > This decoder tells me otherwise!? > > > > > > >http://www.motobit.com/util/base64-decoder-encoder.asp > > > > > > > On Jun 15, 10:20 am, Frederick Cheung <[email protected]> > > > > > > wrote: > > > > > > > > On Jun 15, 9:15 am, Mario <[email protected]> wrote:> > > > > > > > Thanks for your quick response! > > > > > > > > > Unfortunately the cookies set are not identical. Please look at > > > > > > > > the > > > > > > > > last bit of the two strings: > > > > > > > > First response: _vm_session_prod=BAh7xxxx--8afcxxx > > > > > > > > Second response: _vm_session_prod=BAh7xxxx--c173xxx (!!!) > > > > > > > > I know they are not bit for bit equal. But if you debase64 them > > > > > > > you > > > > > > > can see they represent the same hash. > > > > > > > > > The problem later on is that one of my flash files tries to > > > > > > > > authorize > > > > > > > > itself (it sends the session cookie to the server) using the > > > > > > > > cookie > > > > > > > > which was current when the flash file was loaded. BUT meanwhile > > > > > > > > (in > > > > > > > > between flash file was loaded and first flash file request to > > > > > > > > server) > > > > > > > > those images sent by send_file are changing the session cookie. > > > > > > > > As a > > > > > > > > result of this, the requests out of the flash file are refused > > > > > > > > by the > > > > > > > > server (Error 401). > > > > > > > > does this only happen in production ? > > > > > > > > Fred > > > > > > > > > Mario > > > > > > > > > On Jun 15, 3:18 am, Frederick Cheung > > > > > > > > <[email protected]> > > > > > > > > wrote: > > > > > > > > > > On Jun 14, 9:57 pm, Mario <[email protected]> wrote: > > > > > > > > > > > I'm experiencing a serious problem where the responses of > > > > > > > > > > my GET > > > > > > > > > > requests keep reseting my session cookie. > > > > > > > > > > > Basically my initial request > > > > > > > > > > towww.vidmap.desetsasessioncookieon > > > > > > > > > > variable _vm_session_prod which is undesirably overwritten > > > > > > > > > > with > > > > > > > > > > different value by a second request. > > > > > > > > > > > The second request inside the delivered html document is > > > > > > > > > > loading a > > > > > > > > > > jpeg image > > > > > > > > > > throughhttp://www.vidmap.de/web/image?image=bikecam_julierpass.jpg. > > > > > > > > > > The image is delivered through send_file(PATH_XYZ, :type => > > > > > > > > > > 'image/ > > > > > > > > > > jpeg', :disposition => 'inline', :filename => 'video.jpeg', > > > > > > > > > > :stream => > > > > > > > > > > false) on server side. > > > > > > > > > > > My problem is that, for what reason ever, the second > > > > > > > > > > response sets a > > > > > > > > > > new session cookie (which causes heavy trouble at an other > > > > > > > > > > stage). No > > > > > > > > > > other server side responses (render :json / :text) are > > > > > > > > > > causing this > > > > > > > > > > strange effect. > > > > > > > > > > The data in the session cookie actually looks identical > > > > > > > > > (since hashes > > > > > > > > > aren't guaranteed to have the same order, the second time > > > > > > > > > around some > > > > > > > > > of the keys are in a different order when the session hash is > > > > > > > > > serialized) > > > > > > > > > What is the problem happening later on ? > > > > > > > > > > Fred > > > > > > > > > > > Help anyone? > > > > > > > > > > > ################################# > > > > > > > > > > Initial Request onhttp://www.vidmap.de/ > > > > > > > > > > ################################# > > > > > > > > > > Host:www.vidmap.de > > > > > > > > > > > Accept: > > > > > > > > > > text/html,application/xhtml+xml,application/xml;q=0.9,*/ > > > > > > > > > > *;q=0.8 > > > > > > > > > > > Accept-Language: de-de,de;q=0.8,en-us;q=0.5,en;q=0.3 > > > > > > > > > > > Accept-Encoding: gzip,deflate > > > > > > > > > > > Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 > > > > > > > > > > > Keep-Alive: 300 > > > > > > > > > > > Connection: keep-alive > > > > > > > > > > > Referer:http://www.vidmap.de/ > > > > > > > > > > > ########### > > > > > > > > > > Response: > > > > > > > > > > ########### > > > > > > > > > > Set-Cookie: vm_language=de; domain=.vidmap.de; path=/; > > > > > > > > > > expires=Mon, 14 > > > > > > > > > > Jun 2010 19:52:00 GMT > > > > > > > > > > _vm_session_prod=BAh7CDoOcmV0dXJuX3RvIgYvOhB2bV9sYW5ndWFnZSIHZGUiCmZsYXNoSU > > > > > > > > > > > > > > > > > > > > M6%0AJ0FjdGlvbkNvbnRyb2xsZXI6OkZsYXNoOjpGbGFzaEhhc2h7AAY6CkB1c2Vk > > > > > > > > > > %0AewA%3D--8afcd7d5a8f2f64804ca01de1d32b2129152ece8; > > > > > > > > > > domain=vidmap.de; > > > > > > > > > > path=/ > > > > > > > > > > > Status: 200 OK > > > > > > > > > > > ################################################################## > > > > > > > > > > Preceding Request > > > > > > > > > > onhttp://www.vidmap.de/web/image?image=bikecam_julierpass.jpg > > > > > > > > > > ################################################################## > > > > > > > > > > Host:www.vidmap.de > > > > > > > > > > > Accept: image/png,image/*;q=0.8,*/*;q=0.5 > > > > > > > > > > > Accept-Language: de-de,de;q=0.8,en-us;q=0.5,en;q=0.3 > > > > > > > > > > > Accept-Encoding: gzip,deflate > > > > > > > > > > > Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 > > > > > > > > > > > Keep-Alive: 300 > > > > > > > > > > > Connection: keep-alive > > > > > > > > > > > Referer:http://www.vidmap.de/ > > > > > > > > > > > Cookie: vm_language=de; > > > > > > > > > > _vm_session_prod=BAh7CDoOcmV0dXJuX3RvIgYvOhB2bV9sYW5ndWFnZSIHZGUiCmZsYXNoSU > > > > > > > > > > > > > > > > > > > > M6%0AJ0FjdGlvbkNvbnRyb2xsZXI6OkZsYXNoOjpGbGFzaEhhc2h7AAY6CkB1c2Vk > > > > > > > > > > %0AewA%3D--8afcd7d5a8f2f64804ca01de1d32b2129152ece8 > > > > > > > > > > > ########### > > > > > > > > > > Response: > > > > > > > > > > ########### > > > > > > > > > > Set-Cookie: > > > > > > > > > > _vm_session_prod=BAh7CDoOcmV0dXJuX3RvIgYvIgpmbGFzaElDOidBY3Rpb25Db250cm9sbG > > > > > > > > > > Vy > > > > > > > > > > %0AOjpGbGFzaDo6Rmxhc2hIYXNoewAGOgpAdXNlZHsAOhB2bV9sYW5ndWFnZSIH%0AZGU > > > > > > > > > > %3D--c173d4fdc20a0a81eefa9969a83b335f436098a9; > > > > > > > > > > domain=vidmap.de; > > > > > > > > > > path=/ > > > > > > > > > > > Status: 200 OK > > > > > > > > > > > Etag: "2a608345f7bd45f06e60db0317f5cf38" > > > > > > > > > > > Content-Transfer-Encoding: binary > > > > > > > > > > > Pragma: public > > > > > > > > > > > Cache-Control: cache, must-revalidate; > > > > > > > > > > > Content-Disposition: inline; filename="video.jpeg" > > > > > > > > > > > Content-Type: image/jpeg > > > > > > > > > > > Content-Length: 20094 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
