From Daniel.Berger at qwest.com  Mon Jun  2 17:12:15 2008
From: Daniel.Berger at qwest.com (Berger, Daniel)
Date: Mon, 2 Jun 2008 16:12:15 -0500
Subject: Web development at the speed of light (A Camping Success Story)
Message-ID: <7524A45A1A5B264FA4809E2156496CFB023D32DE@ITOMAE2KM01.AD.QINTRA.COM>

Hi all,

Friday. Noon. I'm tasked with writing a small web front end. LDAP
validation required. Form data validation required.

I have to post form data to an external URL because of retarded
licensing issues. And validate the result using screen scraping.

I had the initial version done and online that night. Some finishing
touches were added this afternoon.

THANK YOU CAMPING!!!

Dan


This communication is the property of Qwest and may contain confidential or
privileged information. Unauthorized use of this communication is strictly 
prohibited and may be unlawful.  If you have received this communication 
in error, please immediately notify the sender by reply e-mail and destroy 
all copies of the communication and any attachments.

From kprojection at gmail.com  Tue Jun  3 01:01:54 2008
From: kprojection at gmail.com (Eric Mill)
Date: Tue, 3 Jun 2008 01:01:54 -0400
Subject: Web development at the speed of light (A Camping Success Story)
In-Reply-To: <7524A45A1A5B264FA4809E2156496CFB023D32DE@ITOMAE2KM01.AD.QINTRA.COM>
References: <7524A45A1A5B264FA4809E2156496CFB023D32DE@ITOMAE2KM01.AD.QINTRA.COM>
Message-ID: <c658be6b0806022201q7db92974jf29760ed1c638e9b@mail.gmail.com>

Hooray!

On Mon, Jun 2, 2008 at 5:12 PM, Berger, Daniel <Daniel.Berger at qwest.com> wrote:
> Hi all,
>
> Friday. Noon. I'm tasked with writing a small web front end. LDAP
> validation required. Form data validation required.
>
> I have to post form data to an external URL because of retarded
> licensing issues. And validate the result using screen scraping.
>
> I had the initial version done and online that night. Some finishing
> touches were added this afternoon.
>
> THANK YOU CAMPING!!!
>
> Dan
>
>
> This communication is the property of Qwest and may contain confidential or
> privileged information. Unauthorized use of this communication is strictly
> prohibited and may be unlawful.  If you have received this communication
> in error, please immediately notify the sender by reply e-mail and destroy
> all copies of the communication and any attachments.
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
>

From why at whytheluckystiff.net  Tue Jun  3 04:11:45 2008
From: why at whytheluckystiff.net (_why)
Date: Tue, 3 Jun 2008 03:11:45 -0500
Subject: @@state_secret
Message-ID: <20080603081145.GM70833@beekeeper.hobix.com>

I was having some issue getting the class variables in
Camping::Session to work with some old apps, so I've changed
@@state_secret to a method.

  module Blog
    include Camping::Session
    def state_secret; "kxxxx" end
  end

Also, merged some of zimbatm's patches.  And trying to revive the
Junebug wiki <http://github.com/why/junebug> since it's still my
favorite one.

Oh and Passenger is working with Camping 2.0.  You just use
`run Blog` in your config.ru (following everything else in the
latest Passenger docs.)  Best to wait until they release 1.1.0 gems.

_why

From david.gurba at gmail.com  Tue Jun  3 09:26:17 2008
From: david.gurba at gmail.com (David Gurba)
Date: Tue, 3 Jun 2008 06:26:17 -0700
Subject: @@state_secret
In-Reply-To: <20080603081145.GM70833@beekeeper.hobix.com>
References: <20080603081145.GM70833@beekeeper.hobix.com>
Message-ID: <d4df073a0806030626v59044b58o4a923fcefc4a486d@mail.gmail.com>

I like Junebug alot ... maybe I'll try to add bluecloth to it or something
besides straight textile.

On Tue, Jun 3, 2008 at 1:11 AM, _why <why at whytheluckystiff.net> wrote:

> I was having some issue getting the class variables in
> Camping::Session to work with some old apps, so I've changed
> @@state_secret to a method.
>
>  module Blog
>    include Camping::Session
>    def state_secret; "kxxxx" end
>  end
>
> Also, merged some of zimbatm's patches.  And trying to revive the
> Junebug wiki <http://github.com/why/junebug> since it's still my
> favorite one.
>
> Oh and Passenger is working with Camping 2.0.  You just use
> `run Blog` in your config.ru (following everything else in the
> latest Passenger docs.)  Best to wait until they release 1.1.0 gems.
>
> _why
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/camping-list/attachments/20080603/b83b95d7/attachment.html>

From judofyr at gmail.com  Wed Jun  4 10:12:54 2008
From: judofyr at gmail.com (Magnus Holm)
Date: Wed, 4 Jun 2008 16:12:54 +0200
Subject: @@state_secret
In-Reply-To: <20080603081145.GM70833@beekeeper.hobix.com>
References: <20080603081145.GM70833@beekeeper.hobix.com>
Message-ID: <391a49da0806040712m281f0a6ck90407169355b34b@mail.gmail.com>

Great! If we clean up the documentation, are we then ready for 2.0?

The only thing I want now is the catch(:halt) in #service, so we can do stuff
like this:

  module Example
    module Helpers
      def require_login!
        unless @state.user_id
          redirect Login
          throw :halt
        end
      end
    end

    module Controllers
      class List < R '/list'
        def get
          require_login!
          # do stuff
        end
      end
    end
  end

