Attention Judofyr: Broken cookies in 2.0

[Bluebie, Jenna]

Hey Judofyr! Fix this! When someone sets a cookie using  
@cookies.something = 'data' it should be set with the path going to  
the camping app's root, not with no path, otherwise only that  
controller with the same parameters will ever see the cookie again!  
Please change this code:

> @cookies.each do |k, v|
>   @response.set_cookie(k, v) if o[k] != v
> end


to:

> @cookies.each do |k, v|
>   @response.set_cookie(k, :value => v, :path => self/"/") if o[k] != v
> end

Which should unbreak it, but cookie sessions will still remain broken  
so long as you keep using the longer weird set_cookie syntax in there  
without a path set. Please change it back to @cookie.stuff = "things".

Againy, judofyr, now I find out in the trunk, still, you have a 15  
minute timeout. When I said 10 minutes wasn't enough I didn't mean 'so  
bump it up to 15'. Please get rid of this and just use plain old  
untimed 'session cookies'. If you insist on having state_timeout  
functionality — which I strongly feel is something a user could easily  
implement if they wanted it and beyond the scope of what should come  
with camping — please default it to 'nil' and change the logic to not  
be setting those timeout cookies when it is nil. We're not Rails, we  
don't need to build in every bit of functionality any user could ever  
want.

We can provide timed sessions on the wiki. Well, at least we could if  
there was any way to make a new page on the wiki, which seems to be  
currently disabled. it looks like this:

> def service(*a)
>   @state = Camping::H[] if @cookies.timeout < (Time.now - 1.hour);  
> @cookies.timeout = Time.now.to_i; super(*a)
> end


And, one more thing: I thought the cookie thing had been fixed now,  
but apparently the cookie setting logic is still happening in  
service(*a), making the cookies hash useless inside of service  
wrappers. The stuff in service(*a) should be moved out to call(...),  
outside of the services chain. It's too weird to have to use weird  
rack api's to do things in a service but have to use familiar simple  
camping inside of the camping app and before you call 'super()'. the  
inner most service should just do:

> @body = (catch(:halt){send(@request.request_method.downcase, *a)} ||  
> @body).to_s


Then @body should be used and @headers and @status and @cookies should  
be all done in call() to do all the stuff currently being done in the  
service. Then we can live in a happy world where services really do  
work as 'before' and 'after' style methods and we don't have to code  
to rack api's half the time to make it work in ways which really  
cannot be understood without reading the camping source code. As is  
happening now, these api's might be replaced entirely with some other  
thingo in the future if rack is superseded and break it all, not to  
mention that rack's api's are a lot less fun to code to than camping's.

If someone wants to tell me how git works, I'll be happy to patch  
these problems myself, provided it isn't a stressful or excessively  
difficult thing to do... My username on there is Bluebie. I have no  
idea how to use it.

—
Blueberry the fictional pony
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/camping-list/attachments/20080606/ea54149a/attachment-0001.html>