Re: Camping sessions issue (and fix?) when mounting multiple apps
Ace - cheers!
On Mon, Nov 2, 2009 at 3:13 PM, Magnus Holm wrote:
> Okay, I think we're actually fine by setting :path => "/" by default.
> If you want anything different, you should use "use
> Rack::Session::Cookie" yourself.
>
> //Magnus Holm
>
>
>
> On Mon, Oct 19, 2009 at 19:14, Jonathan Hickford
> >
> wrote:
> > Hi,
> >
> > I'd be inclined to agree with the middleware approach too, especially
> > if it's pre 2.0 release and that change can be made along side other
> > 1.5 -> 2.0 changes
> >
> > Jon
> >
> >> On Sun, Oct 18, 2009 at 9:31 PM, Magnus Holm wrote:
> >>> Wow, great catch! This is definitely a bug. I guess this should go to
> >>> GitHub issues, yes.
> >>>
> >>> This is actually an issue where Camping and Rack::Session::Cookie
> fight:
> >>>
> >>> At the first request, sessions.state is set in ::Cookie after Camping
> >>> has done its magic.
> >>>
> >>> At the second request, Camping loads @state from @env['rack.state'],
> >>> the app changes the session, but @cookie['sessions.state'] stays
> >>> intact. Camping's #to_a then sets the cookies again in the response:
> >>>
> >>> @cookies.each do |k, v|
> >>>v = {:value => v, :path => self / "/"} if String === v
> >>>r.set_cookie(k, v)
> >>> end
> >>>
> >>> Which means that it sets a sessions.state-cookie at /sessions/. Then
> >>> ::Cookies kicks in and figures out that the sessions have changed and
> >>> sets a new cookie, but this time at /. (This also has the effect that
> >>> Camping copies all the cookies at / into /sessions/)
> >>>
> >>> At the third request, Rack chooses cookies "such that those with more
> >>> specific Path attributes precede those with less specific", and the
> >>> cookie at /sessions/ wins.
> >>>
> >>> Your fix won't unfornately work because @root is only available inside
> >>> a request/controller.
> >>>
> >>> I think we need to do two things:
> >>> * Make sure Camping only sets cookies when they've changed.
> >>> * Figure out a way to set :path to SCRIPT_NAME. If so, this should
> >>> only be an option, as you might also want to mount two apps and have
> >>> them share the sessions (aka :path => '/').
> >>>
> >>> I'm not quite sure how we should add that option, though. We could
> >>> switch Camping::Session to be a middleware, but this means all apps
> >>> will have to change "include Camping::Session" to "use
> >>> Camping::Session". It's maybe not such a big deal? We should at least
> >>> do these kind of changes *before* the release of 2.0.
> >>>
> >>> Some examples:
> >>>
> >>> # Middleware
> >>> use Camping::Session, :secret => "foo", :shared => true
> >>>
> >>> # Subclass
> >>> include Camping::Session::Shared
> >>> secret "foo"
> >>>
> >>> # New method
> >>> include Camping::Session
> >>> secret "foo"
> >>> shared_cookie!
> >>>
> >>> # Merge #secret and #shared_cookie! together
> >>> include Camping::Session
> >>> session_options :secret => "foo", :shared => true
> >>>
> >>>
> >>> I think I actually prefer the middleware-version. It's short and
> >>> concise and can be extended with more options if needed.
> >>>
> >>> What do you think?
> >>>
> >>>
> >>> //Magnus Holm
> >>>
> >>>
> >>>
> >>> On Sun, Oct 18, 2009 at 19:59, Jonathan Hickford
> >>> >
> wrote:
> Hi all,
>
> Not sure where best to raise this (github issues?) but I'm seeing an
> issue with the cookie sessions in camping 2.0 using rack. If I mount
> an app such as the example blog or the sessions test app at any url
> that is not the root session information is lost in some cases. Same
> thing happens if I use the built in Camping server.
>
> For example if I mount the blog app using rackup at '/blog' I'm unable
> to log in. If I mount the sessions test app the information added on
> the second page is lost when it reaches page three. Looking at the
> cookies in the browser I can see two state cookies set with the paths
> '/' and '/blog/'.
>
> I'm guessing this is to do with Rack::Session::Cookie in session.rb,
> which will default to use :path => '/' in all cases. If I explicitly
> add :path => '/blog/' there it starts working as expected. Some more
> detailed outputs here (this will run from /test)
> http://pastebin.com/m6c13a4aa
>
> Is that me doing something crazy there (I'm not expert!) or is that a
> bug? If that's an issue I think the below change to session.rb fixes
> it, passing in the apps @root into the path Rack's session cookie
> middleware. I can push that somewhere if we reckon that's a fix?
>
> - app.use Rack::Session::Cookie, :key => key, :secret => secret
> + app.use Rack::Session::Cookie, :key => key, :secret => secret, :path
> => @root
>
> Regards,
>
> Jon
> ___
> Camping-list mailing list
> Camping-list@rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
>
> >
Re: is there a way to configure line breaks in markaby output?
Yes, it can be a bugbear.
It's a bit 'non-lazy' but I just tend to add newlines with Markaby's
'text':
def index
h1 'My Site'
text("\n\n")
p 'Welcome to my site!'
end
- DaveE
Is there anyway that I can configure Markaby to add line breaks
between block elements so I'd get something like this:
My Site
Welcome to my site!
___
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list
Re: is there a way to configure line breaks in markaby output?
I think this should do it: Camping.goes :Nuts Nuts::Mab.set(:indent, 2) You should probably only use it in development, because I think it's pretty slow. //Magnus Holm On Mon, Nov 2, 2009 at 18:57, David Susco wrote: > Hi all, > > Instead of having the following: > > def index > h1 'My Site' > p 'Welcome to my site!' > end > > output this: > > My SiteWelcome to my site! > > Is there anyway that I can configure Markaby to add line breaks > between block elements so I'd get something like this: > > My Site > > Welcome to my site! > > Obviously it makes no difference to the browser, it would just make it > easier on me when debugging and testing. > > -- > Dave > ___ > Camping-list mailing list > Camping-list@rubyforge.org > http://rubyforge.org/mailman/listinfo/camping-list > ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
is there a way to configure line breaks in markaby output?
Hi all, Instead of having the following: def index h1 'My Site' p 'Welcome to my site!' end output this: My SiteWelcome to my site! Is there anyway that I can configure Markaby to add line breaks between block elements so I'd get something like this: My Site Welcome to my site! Obviously it makes no difference to the browser, it would just make it easier on me when debugging and testing. -- Dave ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
Re: Camping book
Magnus - I did make some earlier suggestions/edits and would be happy to implement them. I'm a sad and rather newbie (still working through the O'Reilly Git book) GitHub lurker (with no repos yet: http:// github.com/DaveEveritt) so let me know when you're ready and I'll start work - Dave E. Thanks for bringing this up again! I've pushed out what I have so far, but not your latest suggestions (you had some more in an earlier mail, right?) If you have a Github account I can give you (and anyone else who wants to contribute) push-access. I'm a little busy at the moment, but I'll try to fix it as soon as possible. //Magnus Holm On Mon, Nov 2, 2009 at 01:22, Dave Everitt wrote: I added some basic material to the GitHub Camping Wiki (new pages): http://wiki.github.com/camping/camping [SNIP] Thinking about existing stuff, some time ago Magnus wrote: As for thedocumentation ideas, I've already implemented the templates in RDoc, so "rake docs" builds all the three parts (the book is simply files in the book directory). I still need to make a way to link book chapters from the reference, but at least it's working. A Camping app can be useful when you want to edit it, so you don't need to run the rake task all the time. The book dir on GitHub doesn't have all the current content found at: http://stuff.judofyr.net/camping-docs/book/ or in the Camping install (unless I'm daft, which is possible) so where can the current book files be obtained? I guesswe could also implement it as a wiki, which might be better. Then we can't have it on camping.rubyforge.org (unless we can change the DNS-settings) though since it only allows static files. What do you think? I prefer having everything in files, and I think those who really want to contribute to the book wouldn't mind a "git clone"... I don't think there was a response at the time Magnus wrote this, so (given whywentcamping.com, which would be a separate exercise): ideas, opinions, anyone? Be really good to have camping.rubyforge.org updated, and I'm ready to pitch in, but how to start? Dave Everitt ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
Re: Camping book
Thanks for bringing this up again! I've pushed out what I have so far, but not your latest suggestions (you had some more in an earlier mail, right?) If you have a Github account I can give you (and anyone else who wants to contribute) push-access. I'm a little busy at the moment, but I'll try to fix it as soon as possible. //Magnus Holm On Mon, Nov 2, 2009 at 01:22, Dave Everitt wrote: > I added some basic material to the GitHub Camping Wiki (new pages): > http://wiki.github.com/camping/camping > > ...because I'm starting with a vanilla OS X Leopard install (new MacBook) > and - finally - Camping 1.9, and I thought it would be a good test run to go > through the setup and tutorial process in the 'Camping book': > http://stuff.judofyr.net/camping-docs/book/02_getting_started.html > to find any gotchas. > > Only one (in my setup) - on 'Wrapping it up', in the Controllers: > class Pages > needs the explicit > class Pages < R '/' > to show the pages... anyone not have the same issue? > > Thinking about existing stuff, some time ago Magnus wrote: > >> As for the documentation ideas, I've already implemented the templates in >> RDoc, so "rake docs" builds all the three parts (the book is simply files in >> the book directory). I still need to make a way to link book chapters from >> the reference, but at least it's working. A Camping app can be useful when >> you want to edit it, so you don't need to run the rake task all the time. > > The book dir on GitHub doesn't have all the current content found at: > http://stuff.judofyr.net/camping-docs/book/ > or in the Camping install (unless I'm daft, which is possible) so where can > the current book files be obtained? > >> I guess we could also implement it as a wiki, which might be better. Then >> we can't have it on camping.rubyforge.org (unless we can change the >> DNS-settings) though since it only allows static files. What do you think? I >> prefer having everything in files, and I think those who really want to >> contribute to the book wouldn't mind a "git clone"... > > > I don't think there was a response at the time Magnus wrote this, so (given > whywentcamping.com, which would be a separate exercise): ideas, opinions, > anyone? Be really good to have camping.rubyforge.org updated, and I'm ready > to pitch in, but how to start? > > Dave Everitt > > ___ > Camping-list mailing list > Camping-list@rubyforge.org > http://rubyforge.org/mailman/listinfo/camping-list > ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
Re: Camping sessions issue (and fix?) when mounting multiple apps
Okay, I think we're actually fine by setting :path => "/" by default.
If you want anything different, you should use "use
Rack::Session::Cookie" yourself.
//Magnus Holm
On Mon, Oct 19, 2009 at 19:14, Jonathan Hickford
wrote:
> Hi,
>
> I'd be inclined to agree with the middleware approach too, especially
> if it's pre 2.0 release and that change can be made along side other
> 1.5 -> 2.0 changes
>
> Jon
>
>> On Sun, Oct 18, 2009 at 9:31 PM, Magnus Holm wrote:
>>> Wow, great catch! This is definitely a bug. I guess this should go to
>>> GitHub issues, yes.
>>>
>>> This is actually an issue where Camping and Rack::Session::Cookie fight:
>>>
>>> At the first request, sessions.state is set in ::Cookie after Camping
>>> has done its magic.
>>>
>>> At the second request, Camping loads @state from @env['rack.state'],
>>> the app changes the session, but @cookie['sessions.state'] stays
>>> intact. Camping's #to_a then sets the cookies again in the response:
>>>
>>> �...@cookies.each do |k, v|
>>> v = {:value => v, :path => self / "/"} if String === v
>>> r.set_cookie(k, v)
>>> end
>>>
>>> Which means that it sets a sessions.state-cookie at /sessions/. Then
>>> ::Cookies kicks in and figures out that the sessions have changed and
>>> sets a new cookie, but this time at /. (This also has the effect that
>>> Camping copies all the cookies at / into /sessions/)
>>>
>>> At the third request, Rack chooses cookies "such that those with more
>>> specific Path attributes precede those with less specific", and the
>>> cookie at /sessions/ wins.
>>>
>>> Your fix won't unfornately work because @root is only available inside
>>> a request/controller.
>>>
>>> I think we need to do two things:
>>> * Make sure Camping only sets cookies when they've changed.
>>> * Figure out a way to set :path to SCRIPT_NAME. If so, this should
>>> only be an option, as you might also want to mount two apps and have
>>> them share the sessions (aka :path => '/').
>>>
>>> I'm not quite sure how we should add that option, though. We could
>>> switch Camping::Session to be a middleware, but this means all apps
>>> will have to change "include Camping::Session" to "use
>>> Camping::Session". It's maybe not such a big deal? We should at least
>>> do these kind of changes *before* the release of 2.0.
>>>
>>> Some examples:
>>>
>>> # Middleware
>>> use Camping::Session, :secret => "foo", :shared => true
>>>
>>> # Subclass
>>> include Camping::Session::Shared
>>> secret "foo"
>>>
>>> # New method
>>> include Camping::Session
>>> secret "foo"
>>> shared_cookie!
>>>
>>> # Merge #secret and #shared_cookie! together
>>> include Camping::Session
>>> session_options :secret => "foo", :shared => true
>>>
>>>
>>> I think I actually prefer the middleware-version. It's short and
>>> concise and can be extended with more options if needed.
>>>
>>> What do you think?
>>>
>>>
>>> //Magnus Holm
>>>
>>>
>>>
>>> On Sun, Oct 18, 2009 at 19:59, Jonathan Hickford
>>> wrote:
Hi all,
Not sure where best to raise this (github issues?) but I'm seeing an
issue with the cookie sessions in camping 2.0 using rack. If I mount
an app such as the example blog or the sessions test app at any url
that is not the root session information is lost in some cases. Same
thing happens if I use the built in Camping server.
For example if I mount the blog app using rackup at '/blog' I'm unable
to log in. If I mount the sessions test app the information added on
the second page is lost when it reaches page three. Looking at the
cookies in the browser I can see two state cookies set with the paths
'/' and '/blog/'.
I'm guessing this is to do with Rack::Session::Cookie in session.rb,
which will default to use :path => '/' in all cases. If I explicitly
add :path => '/blog/' there it starts working as expected. Some more
detailed outputs here (this will run from /test)
http://pastebin.com/m6c13a4aa
Is that me doing something crazy there (I'm not expert!) or is that a
bug? If that's an issue I think the below change to session.rb fixes
it, passing in the apps @root into the path Rack's session cookie
middleware. I can push that somewhere if we reckon that's a fix?
- app.use Rack::Session::Cookie, :key => key, :secret => secret
+ app.use Rack::Session::Cookie, :key => key, :secret => secret, :path =>
@root
Regards,
Jon
___
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list
>>> ___
>>> Camping-list mailing list
>>> Camping-list@rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/camping-list
>>
> ___
> Camping-list mailing list
> Camping-list@rubyforge.org
> http://rubyforge.org/mailman/listinfo/camp
Re: Camping book
Very silly me. Forgot about 'Index': - class Pages < R '/' + class Index have corrected the Pastie: http://pastie.org/679826 Dave Everitt Only one (in my setup) - on 'Wrapping it up', in the Controllers: class Pages needs the explicit class Pages < R '/' ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
Re: Using #rubycamping in Twitter posts
true, but I think Philippe is using 'rubycamping.com' as a generic term for 'the Camping website' - DaveE I thought we settled on whywentcamping? ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