(It's already in my repo, just pull from judofyr/master)

On Tue, Jun 3, 2008 at 10:11 AM, _why <why at whytheluckystiff.net> wrote:
>
> I was having some issue getting the class variables in
> Camping::Session to work with some old apps, so I've changed
> @@state_secret to a method.
>
>  module Blog
>    include Camping::Session
>    def state_secret; "kxxxx" end
>  end
>
> Also, merged some of zimbatm's patches.  And trying to revive the
> Junebug wiki <http://github.com/why/junebug> since it's still my
> favorite one.
>
> Oh and Passenger is working with Camping 2.0.  You just use
> `run Blog` in your config.ru (following everything else in the
> latest Passenger docs.)  Best to wait until they release 1.1.0 gems.
>
> _why
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list



--
Magnus Holm

From blueberry at creativepony.com  Wed Jun  4 10:30:35 2008
From: blueberry at creativepony.com (Bluebie, Jenna)
Date: Thu, 5 Jun 2008 00:30:35 +1000
Subject: @@state_secret
In-Reply-To: <391a49da0806040712m281f0a6ck90407169355b34b@mail.gmail.com>
References: <20080603081145.GM70833@beekeeper.hobix.com>
	<391a49da0806040712m281f0a6ck90407169355b34b@mail.gmail.com>
Message-ID: <A571F98F-01AC-4C39-9352-01B42DA2AB32@creativepony.com>

I second this!

On 05/06/2008, at 12:12 AM, Magnus Holm wrote:

> Great! If we clean up the documentation, are we then ready for 2.0?
>
> The only thing I want now is the catch(:halt) in #service, so we can  
> do stuff
> like this:
>
>  module Example
>    module Helpers
>      def require_login!
>        unless @state.user_id
>          redirect Login
>          throw :halt
>        end
>      end
>    end
>
>    module Controllers
>      class List < R '/list'
>        def get
>          require_login!
>          # do stuff
>        end
>      end
>    end
>  end
>
> (It's already in my repo, just pull from judofyr/master)
>
> On Tue, Jun 3, 2008 at 10:11 AM, _why <why at whytheluckystiff.net>  
> wrote:
>>
>> I was having some issue getting the class variables in
>> Camping::Session to work with some old apps, so I've changed
>> @@state_secret to a method.
>>
>> module Blog
>>   include Camping::Session
>>   def state_secret; "kxxxx" end
>> end
>>
>> Also, merged some of zimbatm's patches.  And trying to revive the
>> Junebug wiki <http://github.com/why/junebug> since it's still my
>> favorite one.
>>
>> Oh and Passenger is working with Camping 2.0.  You just use
>> `run Blog` in your config.ru (following everything else in the
>> latest Passenger docs.)  Best to wait until they release 1.1.0 gems.
>>
>> _why
>> _______________________________________________
>> Camping-list mailing list
>> Camping-list at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/camping-list
>
>
>
> --
> Magnus Holm
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list


From julian.tarkhanov at gmail.com  Wed Jun  4 16:23:27 2008
From: julian.tarkhanov at gmail.com (Julian Tarkhanov)
Date: Wed, 4 Jun 2008 22:23:27 +0200
Subject: @@state_secret
In-Reply-To: <A571F98F-01AC-4C39-9352-01B42DA2AB32@creativepony.com>
References: <20080603081145.GM70833@beekeeper.hobix.com>
	<391a49da0806040712m281f0a6ck90407169355b34b@mail.gmail.com>
	<A571F98F-01AC-4C39-9352-01B42DA2AB32@creativepony.com>
Message-ID: <2FBA4ED2-167A-48E8-8AE4-89A6132C1C59@gmail.com>

Why do you need that if you can just skip calling super if the  
authentication fails?

On 4 jun 2008, at 16:30, Bluebie, Jenna wrote:

> I second this!
>
> On 05/06/2008, at 12:12 AM, Magnus Holm wrote:
>
>> Great! If we clean up the documentation, are we then ready for 2.0?
>>
>> The only thing I want now is the catch(:halt) in #service, so we  
>> can do stuff
>> like this:


From blueberry at creativepony.com  Wed Jun  4 18:46:39 2008
From: blueberry at creativepony.com (Bluebie, Jenna)
Date: Thu, 5 Jun 2008 08:46:39 +1000
Subject: @@state_secret
In-Reply-To: <2FBA4ED2-167A-48E8-8AE4-89A6132C1C59@gmail.com>
References: <20080603081145.GM70833@beekeeper.hobix.com>
	<391a49da0806040712m281f0a6ck90407169355b34b@mail.gmail.com>
	<A571F98F-01AC-4C39-9352-01B42DA2AB32@creativepony.com>
	<2FBA4ED2-167A-48E8-8AE4-89A6132C1C59@gmail.com>
Message-ID: <7DCC7A0B-DD2B-4F3B-AE4E-07EBBE3A1890@creativepony.com>

No no, this is something we can use in helper methods, so writing  
'render :blah' for instance would render it and terminate the  
thingo... instead of having to be the very last thing in the  
controller method or be prefixed with return. Though I don't mind this  
too much, it would open possibilities for some nifty things.

On 05/06/2008, at 6:23 AM, Julian Tarkhanov wrote:

> Why do you need that if you can just skip calling super if the  
> authentication fails?
>
> On 4 jun 2008, at 16:30, Bluebie, Jenna wrote:
>
>> I second this!
>>
>> On 05/06/2008, at 12:12 AM, Magnus Holm wrote:
>>
>>> Great! If we clean up the documentation, are we then ready for 2.0?
>>>
>>> The only thing I want now is the catch(:halt) in #service, so we  
>>> can do stuff
>>> like this:
>
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list


From aredridel at nbtsc.org  Wed Jun  4 18:58:21 2008
From: aredridel at nbtsc.org (Aria Stewart)
Date: Wed, 4 Jun 2008 16:58:21 -0600
Subject: @@state_secret
In-Reply-To: <7DCC7A0B-DD2B-4F3B-AE4E-07EBBE3A1890@creativepony.com>
References: <20080603081145.GM70833@beekeeper.hobix.com>
	<391a49da0806040712m281f0a6ck90407169355b34b@mail.gmail.com>
	<A571F98F-01AC-4C39-9352-01B42DA2AB32@creativepony.com>
	<2FBA4ED2-167A-48E8-8AE4-89A6132C1C59@gmail.com>
	<7DCC7A0B-DD2B-4F3B-AE4E-07EBBE3A1890@creativepony.com>
Message-ID: <292C8D75-7778-419B-A3A9-E3DCD94874AB@nbtsc.org>


On Jun 4, 2008, at 4:46 PM, Bluebie, Jenna wrote:

> No no, this is something we can use in helper methods, so writing  
> 'render :blah' for instance would render it and terminate the  
> thingo... instead of having to be the very last thing in the  
> controller method or be prefixed with return. Though I don't mind  
> this too much, it would open possibilities for some nifty things.
>

I almost expected this behavior. I've certainly wondered where my view  
went when I did something after rendering.

Aria Stewart
aredridel at nbtsc.org




From blueberry at creativepony.com  Wed Jun  4 19:41:16 2008
From: blueberry at creativepony.com (Bluebie, Jenna)
Date: Thu, 5 Jun 2008 09:41:16 +1000
Subject: @@state_secret
In-Reply-To: <292C8D75-7778-419B-A3A9-E3DCD94874AB@nbtsc.org>
References: <20080603081145.GM70833@beekeeper.hobix.com>
	<391a49da0806040712m281f0a6ck90407169355b34b@mail.gmail.com>
	<A571F98F-01AC-4C39-9352-01B42DA2AB32@creativepony.com>
	<2FBA4ED2-167A-48E8-8AE4-89A6132C1C59@gmail.com>
	<7DCC7A0B-DD2B-4F3B-AE4E-07EBBE3A1890@creativepony.com>
	<292C8D75-7778-419B-A3A9-E3DCD94874AB@nbtsc.org>
Message-ID: <D15ED4B4-F634-4274-8F60-DFF7B133DF80@creativepony.com>

I've had that annoyance too. Another thing I really want to see fixed  
in 2.0 is when the controller returns something that isn't a string,  
ignore it! Don't throw exceptions about thingo not being a stringo.  
Writing methods called using xmlhttprequests, sometimes I don't return  
anything, so the last method ends up returning a number or something  
and breaks everything. I shouldn't have to put return ''; at the end  
of a controller method to make it work.


On 05/06/2008, at 8:58 AM, Aria Stewart wrote:

>
> On Jun 4, 2008, at 4:46 PM, Bluebie, Jenna wrote:
>
>> No no, this is something we can use in helper methods, so writing  
>> 'render :blah' for instance would render it and terminate the  
>> thingo... instead of having to be the very last thing in the  
>> controller method or be prefixed with return. Though I don't mind  
>> this too much, it would open possibilities for some nifty things.
>>
>
> I almost expected this behavior. I've certainly wondered where my  
> view went when I did something after rendering.
>
> Aria Stewart
> aredridel at nbtsc.org
>
>
>
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list


From ironald at gmail.com  Thu Jun  5 01:02:00 2008
From: ironald at gmail.com (ronald.evangelista)
Date: Thu, 05 Jun 2008 13:02:00 +0800
Subject: @@state_secret
In-Reply-To: <391a49da0806040712m281f0a6ck90407169355b34b@mail.gmail.com>
References: <391a49da0806040712m281f0a6ck90407169355b34b@mail.gmail.com>
Message-ID: <48477348.80009@gmail.com>

would be great to do something simple like that for authenticating 
controller methods.
been using something like this to authenticate get and post in one sweep.

    module Controllers
        module AuthenticationHelper
            def self.included(base)
                base.module_eval do
                    def get(*a)
                    end  unless method_defined? :get
                    def post(*a)
                    end unless method_defined? :post

                    alias_method :__post__, :post
                    alias_method :__get__ , :get

                    def get(*args)
                        on_authenticated do
                            __get__(*args)
                        end
                    end
                    def post(*args)
                        on_authenticated do
                            __post__(*args)
                        end
                    end
                end
            end
            private
            def on_authenticated
                unless @state.blank? or @state.user_id.nil?
                    yield
                else
                    @state.link_back=@env.REQUEST_URI
                    redirect(Login)
                end
            end
        end
    end

  # included at the end
class Add
    def get;end
    def post;end
    include AuthenticationHelper
end


From ironald at gmail.com  Thu Jun  5 04:19:45 2008
From: ironald at gmail.com (ronald.evangelista)
Date: Thu, 05 Jun 2008 16:19:45 +0800
Subject: how to add a method without coding it directly into app?
Message-ID: <4847A1A1.8010503@gmail.com>

i'm missing something here.
how would I code this outside the application to be shared with other 
Camping apps?

module Blog::Controllers
    module AuthenticationHelper
        def self.included(base)
            class << base
                define_method :authenticate do |*a|
                    a.each do |meth|
                        if method_defined?(meth.to_s)
                            alias_method "__#{meth}__", meth
                            class_def(meth) do |*a|
                                @state.Back=@env.REQUEST_URI
                                return redirect(Login) if @state.blank? 
or @state.user_id.nil?
                                send("__#{meth}__", *a)
                            end
                        end
                    end
                end
            end
        end
    end
end

any hints? thanks!

From blueberry at creativepony.com  Thu Jun  5 04:21:24 2008
From: blueberry at creativepony.com (Bluebie, Jenna)
Date: Thu, 5 Jun 2008 18:21:24 +1000
Subject: how to add a method without coding it directly into app?
In-Reply-To: <4847A1A1.8010503@gmail.com>
References: <4847A1A1.8010503@gmail.com>
Message-ID: <462A6743-C37C-42BD-8CBB-E0DF7BC5F7E8@creativepony.com>

Change Blog::Controllers to Camping::Controllers and require it before  
Caming.goes :somewhere_else


On 05/06/2008, at 6:19 PM, ronald.evangelista wrote:

> i'm missing something here.
> how would I code this outside the application to be shared with  
> other Camping apps?
>
> module Blog::Controllers
>   module AuthenticationHelper
>       def self.included(base)
>           class << base
>               define_method :authenticate do |*a|
>                   a.each do |meth|
>                       if method_defined?(meth.to_s)
>                           alias_method "__#{meth}__", meth
>                           class_def(meth) do |*a|
>                               @state.Back=@env.REQUEST_URI
>                               return redirect(Login) if  
> @state.blank? or @state.user_id.nil?
>                               send("__#{meth}__", *a)
>                           end
>                       end
>                   end
>               end
>           end
>       end
>   end
> end
>
> any hints? thanks!
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list


From ironald at gmail.com  Thu Jun  5 04:53:53 2008
From: ironald at gmail.com (ronald.evangelista)
Date: Thu, 05 Jun 2008 16:53:53 +0800
Subject: how to add a method without coding it directly into app?
In-Reply-To: <462A6743-C37C-42BD-8CBB-E0DF7BC5F7E8@creativepony.com>
References: <462A6743-C37C-42BD-8CBB-E0DF7BC5F7E8@creativepony.com>
Message-ID: <4847A9A1.7010502@gmail.com>

..an oversight. :-)

modified slightly to work:

class_def(meth) do |*a|
    controller_module = self.class.name.split(/::/)
    controller_module.pop
    controller_module << :Login  # maybe this could be passed as an arg too
    controller_module=controller_module.join("::").constantize
    @state.Back=@env.REQUEST_URI
    return redirect(controller_module) if @state.blank? or 
@state.user_id.nil?
    send("__#{meth}__", *a)
end

thanks for the speedy reply!

From why at whytheluckystiff.net  Thu Jun  5 20:36:04 2008
From: why at whytheluckystiff.net (_why)
Date: Thu, 5 Jun 2008 19:36:04 -0500
Subject: throw :halt
Message-ID: <20080606003604.GS70833@beekeeper.hobix.com>

Okay, I decided to go with Magnus' :halt idea.  I was skeptical, but
good points from the blueberry australian.  Anyway, it was only like
a thirteen-byte patch.  Now THAT'S a camping patch!

_why

From blueberry at creativepony.com  Thu Jun  5 21:18:22 2008
From: blueberry at creativepony.com (Bluebie, Jenna)
Date: Fri, 6 Jun 2008 11:18:22 +1000
Subject: Attention Judofyr: Broken cookies in 2.0
Message-ID: <82A50135-8063-476A-8CC6-E7267403BD2C@creativepony.com>

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>

From why at whytheluckystiff.net  Thu Jun  5 21:35:11 2008
From: why at whytheluckystiff.net (_why)
Date: Thu, 5 Jun 2008 20:35:11 -0500
Subject: Attention Judofyr: Broken cookies in 2.0
In-Reply-To: <82A50135-8063-476A-8CC6-E7267403BD2C@creativepony.com>
References: <82A50135-8063-476A-8CC6-E7267403BD2C@creativepony.com>
Message-ID: <20080606013511.GT70833@beekeeper.hobix.com>

On Fri, Jun 06, 2008 at 11:18:22AM +1000, Bluebie, Jenna wrote:
> 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.

Basically what you need to do is fork the project, add your changes,
commit, and send me a pull request.  The "pull request" is just a
message that you have some changes to pick up.  It's like putting up
the little flag on your mailbox to tell the mailman to stop by.

First off, go here: http://github.com/why/camping/tree/master.
And click the "fork" button.

>From there, you'll need to do the rest from a console:

  $ git clone git at github.com:Bluebie/camping.git
  $ cd camping
  # ... make your changes ...

  $ git commit -a
  # ... saves your changes ...

  $ git push
  # ... sends your changes to github ...

And then, you can just send me a pull request.  Go to your camping
page: http://github.com/Bluebie/camping/tree/master.  Click on "pull
request" and explain the change.

You're going to love it.

_why

From blueberry at creativepony.com  Thu Jun  5 21:54:07 2008
From: blueberry at creativepony.com (Bluebie, Jenna)
Date: Fri, 6 Jun 2008 11:54:07 +1000
Subject: Attention Judofyr: Broken cookies in 2.0
In-Reply-To: <20080606013511.GT70833@beekeeper.hobix.com>
References: <82A50135-8063-476A-8CC6-E7267403BD2C@creativepony.com>
	<20080606013511.GT70833@beekeeper.hobix.com>
Message-ID: <E3BA3603-03EC-49E9-88FA-20434CC2C5FE@creativepony.com>

now it's in vim and I don't know what to do and it wont let me quit  
and wont save...
On 06/06/2008, at 11:35 AM, _why wrote:

> On Fri, Jun 06, 2008 at 11:18:22AM +1000, Bluebie, Jenna wrote:
>> 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.
>
> Basically what you need to do is fork the project, add your changes,
> commit, and send me a pull request.  The "pull request" is just a
> message that you have some changes to pick up.  It's like putting up
> the little flag on your mailbox to tell the mailman to stop by.
>
> First off, go here: http://github.com/why/camping/tree/master.
> And click the "fork" button.
>
>> From there, you'll need to do the rest from a console:
>
>  $ git clone git at github.com:Bluebie/camping.git
>  $ cd camping
>  # ... make your changes ...
>
>  $ git commit -a
>  # ... saves your changes ...
>
>  $ git push
>  # ... sends your changes to github ...
>
> And then, you can just send me a pull request.  Go to your camping
> page: http://github.com/Bluebie/camping/tree/master.  Click on "pull
> request" and explain the change.
>
> You're going to love it.
>
> _why
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list


From blueberry at creativepony.com  Thu Jun  5 22:07:39 2008
From: blueberry at creativepony.com (Bluebie, Jenna)
Date: Fri, 6 Jun 2008 12:07:39 +1000
Subject: Attention Judofyr: Broken cookies in 2.0
In-Reply-To: <E3BA3603-03EC-49E9-88FA-20434CC2C5FE@creativepony.com>
References: <82A50135-8063-476A-8CC6-E7267403BD2C@creativepony.com>
	<20080606013511.GT70833@beekeeper.hobix.com>
	<E3BA3603-03EC-49E9-88FA-20434CC2C5FE@creativepony.com>
Message-ID: <35E5941D-84A2-4257-A0B3-93767F12F5D4@creativepony.com>

I did some vimtutor and put some text in the thing and then :wq to  
save it and then it says:

> fatal: There was a problem with the editor vi.


A fantastic descriptive error if ever I did see one.

can someone tell me how the heck to make vim go? Or better yet how to  
hack git to use TextMate or Coda instead?


On 06/06/2008, at 11:54 AM, Bluebie, Jenna wrote:

> now it's in vim and I don't know what to do and it wont let me quit  
> and wont save...
> On 06/06/2008, at 11:35 AM, _why wrote:
>
>> On Fri, Jun 06, 2008 at 11:18:22AM +1000, Bluebie, Jenna wrote:
>>> 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.
>>
>> Basically what you need to do is fork the project, add your changes,
>> commit, and send me a pull request.  The "pull request" is just a
>> message that you have some changes to pick up.  It's like putting up
>> the little flag on your mailbox to tell the mailman to stop by.
>>
>> First off, go here: http://github.com/why/camping/tree/master.
>> And click the "fork" button.
>>
>>> From there, you'll need to do the rest from a console:
>>
>> $ git clone git at github.com:Bluebie/camping.git
>> $ cd camping
>> # ... make your changes ...
>>
>> $ git commit -a
>> # ... saves your changes ...
>>
>> $ git push
>> # ... sends your changes to github ...
>>
>> And then, you can just send me a pull request.  Go to your camping
>> page: http://github.com/Bluebie/camping/tree/master.  Click on "pull
>> request" and explain the change.
>>
>> You're going to love it.
>>
>> _why
>> _______________________________________________
>> Camping-list mailing list
>> Camping-list at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/camping-list
>
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list


From kprojection at gmail.com  Thu Jun  5 22:11:33 2008
From: kprojection at gmail.com (Eric Mill)
Date: Thu, 5 Jun 2008 22:11:33 -0400
Subject: Attention Judofyr: Broken cookies in 2.0
In-Reply-To: <35E5941D-84A2-4257-A0B3-93767F12F5D4@creativepony.com>
References: <82A50135-8063-476A-8CC6-E7267403BD2C@creativepony.com>
	<20080606013511.GT70833@beekeeper.hobix.com>
	<E3BA3603-03EC-49E9-88FA-20434CC2C5FE@creativepony.com>
	<35E5941D-84A2-4257-A0B3-93767F12F5D4@creativepony.com>
Message-ID: <c658be6b0806051911l3f58afa3ha9db71b5c98cc72e@mail.gmail.com>

How did you end up in vim?  You don't need to use any particular
editor, edit the files from the repository any way you want.  You
don't actually have to make all your changes from the command line.

-- Eric

On Thu, Jun 5, 2008 at 10:07 PM, Bluebie, Jenna
<blueberry at creativepony.com> wrote:
> I did some vimtutor and put some text in the thing and then :wq to save it
> and then it says:
>
>> fatal: There was a problem with the editor vi.
>
>
> A fantastic descriptive error if ever I did see one.
>
> can someone tell me how the heck to make vim go? Or better yet how to hack
> git to use TextMate or Coda instead?
>
>
> On 06/06/2008, at 11:54 AM, Bluebie, Jenna wrote:
>
>> now it's in vim and I don't know what to do and it wont let me quit and
>> wont save...
>> On 06/06/2008, at 11:35 AM, _why wrote:
>>
>>> On Fri, Jun 06, 2008 at 11:18:22AM +1000, Bluebie, Jenna wrote:
>>>>
>>>> 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.
>>>
>>> Basically what you need to do is fork the project, add your changes,
>>> commit, and send me a pull request.  The "pull request" is just a
>>> message that you have some changes to pick up.  It's like putting up
>>> the little flag on your mailbox to tell the mailman to stop by.
>>>
>>> First off, go here: http://github.com/why/camping/tree/master.
>>> And click the "fork" button.
>>>
>>>> From there, you'll need to do the rest from a console:
>>>
>>> $ git clone git at github.com:Bluebie/camping.git
>>> $ cd camping
>>> # ... make your changes ...
>>>
>>> $ git commit -a
>>> # ... saves your changes ...
>>>
>>> $ git push
>>> # ... sends your changes to github ...
>>>
>>> And then, you can just send me a pull request.  Go to your camping
>>> page: http://github.com/Bluebie/camping/tree/master.  Click on "pull
>>> request" and explain the change.
>>>
>>> You're going to love it.
>>>
>>> _why
>>> _______________________________________________
>>> Camping-list mailing list
>>> Camping-list at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/camping-list
>>
>> _______________________________________________
>> Camping-list mailing list
>> Camping-list at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/camping-list
>
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
>

From blueberry at creativepony.com  Thu Jun  5 22:11:41 2008
From: blueberry at creativepony.com (Bluebie, Jenna)
Date: Fri, 6 Jun 2008 12:11:41 +1000
Subject: Attention Judofyr: Broken cookies in 2.0
In-Reply-To: <35E5941D-84A2-4257-A0B3-93767F12F5D4@creativepony.com>
References: <82A50135-8063-476A-8CC6-E7267403BD2C@creativepony.com>
	<20080606013511.GT70833@beekeeper.hobix.com>
	<E3BA3603-03EC-49E9-88FA-20434CC2C5FE@creativepony.com>
	<35E5941D-84A2-4257-A0B3-93767F12F5D4@creativepony.com>
Message-ID: <AC1B3B5F-686A-48EF-AC58-AE1BEBF8B26C@creativepony.com>

Ooh I figured it out!
On 06/06/2008, at 12:07 PM, Bluebie, Jenna wrote:

> I did some vimtutor and put some text in the thing and then :wq to  
> save it and then it says:
>
>> fatal: There was a problem with the editor vi.
>
>
> A fantastic descriptive error if ever I did see one.
>
> can someone tell me how the heck to make vim go? Or better yet how  
> to hack git to use TextMate or Coda instead?
>
>
> On 06/06/2008, at 11:54 AM, Bluebie, Jenna wrote:
>
>> now it's in vim and I don't know what to do and it wont let me quit  
>> and wont save...
>> On 06/06/2008, at 11:35 AM, _why wrote:
>>
>>> On Fri, Jun 06, 2008 at 11:18:22AM +1000, Bluebie, Jenna wrote:
>>>> 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.
>>>
>>> Basically what you need to do is fork the project, add your changes,
>>> commit, and send me a pull request.  The "pull request" is just a
>>> message that you have some changes to pick up.  It's like putting up
>>> the little flag on your mailbox to tell the mailman to stop by.
>>>
>>> First off, go here: http://github.com/why/camping/tree/master.
>>> And click the "fork" button.
>>>
>>>> From there, you'll need to do the rest from a console:
>>>
>>> $ git clone git at github.com:Bluebie/camping.git
>>> $ cd camping
>>> # ... make your changes ...
>>>
>>> $ git commit -a
>>> # ... saves your changes ...
>>>
>>> $ git push
>>> # ... sends your changes to github ...
>>>
>>> And then, you can just send me a pull request.  Go to your camping
>>> page: http://github.com/Bluebie/camping/tree/master.  Click on "pull
>>> request" and explain the change.
>>>
>>> You're going to love it.
>>>
>>> _why
>>> _______________________________________________
>>> Camping-list mailing list
>>> Camping-list at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/camping-list
>>
>> _______________________________________________
>> Camping-list mailing list
>> Camping-list at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/camping-list
>
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list


From blueberry at creativepony.com  Thu Jun  5 22:12:54 2008
From: blueberry at creativepony.com (Bluebie, Jenna)
Date: Fri, 6 Jun 2008 12:12:54 +1000
Subject: Attention Judofyr: Broken cookies in 2.0
In-Reply-To: <c658be6b0806051911l3f58afa3ha9db71b5c98cc72e@mail.gmail.com>
References: <82A50135-8063-476A-8CC6-E7267403BD2C@creativepony.com>
	<20080606013511.GT70833@beekeeper.hobix.com>
	<E3BA3603-03EC-49E9-88FA-20434CC2C5FE@creativepony.com>
	<35E5941D-84A2-4257-A0B3-93767F12F5D4@creativepony.com>
	<c658be6b0806051911l3f58afa3ha9db71b5c98cc72e@mail.gmail.com>
Message-ID: <2341CB0E-D9B0-44D4-A15B-920A376DFD65@creativepony.com>

git forced me in to vim when I did git commit -a. Turns out that's  
what it defaults to when EDITOR enviroment variable isn't set. Now it  
is, all is well.


On 06/06/2008, at 12:11 PM, Eric Mill wrote:

> How did you end up in vim?  You don't need to use any particular
> editor, edit the files from the repository any way you want.  You
> don't actually have to make all your changes from the command line.
>
> -- Eric
>
> On Thu, Jun 5, 2008 at 10:07 PM, Bluebie, Jenna
> <blueberry at creativepony.com> wrote:
>> I did some vimtutor and put some text in the thing and then :wq to  
>> save it
>> and then it says:
>>
>>> fatal: There was a problem with the editor vi.
>>
>>
>> A fantastic descriptive error if ever I did see one.
>>
>> can someone tell me how the heck to make vim go? Or better yet how  
>> to hack
>> git to use TextMate or Coda instead?
>>
>>
>> On 06/06/2008, at 11:54 AM, Bluebie, Jenna wrote:
>>
>>> now it's in vim and I don't know what to do and it wont let me  
>>> quit and
>>> wont save...
>>> On 06/06/2008, at 11:35 AM, _why wrote:
>>>
>>>> On Fri, Jun 06, 2008 at 11:18:22AM +1000, Bluebie, Jenna wrote:
>>>>>
>>>>> 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.
>>>>
>>>> Basically what you need to do is fork the project, add your  
>>>> changes,
>>>> commit, and send me a pull request.  The "pull request" is just a
>>>> message that you have some changes to pick up.  It's like putting  
>>>> up
>>>> the little flag on your mailbox to tell the mailman to stop by.
>>>>
>>>> First off, go here: http://github.com/why/camping/tree/master.
>>>> And click the "fork" button.
>>>>
>>>>> From there, you'll need to do the rest from a console:
>>>>
>>>> $ git clone git at github.com:Bluebie/camping.git
>>>> $ cd camping
>>>> # ... make your changes ...
>>>>
>>>> $ git commit -a
>>>> # ... saves your changes ...
>>>>
>>>> $ git push
>>>> # ... sends your changes to github ...
>>>>
>>>> And then, you can just send me a pull request.  Go to your camping
>>>> page: http://github.com/Bluebie/camping/tree/master.  Click on  
>>>> "pull
>>>> request" and explain the change.
>>>>
>>>> You're going to love it.
>>>>
>>>> _why
>>>> _______________________________________________
>>>> Camping-list mailing list
>>>> Camping-list at rubyforge.org
>>>> http://rubyforge.org/mailman/listinfo/camping-list
>>>
>>> _______________________________________________
>>> Camping-list mailing list
>>> Camping-list at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/camping-list
>>
>> _______________________________________________
>> Camping-list mailing list
>> Camping-list at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/camping-list
>>
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list


From anibalrojas at gmail.com  Thu Jun  5 22:14:48 2008
From: anibalrojas at gmail.com (=?ISO-8859-1?Q?An=EDbal_Rojas?=)
Date: Fri, 6 Jun 2008 21:44:48 +1930
Subject: Attention Judofyr: Broken cookies in 2.0
In-Reply-To: <2341CB0E-D9B0-44D4-A15B-920A376DFD65@creativepony.com>
References: <82A50135-8063-476A-8CC6-E7267403BD2C@creativepony.com>
	<20080606013511.GT70833@beekeeper.hobix.com>
	<E3BA3603-03EC-49E9-88FA-20434CC2C5FE@creativepony.com>
	<35E5941D-84A2-4257-A0B3-93767F12F5D4@creativepony.com>
	<c658be6b0806051911l3f58afa3ha9db71b5c98cc72e@mail.gmail.com>
	<2341CB0E-D9B0-44D4-A15B-920A376DFD65@creativepony.com>
Message-ID: <dd83951f0806051914x2da00ab4u5bc7414548ac78eb@mail.gmail.com>

Use the -m switch

-- 
An?bal

On Fri, Jun 6, 2008 at 9:42 PM, Bluebie, Jenna
<blueberry at creativepony.com> wrote:
> git forced me in to vim when I did git commit -a. Turns out that's what it
> defaults to when EDITOR enviroment variable isn't set. Now it is, all is
> well.
>
>
> On 06/06/2008, at 12:11 PM, Eric Mill wrote:
>
>> How did you end up in vim?  You don't need to use any particular
>> editor, edit the files from the repository any way you want.  You
>> don't actually have to make all your changes from the command line.
>>
>> -- Eric
>>
>> On Thu, Jun 5, 2008 at 10:07 PM, Bluebie, Jenna
>> <blueberry at creativepony.com> wrote:
>>>
>>> I did some vimtutor and put some text in the thing and then :wq to save
>>> it
>>> and then it says:
>>>
>>>> fatal: There was a problem with the editor vi.
>>>
>>>
>>> A fantastic descriptive error if ever I did see one.
>>>
>>> can someone tell me how the heck to make vim go? Or better yet how to
>>> hack
>>> git to use TextMate or Coda instead?
>>>
>>>
>>> On 06/06/2008, at 11:54 AM, Bluebie, Jenna wrote:
>>>
>>>> now it's in vim and I don't know what to do and it wont let me quit and
>>>> wont save...
>>>> On 06/06/2008, at 11:35 AM, _why wrote:
>>>>
>>>>> On Fri, Jun 06, 2008 at 11:18:22AM +1000, Bluebie, Jenna wrote:
>>>>>>
>>>>>> 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.
>>>>>
>>>>> Basically what you need to do is fork the project, add your changes,
>>>>> commit, and send me a pull request.  The "pull request" is just a
>>>>> message that you have some changes to pick up.  It's like putting up
>>>>> the little flag on your mailbox to tell the mailman to stop by.
>>>>>
>>>>> First off, go here: http://github.com/why/camping/tree/master.
>>>>> And click the "fork" button.
>>>>>
>>>>>> From there, you'll need to do the rest from a console:
>>>>>
>>>>> $ git clone git at github.com:Bluebie/camping.git
>>>>> $ cd camping
>>>>> # ... make your changes ...
>>>>>
>>>>> $ git commit -a
>>>>> # ... saves your changes ...
>>>>>
>>>>> $ git push
>>>>> # ... sends your changes to github ...
>>>>>
>>>>> And then, you can just send me a pull request.  Go to your camping
>>>>> page: http://github.com/Bluebie/camping/tree/master.  Click on "pull
>>>>> request" and explain the change.
>>>>>
>>>>> You're going to love it.
>>>>>
>>>>> _why
>>>>> _______________________________________________
>>>>> Camping-list mailing list
>>>>> Camping-list at rubyforge.org
>>>>> http://rubyforge.org/mailman/listinfo/camping-list
>>>>
>>>> _______________________________________________
>>>> Camping-list mailing list
>>>> Camping-list at rubyforge.org
>>>> http://rubyforge.org/mailman/listinfo/camping-list
>>>
>>> _______________________________________________
>>> Camping-list mailing list
>>> Camping-list at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/camping-list
>>>
>> _______________________________________________
>> Camping-list mailing list
>> Camping-list at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/camping-list
>
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
>

From blueberry at creativepony.com  Fri Jun  6 00:53:28 2008
From: blueberry at creativepony.com (Bluebie, Jenna)
Date: Fri, 6 Jun 2008 14:53:28 +1000
Subject: Quickie: URL Shortener's, some code.
Message-ID: <908BBB6B-BC1B-4946-8AF9-C0B8E739D40D@creativepony.com>

The wiki won't let me make new pages anymore, so I put it on my own  
site.
http://creativepony.com/journal/scripts/url-shorteners/

I hope it helps someone!


?
Jenna 

From judofyr at gmail.com  Fri Jun  6 09:07:50 2008
From: judofyr at gmail.com (Magnus Holm)
Date: Fri, 6 Jun 2008 15:07:50 +0200
Subject: Messy Cookies
Message-ID: <391a49da0806060607jea4701dt39a1ae732656e56f@mail.gmail.com>

It looks like everyone has tried to fix the cookies lately, and no-one managed
to get it 100% correctly.

The current implementation doesn't set the path correctly, and you can't use
@cookies in a #service-overload.

Qwzybug's patch fixed only the sessions.

Jenna's patch won't allow to set complex cookies (@cookies.key = {:path =>
"/path", :value => "value", :expires => Time.now + 900}) and won't work
properly when you use #method_missing (which allows you to do
Blog.get(:Controller)).

