Camping list - Sep 2007 - Session cookies not passed on first redirect

Hello Campers!

Is it just me or does Camping  init the session twice on a redirect?  
If I have an app and when the user visits it for the first time, a  
session is generated. Afterwards I redirect the user in a service  
(that basically does auth) and he gets bounced to the login page -  
but when I arrive at the login page my SID somehow has changed :-( so  
there is a stale session dangling in the store and and empty @state.
After the second request (even if I fail auth or load a page that  
does not require it beforehand) everything is fine and dandy.

Herre is the service in question - if I do it like this the session  
is regenerated when the user lands on the signon page And the page he  
is redirected from was his first one
in the session

def service(*a)
       begin
         return super(*a)
       rescue PleaseLogin
         redirect R(Pasaporte::Controllers::Signon, @nickname)
         return self
       end
       self
end

And this version works in all cases:

def service(*a)
       begin
         return super(*a)
       rescue PleaseLogin
         @headers[''Set-Cookie''] = ''camping_sid=%s;
path=/'' %
@cookies.camping_sid
         redirect R(Pasaporte::Controllers::Signon, @nickname)
         return self
       end
       self
end

Of course the service is included before Camping::Session so the  
session service should wrap.

Has someone observed this behavior? Why is it needed to manually set  
the session cookie? Is it that the same as the workaround that  
mod_perl and mod_python use (as in "error headers" versus "normal
headers")?

-- 
Julian ''Julik'' Tarkhanov
please send all personal mail to me at julik.nl



-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/camping-list/attachments/20070925/e2999321/attachment.html

Although I''m not sure, but I guess, that the exception is the reason
for this effect.

I think, but I''m not entirely sure that, within camping/session the
code in the service method after its super is not called, when the
exeption is raised. This code is the one, that sets the cookie
information.

This is the code in camping/session.rb

    def service(*a)
        session = Camping::Models::Session.persist @cookies
        app = self.class.name.gsub(/^(\w+)::.+$/, ''\1'')
        @state = (session[app] ||= Camping::H[])
        hash_before = Marshal.dump(@state).hash
        s = super(*a)
        if session
            hash_after = Marshal.dump(@state).hash
            unless hash_before == hash_after
                session[app] = @state
                session.save
            end
        end
        s
    end

The exception is raised in the super(*a) line, this transfer the
control flow to your rescue line and it never comes back.

The only possibility would be to avoid exceptions to manipulate your
control flow.

Cheers,

Gregor	

On 9/25/07, Julian ''Julik'' Tarkhanov <julian.tarkhanov at
gmail.com> wrote:
>
> Hello Campers!
>
> Is it just me or does Camping  init the session twice on a redirect? If I
> have an app and when the user visits it for the first time, a session is
> generated. Afterwards I redirect the user in a service (that basically does
> auth) and he gets bounced to the login page - but when I arrive at the
login
> page my SID somehow has changed :-( so there is a stale session dangling in
> the store and and empty @state.
> After the second request (even if I fail auth or load a page that does not
> require it beforehand) everything is fine and dandy.
>
> Herre is the service in question - if I do it like this the session is
> regenerated when the user lands on the signon page And the page he is
> redirected from was his first one
> in the session
>
> def service(*a)
>       begin
>         return super(*a)
>       rescue PleaseLogin
>         redirect R(Pasaporte::Controllers::Signon,
> @nickname)
>         return self
>       end
>       self
> end
>
> And this version works in all cases:
>
>
> def service(*a)
>       begin
>         return super(*a)
>       rescue PleaseLogin
>         @headers[''Set-Cookie''] =
''camping_sid=%s; path=/'' %
> @cookies.camping_sid
>         redirect R(Pasaporte::Controllers::Signon,
> @nickname)
>         return self
>       end
>       self
> end
>
> Of course the service is included before Camping::Session so the session
> service should wrap.
> Has someone observed this behavior? Why is it needed to manually set the
> session cookie? Is it that the same as the workaround that mod_perl and
> mod_python use (as in "error headers" versus "normal
headers")?
>
> --
> Julian ''Julik'' Tarkhanov
> please send all personal mail to me at julik.nl
>
>
>
>
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
>

Hi Julian,

can you try the attached patch applied to camping-trunk ?

-- 
Cheers,
  zimbatm
-------------- next part --------------
A non-text attachment was scrubbed...
Name: camping-session.diff
Type: text/x-diff
Size: 646 bytes
Desc: not available
Url :
http://rubyforge.org/pipermail/camping-list/attachments/20070925/1d6177be/attachment.bin

On Sep 25, 2007, at 10:50 PM, Jonas Pfenniger wrote:
> can you try the attached patch applied to camping-trunk ?
> <camping-session.diff>
Will try. Cannot find the SVN URL on the site - only the trac is  
showing.

As of exceptions - in this case I catch the exception myself and  
return from underneath it, so it shouldn''t be a problem.
This service(*a) is the "super" to Camping::Session (because  
Camping::Session gets included after it).

I suspect there is something with the cookie setter rather than with  
the Session service itself. But you are right - let''s twist that flow  
one more bit :-)

-- 
Julian ''Julik'' Tarkhanov
please send all personal mail to me at julik.nl



-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/camping-list/attachments/20070925/63dcf22a/attachment.html

On Sep 25, 2007, at 10:31 PM, Gregor Schmidt wrote:
> The exception is raised in the super(*a) line, this transfer the
> control flow to your rescue line and it never comes back.
It does come back because

rescue PleaseLogin
         @headers[''Set-Cookie''] = ''camping_sid=%s;
path=/'' %
@cookies.camping_sid
         redirect R(Pasaporte::Controllers::Signon, @nickname)
         return self <<< this is the comeback
       end
-- 
Julian ''Julik'' Tarkhanov
please send all personal mail to me at julik.nl



-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/camping-list/attachments/20070925/2747a66a/attachment.html

2007/9/25, Julian ''Julik'' Tarkhanov <julian.tarkhanov at
gmail.com>:
> Cannot find the SVN URL on the site - only the trac is showing.
`svn co http://code.whytheluckystiff.net/svn/camping/trunk`

-- 
Cheers,
  zimbatm

On Sep 25, 2007, at 11:20 PM, Jonas Pfenniger wrote:
> 2007/9/25, Julian ''Julik'' Tarkhanov <julian.tarkhanov
at gmail.com>:
>> Cannot find the SVN URL on the site - only the trac is showing.
>
> `svn co http://code.whytheluckystiff.net/svn/camping/trunk`
Thx. Checked that. No the issue isn''t fixed. I suspect something is  
wrong with the cookie code, not with the session code (setting the  
cookie manually works after all).


-- 
Julian ''Julik'' Tarkhanov
please send all personal mail to me at julik.nl



-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/camping-list/attachments/20070925/ea54404e/attachment.html

On Sep 25, 2007, at 11:57 PM, Julian ''Julik'' Tarkhanov
wrote:
> Thx. Checked that. No the issue isn''t fixed. I suspect something
is
> wrong with the cookie code, not with the session code (setting the  
> cookie manually works after all).
Ok, with the trunk Camping it gets even more interesting! I loose the  
session on _all_ redirects now.

Camping.goes :Findme
require ''camping/session''

module Findme
   include Camping::Session
   module Controllers
     class One < R(''/stepone'')
       def get
         @state = {"one" => 2}
         puts "1:" + @state.inspect
         redirect R(Two)
       end
     end

     class Two < R(''/steptwo'')
       def get
         @state.two = "This is in two"
         puts "2:" + @state.inspect
         redirect R(Three)
       end
     end

     class Three < R(''/stepthree'')
       def get
         @state.three = "This is in three"
         puts "3:" + @state.inspect
         return "Accumulated state across redirects:
#{@state.inspect}"
         redirect R(Three)
       end
     end
   end
end

That''s a bummer.
-- 
Julian ''Julik'' Tarkhanov
please send all personal mail to me at julik.nl



-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/camping-list/attachments/20070926/b2dcf37d/attachment.html

Well'' I know this might sound very weird (it is!) - but it was  
theactiverecordeverybodyhates. I mean sometimes you shoudn''t be  
greedy and just give them that ID.

If I do the following
-                create_table :sessions, :force => true, :id => false  
do |t|
+                create_table :sessions, :force => true do |t|

everything gets rollin'', on trunk or otherwise.
Can''t post an attachment to trac so here it is

?
-- 
Julian ''Julik'' Tarkhanov
please send all personal mail to me at julik.nl



-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/camping-list/attachments/20070926/a8125024/attachment.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fix-sessions.diff
Type: application/octet-stream
Size: 1305 bytes
Desc: not available
Url :
http://rubyforge.org/pipermail/camping-list/attachments/20070926/a8125024/attachment.obj
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/camping-list/attachments/20070926/a8125024/attachment-0001.html

Thanks Julian,

the little app helped a lot. Check changeset [225].
http://code.whytheluckystiff.net/camping/changeset/225

-- 
Cheers,
  zimbatm

On Sep 26, 2007, at 10:52 AM, Jonas Pfenniger wrote:
> the little app helped a lot. Check changeset [225].
> http://code.whytheluckystiff.net/camping/changeset/225
Coolio! You can optionally try my patch for session.rb because it  
makes them neater and does not do bypasses. But the idea with the  
hideuous
injection is in our spirit yess :-)
-- 
Julian ''Julik'' Tarkhanov
please send all personal mail to me at julik.nl



-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/camping-list/attachments/20070926/03d5ab15/attachment.html

2007/9/26, Julian ''Julik'' Tarkhanov <julian.tarkhanov at
gmail.com>:
> Coolio! You can optionally try my patch for session.rb because it makes
them
> neater and does not do bypasses.
I am not really confident with the eternally growing id. I guess it
depends on the database, but a 65535 items limit can be obtained
pretty fast depending on the conditions.

-- 
Cheers,
  zimbatm

On Sep 26, 2007, at 2:42 PM, Jonas Pfenniger wrote:
> I am not really confident with the eternally growing id. I guess it
> depends on the database, but a 65535 items limit can be obtained
> pretty fast depending on the conditions.
True, didnt think about that in this sense. Well let''s carry on then
:-)
-1 for my netaness and I set out on the test corpus this weekend
this kind of stuff is something we _really_ should have known before
-- 
Julian ''Julik'' Tarkhanov
please send all personal mail to me at julik.nl



-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/camping-list/attachments/20070926/8b831ce6/attachment.html

2007/9/26, Julian ''Julik'' Tarkhanov <julian.tarkhanov at
gmail.com>:
> pretty fast depending on the conditions.
> True, didnt think about that in this sense. Well let''s carry on
then :-)-1
> for my netaness and I set out on the test corpus this weekend
> this kind of stuff is something we _really_ should have known before
Well, I don''t use sessions so I don''t care :-p

-- 
Cheers,
  zimbatm