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
-~----------~----~----~----~------~----~------~--~---