So I took Bluebie's code and rewrote it a bit. I moved some logic (which
currently is in #service) from #call to Base#to_a. So even if you're not using
Rack, you need to call #to_a in order to clean things up.

The code is available in the proper_cookie-branch:
http://github.com/judofyr/camping/commits/proper_cookies

I've tested it with Firefox + LiveHTTPHeaders and it seems to work fine. If
anyone spots a bug, please comment on a commit (or scream out on IRC)!

Oh, and _why has to decide if we should make the session-system completely
XSS-proof, or be a little more relaxed. It doesn't have to be XSS-proof as
long as you keep the cookies secret (aka, escapes all Javascript).

--
Magnus Holm

From devin.chalmers at gmail.com  Fri Jun  6 16:06:35 2008
From: devin.chalmers at gmail.com (Devin Chalmers)
Date: Fri, 6 Jun 2008 13:06:35 -0700
Subject: Messy Cookies
In-Reply-To: <391a49da0806060607jea4701dt39a1ae732656e56f@mail.gmail.com>
References: <391a49da0806060607jea4701dt39a1ae732656e56f@mail.gmail.com>
Message-ID: <d7273a4e0806061306g6de1858fx3b6e563fb1bcac59@mail.gmail.com>

On Fri, Jun 6, 2008 at 6:07 AM, Magnus Holm <judofyr at gmail.com> wrote:

> It looks like everyone has tried to fix the cookies lately, and no-one
> managed
> to get it 100% correctly...
>

Thanks for the code, that seems to work really well and prettily. I admit
that, though I love writing apps in it, I am very new to hacking on the dark
underbelly of Camping. (Me, I just wanted to get sessions to work in the
Junebug wiki for a Ruby class I'm teaching some friends.)
Your new patch makes sense to me. I'd be interested to hear a discussion of
why the Bluebie version didn't work, because I thought that made sense too.
:)

I do like Jenna's streamlining of the session handling stuff:
http://github.com/Bluebie/camping/commit/8ef1e532453fd378b003f967c034c78f64dbc802
I tend to agree that for most Camping apps it's probably okay to keep the
cookie session around for the whole browser session, and that trying to
prevent session hijacking with IP addresses/UA strings is going to be
annoying for a fair amount of people.

On the other hand, removing the timeout and remote address stuff does make
it stupidly easy to steal a session, since all the session data is sent in
essentially cleartext with every request. (This is of course only very
slightly worse than, say, a username/password being sent in cleartext once
during a login.) Tricky tricky!

Myself, I'd prefer to keep Camping sessions super-simple, and just make sure
that the limitations are documented and the necessity of something like
OpenID or SSL is emphasized if you need really real security.

Like this:
http://rubyforge.org/pipermail/camping-list/2008-May/000712.html
and also this:
http://rubyforge.org/pipermail/camping-list/2008-May/000722.html

devin ('qwzybug')
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/camping-list/attachments/20080606/460fc15e/attachment.html>

From blueberry at creativepony.com  Fri Jun  6 19:52:52 2008
From: blueberry at creativepony.com (Bluebie, Jenna)
Date: Sat, 7 Jun 2008 09:52:52 +1000
Subject: Messy Cookies
In-Reply-To: <d7273a4e0806061306g6de1858fx3b6e563fb1bcac59@mail.gmail.com>
References: <391a49da0806060607jea4701dt39a1ae732656e56f@mail.gmail.com>
	<d7273a4e0806061306g6de1858fx3b6e563fb1bcac59@mail.gmail.com>
Message-ID: <B42AEBFE-831A-4319-85B5-834FBDB1F5C7@creativepony.com>

Judofyr: This isn't a question to ask _why. It simply cannot be done.  
Stealing cookies is not the same thing as XSS, and locking cookies to  
an IP address will not stop XSS at all. Locking cookies to an IP  
address (as I wrote in my git commit where I removed it) will lock out  
AOL users, and surely many others on large NAT based networks. We  
aren't just talking getting logged out occasionally. Every single  
request from an AOL user comes from a seemingly random IP address,  
often from a different continent to where the user is. This is because  
AOL user's don't have their own internet IP address. The network is a  
giant nat, but it's a nat with several outgoing IP's, and every time a  
connection is made, it's sent through a different IP.

In a world where IPv6 still hasn't gained serious traction and the  
IPv4 address space continues to shrink, this practice is only becoming  
more and more common. In some countries, they only have 2-5 IP's to  
NAT the whole country through.

To understand why we can't fix XSS in the cookies handler you have to  
understand what XSS is. Imagine a bank, who has a camping app for  
internet banking. Imagine they have a /login controller, and a / 
transfer_monies controller. XSS is when a bad person creates a webpage  
with a tag in it capable of loading remote resources, like <img>, and  
sets the src attribute to http://mybank.com/transfer_monies?to=888422243&name=Hahahahaha

Then they direct the user to this page, which could be on myspace or  
anywhere else html embedding is allowed, while the target is logged in  
to their banking website. When their browser reaches the page, and  
parses the <img>, it throws that get request on to the queue, and when  
it gets around to it, it goes right ahead and loads that address with  
a get request with all the users cookies in tact. This can't be worked  
around by requiring important things to be done with the 'post' method  
either as it is incredibly easy to make an invisible form that  
automatically submits as soon as it is parsed.

The one attack binding cookies to the user's IP address prevents (in  
countries and ISP's where each user has their own IP address, and  
their ISP's don't allow other user's to request a specific IP from the  
DHCP server's and get it if it is available now) is someone who  
inserts a <script> or a java applet or flash player in to the page,  
and then puts scripting in the <script>, applet, or flash, to read the  
value of document.cookie, url encode it, and send it to a remote  
server the attacker controls... or even just to a guestbook or  
something. The lesson here is don't let your user's embed nasty html  
code if your site has valuable stuff in it, or if you have admin  
accounts that can do damage if stolen.

One way to put a stop to XSS attacks is to require important requests  
to have a token on the end, something only the server knows. The token  
is added to all the links that change some state on the server, and  
all of those controllers have to check it and instantly redirect the  
user back to a page where there is no token. If they don't redirect  
back, the user is left on a url with a token in it and they are then  
vulnerable to social engineering.

I've put up a simple implementation of this here: http://code.whytheluckystiff.net/camping/wiki/XssBeGoneWithSessions

But I'm sure you can imagine why this process cannot be automated.  
Camping can't know which controllers are important and which aren't,  
and the user still has to consciously make them redirect back to some  
place. Using that little script, the attacker can't figure out the url  
to put in their <img> and so they can't make a valid request. One  
thing that would also help against XSS would be to dump all requests  
that have a referrer from some place else, but then.. nobody would be  
able to get to your app from a link on some website anymore.

All these things are far beyond the scope of Session anyway. I feel  
very strongly that if you make the cookies locked down to an IP  
address then you are making camping incompatible with the internet.

On the plus side: Yay! We have working sessions! ^_^

Does the stuff I changed now work? Can you safely use @body, @headers,  
@cookies from anywhere inside a service?

?
Jenna

On 07/06/2008, at 6:06 AM, Devin Chalmers wrote:

> On Fri, Jun 6, 2008 at 6:07 AM, Magnus Holm <judofyr at gmail.com> wrote:
> It looks like everyone has tried to fix the cookies lately, and no- 
> one managed
> to get it 100% correctly...
>
> Thanks for the code, that seems to work really well and prettily. I  
> admit that, though I love writing apps in it, I am very new to  
> hacking on the dark underbelly of Camping. (Me, I just wanted to get  
> sessions to work in the Junebug wiki for a Ruby class I'm teaching  
> some friends.)
>
> Your new patch makes sense to me. I'd be interested to hear a  
> discussion of why the Bluebie version didn't work, because I thought  
> that made sense too. :)
>
> I do like Jenna's streamlining of the session handling stuff: http://github.com/Bluebie/camping/commit/8ef1e532453fd378b003f967c034c78f64dbc802
> I tend to agree that for most Camping apps it's probably okay to  
> keep the cookie session around for the whole browser session, and  
> that trying to prevent session hijacking with IP addresses/UA  
> strings is going to be annoying for a fair amount of people.
>
> On the other hand, removing the timeout and remote address stuff  
> does make it stupidly easy to steal a session, since all the session  
> data is sent in essentially cleartext with every request. (This is  
> of course only very slightly worse than, say, a username/password  
> being sent in cleartext once during a login.) Tricky tricky!
>
> Myself, I'd prefer to keep Camping sessions super-simple, and just  
> make sure that the limitations are documented and the necessity of  
> something like OpenID or SSL is emphasized if you need really real  
> security.
>
> Like this:
> http://rubyforge.org/pipermail/camping-list/2008-May/000712.html
> and also this:
> http://rubyforge.org/pipermail/camping-list/2008-May/000722.html
>
> devin ('qwzybug')
>
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/camping-list/attachments/20080607/3b852c0b/attachment.html>

From judofyr at gmail.com  Sun Jun 22 18:16:35 2008
From: judofyr at gmail.com (Magnus Holm)
Date: Mon, 23 Jun 2008 00:16:35 +0200
Subject: Getting rid of the route maker
Message-ID: <391a49da0806221516h7765cf1dv79371bb29d74c9c4@mail.gmail.com>

The route maker's job is basically two things:
- Make sure that all controllers includes the right mixins
- If any controllers doesn't respond to "urls" (aka. haven't been inherited
  from R) define "urls" as ClassName.downcase

The first point can be accomplished within R, but not the latter. But it
should be noted that the latter also can cause some troubles. It's assuming
all constants under Controllers are class and all should be publicly
accessible:

module Camping::Controllers
  LIMIT = 6
  # Ops! Crashing time!

  class HiddenStuff;end
  # Ops! Hacking time!
end

By removing the route maker you must explicitly define controllers by
inherited it from R:

module Camping::Controllers
  class Posts
  end
  # No longer working!
  # Stick with this:
  class Posts < R '/posts'
  end
end

What do you think? (It's also 135 bytes smaller). Code available here:
http://github.com/judofyr/camping/tree/no_route_maker

--
Magnus Holm

From zimbatm at oree.ch  Mon Jun 23 06:17:47 2008
From: zimbatm at oree.ch (zimbatm)
Date: Mon, 23 Jun 2008 12:17:47 +0200
Subject: Getting rid of the route maker
In-Reply-To: <391a49da0806221516h7765cf1dv79371bb29d74c9c4@mail.gmail.com>
References: <391a49da0806221516h7765cf1dv79371bb29d74c9c4@mail.gmail.com>
Message-ID: <e3caf1460806230317w152fd039p267d06ed17af59b7@mail.gmail.com>

Hey, why not. I'd much prefer to at least allow a "class Name < R;
end" construct

Longer answer :

The constants problem can also be avoided by checking it's type. I
never encountered that problem because that Controllers module is
exactly there to separate the code logic. Other constants must go one
level higher. Otherwise, we could scrap the modules all together an
build our apps on a 1 module level.

The real problem, I believe, is the late module inclusion. It makes it
harder to build plugins and such. While developing the "Equipment"
library, I had a weird inclusion mechanism I wish I didn't had to do.
Ruby also has some quirks regarding module inclusion into other
modules and late method definition in reopened parent module. So while
your patch might fix the most cases, I believe there is more work to
be done here. Anyways, keep up the good work.

Cheers,
  zimbatm

From judofyr at gmail.com  Mon Jun 23 06:38:52 2008
From: judofyr at gmail.com (Magnus Holm)
Date: Mon, 23 Jun 2008 12:38:52 +0200
Subject: Getting rid of the route maker
In-Reply-To: <e3caf1460806230317w152fd039p267d06ed17af59b7@mail.gmail.com>
References: <391a49da0806221516h7765cf1dv79371bb29d74c9c4@mail.gmail.com>
	<e3caf1460806230317w152fd039p267d06ed17af59b7@mail.gmail.com>
Message-ID: <391a49da0806230338m1d160b2fkaf6a933f0fdf337d@mail.gmail.com>

Yeah, I had to move the internal controller to the bottom, so it would include
Models too. I've never liked the route maker, and if we can do almost the same
without (and 135 bytes) it I would be happy.

Do you have any plans on making Equipment Camping 2.0 ready? Is there much to
do? Perhaps you could push it to GitHub?

On Mon, Jun 23, 2008 at 12:17 PM, zimbatm <zimbatm at oree.ch> wrote:
> Hey, why not. I'd much prefer to at least allow a "class Name < R;
> end" construct
>
> Longer answer :
>
> The constants problem can also be avoided by checking it's type. I
> never encountered that problem because that Controllers module is
> exactly there to separate the code logic. Other constants must go one
> level higher. Otherwise, we could scrap the modules all together an
> build our apps on a 1 module level.
>
> The real problem, I believe, is the late module inclusion. It makes it
> harder to build plugins and such. While developing the "Equipment"
> library, I had a weird inclusion mechanism I wish I didn't had to do.
> Ruby also has some quirks regarding module inclusion into other
> modules and late method definition in reopened parent module. So while
> your patch might fix the most cases, I believe there is more work to
> be done here. Anyways, keep up the good work.
>
> Cheers,
>  zimbatm
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
>



-- 
Magnus Holm

From why at whytheluckystiff.net  Mon Jun 23 18:14:22 2008
From: why at whytheluckystiff.net (_why)
Date: Mon, 23 Jun 2008 17:14:22 -0500
Subject: Getting rid of the route maker
In-Reply-To: <391a49da0806221516h7765cf1dv79371bb29d74c9c4@mail.gmail.com>
References: <391a49da0806221516h7765cf1dv79371bb29d74c9c4@mail.gmail.com>
Message-ID: <20080623221422.GM1424@beekeeper.hobix.com>

On Mon, Jun 23, 2008 at 12:16:35AM +0200, Magnus Holm wrote:
> The route maker's job is basically two things:
> - Make sure that all controllers includes the right mixins
> - If any controllers doesn't respond to "urls" (aka. haven't been inherited
>   from R) define "urls" as ClassName.downcase
> 
> The first point can be accomplished within R, but not the latter. But it
> should be noted that the latter also can cause some troubles.

Or, maybe, instead of getting rid of #2 we could make it go a bit
beyond just downcasing to help steer us away from regexps.

  module Blog::Controllers
    class Index # automatically '/'
      def get; end
    end

    class ViewN # automatically '/view/(\d+)'
      def get id; end
    end

    class ViewX # automatically '/view/(\w+)'
      def get name; end
    end

    class ViewYMD # automatically '/view/(\d+)/(\d+)/(\d+)'
      def get time; end
    end
  end 

_why

From judofyr at gmail.com  Tue Jun 24 07:05:54 2008
From: judofyr at gmail.com (Magnus Holm)
Date: Tue, 24 Jun 2008 13:05:54 +0200
Subject: Getting rid of the route maker
In-Reply-To: <20080623221422.GM1424@beekeeper.hobix.com>
References: <391a49da0806221516h7765cf1dv79371bb29d74c9c4@mail.gmail.com>
	<20080623221422.GM1424@beekeeper.hobix.com>
Message-ID: <391a49da0806240405o12ef1ddcld5e1716dc3c0c8c@mail.gmail.com>

Man, that's way better than removing 135 bytes! I *love* the implementation!

Alright! What about releasing 2.0? I've closed a lot of tickets on the
tracker, and I don't think we need more for a 2.0. There is no point
of waiting anymore, IMO!

On Tue, Jun 24, 2008 at 12:14 AM, _why <why at whytheluckystiff.net> wrote:
> On Mon, Jun 23, 2008 at 12:16:35AM +0200, Magnus Holm wrote:
>> The route maker's job is basically two things:
>> - Make sure that all controllers includes the right mixins
>> - If any controllers doesn't respond to "urls" (aka. haven't been inherited
>>   from R) define "urls" as ClassName.downcase
>>
>> The first point can be accomplished within R, but not the latter. But it
>> should be noted that the latter also can cause some troubles.
>
> Or, maybe, instead of getting rid of #2 we could make it go a bit
> beyond just downcasing to help steer us away from regexps.
>
>  module Blog::Controllers
>    class Index # automatically '/'
>      def get; end
>    end
>
>    class ViewN # automatically '/view/(\d+)'
>      def get id; end
>    end
>
>    class ViewX # automatically '/view/(\w+)'
>      def get name; end
>    end
>
>    class ViewYMD # automatically '/view/(\d+)/(\d+)/(\d+)'
>      def get time; end
>    end
>  end
>
> _why
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
>



-- 
Magnus Holm

From julian.tarkhanov at gmail.com  Tue Jun 24 09:09:00 2008
From: julian.tarkhanov at gmail.com (Julik Tarkhanov)
Date: Tue, 24 Jun 2008 15:09:00 +0200
Subject: Getting rid of the route maker
In-Reply-To: <391a49da0806240405o12ef1ddcld5e1716dc3c0c8c@mail.gmail.com>
References: <391a49da0806221516h7765cf1dv79371bb29d74c9c4@mail.gmail.com>
	<20080623221422.GM1424@beekeeper.hobix.com>
	<391a49da0806240405o12ef1ddcld5e1716dc3c0c8c@mail.gmail.com>
Message-ID: <AC660AC2-CA2D-44CA-9170-ACC1ABC02A6B@gmail.com>

Does that mean we are losing the possinility for multiple routes per  
controller and such?
Or should I return something magic from self.urls to make controllers  
function the pre-2.0 way?

On Jun 24, 2008, at 1:05 PM, Magnus Holm wrote:

> Alright! What about releasing 2.0? I've closed a lot of tickets on the
> tracker, and I don't think we need more for a 2.0. There is no point
> of waiting anymore, IMO!

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/camping-list/attachments/20080624/6e33fd98/attachment.html>

From judofyr at gmail.com  Tue Jun 24 09:14:24 2008
From: judofyr at gmail.com (Magnus Holm)
Date: Tue, 24 Jun 2008 15:14:24 +0200
Subject: Getting rid of the route maker
In-Reply-To: <AC660AC2-CA2D-44CA-9170-ACC1ABC02A6B@gmail.com>
References: <391a49da0806221516h7765cf1dv79371bb29d74c9c4@mail.gmail.com>
	<20080623221422.GM1424@beekeeper.hobix.com>
	<391a49da0806240405o12ef1ddcld5e1716dc3c0c8c@mail.gmail.com>
	<AC660AC2-CA2D-44CA-9170-ACC1ABC02A6B@gmail.com>
Message-ID: <391a49da0806240614q694d525ax34b4e45a84d3e6a2@mail.gmail.com>

R isn't gone! Feel free to use both (and if you use R, it would not
add more routes:

module Camping::Controllers
  class Index;end
  class Advanced < R '/(some regex';end
  # /advanced will NOT route to Advanced
end

On Tue, Jun 24, 2008 at 3:09 PM, Julik Tarkhanov
<julian.tarkhanov at gmail.com> wrote:
> Does that mean we are losing the possinility for multiple routes per
> controller and such?
> Or should I return something magic from self.urls to make controllers
> function the pre-2.0 way?
>
> On Jun 24, 2008, at 1:05 PM, Magnus Holm wrote:
>
> Alright! What about releasing 2.0? I've closed a lot of tickets on the
>
> tracker, and I don't think we need more for a 2.0. There is no point
>
> of waiting anymore, IMO!
>
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
>



-- 
Magnus Holm

From julian.tarkhanov at gmail.com  Tue Jun 24 10:31:56 2008
From: julian.tarkhanov at gmail.com (Julik Tarkhanov)
Date: Tue, 24 Jun 2008 16:31:56 +0200
Subject: Getting rid of the route maker
In-Reply-To: <391a49da0806240614q694d525ax34b4e45a84d3e6a2@mail.gmail.com>
References: <391a49da0806221516h7765cf1dv79371bb29d74c9c4@mail.gmail.com>
	<20080623221422.GM1424@beekeeper.hobix.com>
	<391a49da0806240405o12ef1ddcld5e1716dc3c0c8c@mail.gmail.com>
	<AC660AC2-CA2D-44CA-9170-ACC1ABC02A6B@gmail.com>
	<391a49da0806240614q694d525ax34b4e45a84d3e6a2@mail.gmail.com>
Message-ID: <D9EB05C1-6A11-41E6-9180-17D1A228F03B@gmail.com>

Then I'm +1.
Can't wait to see my tests fail with 2.0 (I will obviously have to  
update Mosquito for the new version, although if we still have .run  
it should
work unmodified).

On Jun 24, 2008, at 3:14 PM, Magnus Holm wrote:

> R isn't gone! Feel free to use both (and if you use R, it would not
> add more routes:
>
> module Camping::Controllers
>   class Index;end
>   class Advanced < R '/(some regex';end
>   # /advanced will NOT route to Advanced
> end
>
> On Tue, Jun 24, 2008 at 3:09 PM, Julik Tarkhanov
> <julian.tarkhanov at gmail.com> wrote:
>> Does that mean we are losing the possinility for multiple routes per
>> controller and such?
>> Or should I return something magic from self.urls to make controllers
>> function the pre-2.0 way?
>>
>> On Jun 24, 2008, at 1:05 PM, Magnus Holm wrote:
>>
>> Alright! What about releasing 2.0? I've closed a lot of tickets on  
>> the
>>
>> tracker, and I don't think we need more for a 2.0. There is no point
>>
>> of waiting anymore, IMO!
>>
>> _______________________________________________
>> Camping-list mailing list
>> Camping-list at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/camping-list
>>
>
>
>
> -- 
> Magnus Holm
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list


From why at whytheluckystiff.net  Tue Jun 24 11:07:58 2008
From: why at whytheluckystiff.net (_why)
Date: Tue, 24 Jun 2008 10:07:58 -0500
Subject: Getting rid of the route maker
In-Reply-To: <391a49da0806240405o12ef1ddcld5e1716dc3c0c8c@mail.gmail.com>
References: <391a49da0806221516h7765cf1dv79371bb29d74c9c4@mail.gmail.com>
	<20080623221422.GM1424@beekeeper.hobix.com>
	<391a49da0806240405o12ef1ddcld5e1716dc3c0c8c@mail.gmail.com>
Message-ID: <20080624150757.GN1424@beekeeper.hobix.com>

On Tue, Jun 24, 2008 at 01:05:54PM +0200, Magnus Holm wrote:
> Man, that's way better than removing 135 bytes! I *love* the implementation!

I have always wanted to use Method#to_proc in Camping.

> Alright! What about releasing 2.0? I've closed a lot of tickets on the
> tracker, and I don't think we need more for a 2.0. There is no point
> of waiting anymore, IMO!

I have two things left: I need to figure out if I want to merge
zimbatm's Markaby patch.  And I'd like to go through Rack a bit more
myself and see if I can cut down the work we're doing.  Hopefully
today or tomorrow, though!

_why

From judofyr at gmail.com  Tue Jun 24 11:28:51 2008
From: judofyr at gmail.com (Magnus Holm)
Date: Tue, 24 Jun 2008 17:28:51 +0200
Subject: Getting rid of the route maker
In-Reply-To: <20080624150757.GN1424@beekeeper.hobix.com>
References: <391a49da0806221516h7765cf1dv79371bb29d74c9c4@mail.gmail.com>
	<20080623221422.GM1424@beekeeper.hobix.com>
	<391a49da0806240405o12ef1ddcld5e1716dc3c0c8c@mail.gmail.com>
	<20080624150757.GN1424@beekeeper.hobix.com>
Message-ID: <391a49da0806240828m21e6e1e3p3f0c33b28d9617c0@mail.gmail.com>

Nice! You should also go through the documentation, it's pretty bad at
the moment...

On Tue, Jun 24, 2008 at 5:07 PM, _why <why at whytheluckystiff.net> wrote:
> On Tue, Jun 24, 2008 at 01:05:54PM +0200, Magnus Holm wrote:
>> Man, that's way better than removing 135 bytes! I *love* the implementation!
>
> I have always wanted to use Method#to_proc in Camping.
>
>> Alright! What about releasing 2.0? I've closed a lot of tickets on the
>> tracker, and I don't think we need more for a 2.0. There is no point
>> of waiting anymore, IMO!
>
> I have two things left: I need to figure out if I want to merge
> zimbatm's Markaby patch.  And I'd like to go through Rack a bit more
> myself and see if I can cut down the work we're doing.  Hopefully
> today or tomorrow, though!
>
> _why
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
>



-- 
Magnus Holm

From zimbatm at oree.ch  Wed Jun 25 09:18:47 2008
From: zimbatm at oree.ch (zimbatm)
Date: Wed, 25 Jun 2008 15:18:47 +0200
Subject: Getting rid of the route maker
In-Reply-To: <20080624150757.GN1424@beekeeper.hobix.com>
References: <391a49da0806221516h7765cf1dv79371bb29d74c9c4@mail.gmail.com>
	<20080623221422.GM1424@beekeeper.hobix.com>
	<391a49da0806240405o12ef1ddcld5e1716dc3c0c8c@mail.gmail.com>
	<20080624150757.GN1424@beekeeper.hobix.com>
Message-ID: <e3caf1460806250618q144122fcx9e94451e34ecc026@mail.gmail.com>

2008/6/24 _why <why at whytheluckystiff.net>:
> I need to figure out if I want to merge zimbatm's Markaby patch.

These are the reasons behind the patch :
* Historically Markaby was expurged to attain the 0 dependencies
walhalla. Rack has changed it all
* Camping apps are really nice in a 1 file setup. Markaby is the perfect match
* (minor) Object#meta_def is not into camping's source, making the code clearer

One contra argument is that markaby is pretty old. Last time I checked
the trunk it was in a weird state. If I remember well,
it has been made Camping incompatible in favor of some Rails (!) goodness.

Cheers,
  zimbatm

From manfred at gmail.com  Wed Jun 25 09:58:50 2008
From: manfred at gmail.com (Manfred Stienstra)
Date: Wed, 25 Jun 2008 15:58:50 +0200
Subject: Getting rid of the route maker
In-Reply-To: <e3caf1460806250618q144122fcx9e94451e34ecc026@mail.gmail.com>
References: <391a49da0806221516h7765cf1dv79371bb29d74c9c4@mail.gmail.com>
	<20080623221422.GM1424@beekeeper.hobix.com>
	<391a49da0806240405o12ef1ddcld5e1716dc3c0c8c@mail.gmail.com>
	<20080624150757.GN1424@beekeeper.hobix.com>
	<e3caf1460806250618q144122fcx9e94451e34ecc026@mail.gmail.com>
Message-ID: <D67B6A1E-B3FA-4289-B230-A8B23C778291@gmail.com>


On Jun 25, 2008, at 3:18 PM, zimbatm wrote:
> One contra argument is that markaby is pretty old. Last time I checked
> the trunk it was in a weird state. If I remember well,
> it has been made Camping incompatible in favor of some Rails (!)  
> goodness.

Yeah, I removed Markaby from one of our Rails projects because it  
seemed to be leaking memory like crazy when I updated Rails. I don't  
have any empirical evidence unfortunately, but I think Markaby needs a  
refresh in order to work properly with either Camping > 1.0 or Rails >  
1.0.

Manfred

From jerry.west at ntlworld.com  Thu Jun 26 03:20:40 2008
From: jerry.west at ntlworld.com (Jerry West)
Date: Thu, 26 Jun 2008 08:20:40 +0100
Subject: Markaby leaks?
In-Reply-To: <D67B6A1E-B3FA-4289-B230-A8B23C778291@gmail.com>
References: <391a49da0806221516h7765cf1dv79371bb29d74c9c4@mail.gmail.com>	<20080623221422.GM1424@beekeeper.hobix.com>	<391a49da0806240405o12ef1ddcld5e1716dc3c0c8c@mail.gmail.com>	<20080624150757.GN1424@beekeeper.hobix.com>	<e3caf1460806250618q144122fcx9e94451e34ecc026@mail.gmail.com>
	<D67B6A1E-B3FA-4289-B230-A8B23C778291@gmail.com>
Message-ID: <48634348.9070900@ntlworld.com>

An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/camping-list/attachments/20080626/1612344b/attachment.html>

From manfred at gmail.com  Thu Jun 26 04:12:38 2008
From: manfred at gmail.com (Manfred Stienstra)
Date: Thu, 26 Jun 2008 10:12:38 +0200
Subject: Markaby leaks?
In-Reply-To: <48634348.9070900@ntlworld.com>
References: <391a49da0806221516h7765cf1dv79371bb29d74c9c4@mail.gmail.com>	<20080623221422.GM1424@beekeeper.hobix.com>	<391a49da0806240405o12ef1ddcld5e1716dc3c0c8c@mail.gmail.com>	<20080624150757.GN1424@beekeeper.hobix.com>	<e3caf1460806250618q144122fcx9e94451e34ecc026@mail.gmail.com>
	<D67B6A1E-B3FA-4289-B230-A8B23C778291@gmail.com>
	<48634348.9070900@ntlworld.com>
Message-ID: <F6CC6C51-9BF8-444C-9A28-17B85AD09A9F@gmail.com>


On Jun 26, 2008, at 9:20 AM, Jerry West wrote:

> I'm using Markaby a lot at present (with waves 0.7.3 currently).  If  
> it is meaningful to do so, I will gladly instrument my setup to  
> check for memory leaks, but someone will have to tell me how to do  
> so or point me in the right direction.

Cool, I meant that I noticed leaks under Rails, and haven't checked if  
it was actually Markaby. If you still want to check for leaks, Evan  
has a pretty nice writeup about Valgrind and Ruby: http://blog.evanweaver.com/articles/2008/02/05/valgrind-and-ruby/

Manfred

From zimbatm at oree.ch  Fri Jun 27 06:04:26 2008
From: zimbatm at oree.ch (zimbatm)
Date: Fri, 27 Jun 2008 12:04:26 +0200
Subject: Camping.method_missing useful ?
Message-ID: <e3caf1460806270304x41512e1bk96b7ace775ddaa50@mail.gmail.com>

The concept is fun but is it really used by people out there ?

From ironald at gmail.com  Fri Jun 27 06:28:43 2008
From: ironald at gmail.com (ronald.evangelista)
Date: Fri, 27 Jun 2008 18:28:43 +0800
Subject: Camping.method_missing useful ?
In-Reply-To: <e3caf1460806270304x41512e1bk96b7ace775ddaa50@mail.gmail.com>
References: <e3caf1460806270304x41512e1bk96b7ace775ddaa50@mail.gmail.com>
Message-ID: <4864C0DB.2020001@gmail.com>

Never really used Camping's scriptable dispatcher in practice.

From blueberry at creativepony.com  Fri Jun 27 06:29:23 2008
From: blueberry at creativepony.com (Bluebie, Jenna)
Date: Fri, 27 Jun 2008 20:29:23 +1000
Subject: Camping.method_missing useful ?
In-Reply-To: <e3caf1460806270304x41512e1bk96b7ace775ddaa50@mail.gmail.com>
References: <e3caf1460806270304x41512e1bk96b7ace775ddaa50@mail.gmail.com>
Message-ID: <CC6748BB-D301-4E30-80CA-222DDE252D86@creativepony.com>

I never use it, I think it is harmful to debugging, but hey, if we  
wanted a simple obvious framework, we wouldn't use camping to begin  
with. This is a fun hack, and once you're used to it's effect on error  
messages, everything is a-ok. :)

I vote to keep it!

On 27/06/2008, at 8:04 PM, zimbatm wrote:

> The concept is fun but is it really used by people out there ?
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list