From john.beppu at gmail.com  Mon May  5 00:14:20 2008
From: john.beppu at gmail.com (John Beppu)
Date: Sun, 4 May 2008 21:14:20 -0700
Subject: [poll] What was your primary language before you started coding in
	Ruby?
Message-ID: <21a10fe00805042114n571a94cbw92fedbd396571559@mail.gmail.com>

This is an informal poll.

If you are primarily a Ruby programmer,
- What was your primary language before you started coding in Ruby?
Else,
- What's your current programming language of choice?



I'll start:

Perl
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/camping-list/attachments/20080504/86c5bc39/attachment-0001.html>

From abeguelin05 at aol.com  Mon May  5 00:24:44 2008
From: abeguelin05 at aol.com (Adam Beguelin)
Date: Mon, 5 May 2008 11:24:44 +0700
Subject: [poll] What was your primary language before you started coding
	in Ruby?
In-Reply-To: <21a10fe00805042114n571a94cbw92fedbd396571559@mail.gmail.com>
References: <21a10fe00805042114n571a94cbw92fedbd396571559@mail.gmail.com>
Message-ID: <F3EC09EA-1372-4A28-9C48-CCAC42D75B9F@aol.com>


Java.  I tried Perl but it hurt my brain.  Then I found Ruby and it  
fit into my noggin even better than Java.


Check out my blogs:
http://saigon.beguelin.com
http://www.beguelin.com
http://ifood.beguelin.com


On May 5, 2008, at 11:14 AM, John Beppu wrote:

> This is an informal poll.
>
> If you are primarily a Ruby programmer,
> - What was your primary language before you started coding in Ruby?
> Else,
> - What's your current programming language of choice?
>
>
>
> I'll start:
>
> Perl
>
>
> _______________________________________________
> 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/20080505/3cbe9320/attachment.html>

From john.beppu at gmail.com  Mon May  5 00:48:21 2008
From: john.beppu at gmail.com (John Beppu)
Date: Sun, 4 May 2008 21:48:21 -0700
Subject: learning.kicks-ass.org
Message-ID: <21a10fe00805042148n1e3cdb6ep5aa0889268fd5e73@mail.gmail.com>

Hey Campers,

Here's a tiny little app I wrote shortly after SXSW this year.

http://learning.kicks-ass.org/

Click on the big red *RANDOM* button for some mild amusement.

The idea came from Heath Row over a dinner conversation as chronicled here:

http://h3athrow.blogspot.com/2008/03/learning-kicks.html

The source code is here:

http://github.com/beppu/learning/tree/master

It's in the public domain...  and I figured that it would be a good sample
application to look at for anyone getting started w/ Camping.  I'm using a
multiple file layout as described on the wiki, because it helps you move
around when you have medium sized Camping apps.  It also has an Atom feed
generator in the views which some of you may find useful.

Have fun.

--beppu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/camping-list/attachments/20080504/4f54231e/attachment.html>

From jeremymcanally at gmail.com  Mon May  5 00:55:53 2008
From: jeremymcanally at gmail.com (Jeremy McAnally)
Date: Mon, 5 May 2008 00:55:53 -0400
Subject: [poll] What was your primary language before you started coding
	in Ruby?
In-Reply-To: <F3EC09EA-1372-4A28-9C48-CCAC42D75B9F@aol.com>
References: <21a10fe00805042114n571a94cbw92fedbd396571559@mail.gmail.com>
	<F3EC09EA-1372-4A28-9C48-CCAC42D75B9F@aol.com>
Message-ID: <d878fe460805042155p692e5bb2ra783dcd0d1cd65f4@mail.gmail.com>

C# for GUI dev and PHP for web dev.  Then Python for just a little
while before Ruby.

--Jeremy

On Mon, May 5, 2008 at 12:24 AM, Adam Beguelin <abeguelin05 at aol.com> wrote:
>
> Java.  I tried Perl but it hurt my brain.  Then I found Ruby and it fit into
> my noggin even better than Java.
>
>
>
> Check out my blogs:
> http://saigon.beguelin.com
> http://www.beguelin.com
> http://ifood.beguelin.com
>
>
>
>
> On May 5, 2008, at 11:14 AM, John Beppu wrote:
>
>
> This is an informal poll.
>
> If you are primarily a Ruby programmer,
> - What was your primary language before you started coding in Ruby?
> Else,
> - What's your current programming language of choice?
>
>
>
> I'll start:
>
> Perl
>
>
> _______________________________________________
> 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
>



-- 
http://jeremymcanally.com/
http://entp.com

Read my books:
Ruby in Practice (http://manning.com/mcanally/)
My free Ruby e-book (http://humblelittlerubybook.com/)

Or, my blogs:
http://mrneighborly.com
http://rubyinpractice.com

From trevor at tjohns.net  Mon May  5 02:13:32 2008
From: trevor at tjohns.net (Trevor Johns)
Date: Sun, 4 May 2008 23:13:32 -0700
Subject: [poll] What was your primary language before you started coding
	in Ruby?
In-Reply-To: <21a10fe00805042114n571a94cbw92fedbd396571559@mail.gmail.com>
References: <21a10fe00805042114n571a94cbw92fedbd396571559@mail.gmail.com>
Message-ID: <FB2006F0-5FC8-4928-BF8A-592E1F87F514@tjohns.net>

On May 4, 2008, at 9:14 PM, John Beppu wrote:

> - What was your primary language before you started coding in Ruby?

C++ for desktop apps, PHP for web apps.

> - What's your current programming language of choice?


Ruby, of course. :)

Second choice would be Objective-C.

-- 
Trevor Johns
http://tjohns.net


From kprojection at gmail.com  Mon May  5 02:33:48 2008
From: kprojection at gmail.com (Eric Mill)
Date: Mon, 5 May 2008 02:33:48 -0400
Subject: [poll] What was your primary language before you started coding
	in Ruby?
In-Reply-To: <FB2006F0-5FC8-4928-BF8A-592E1F87F514@tjohns.net>
References: <21a10fe00805042114n571a94cbw92fedbd396571559@mail.gmail.com>
	<FB2006F0-5FC8-4928-BF8A-592E1F87F514@tjohns.net>
Message-ID: <c658be6b0805042333j442b521ck80982b87f764dd21@mail.gmail.com>

PHP, mostly.  Some Perl, and some Java (but not since college), but
yeah, mostly PHP.  I'm better off now.

-- Eric

On Mon, May 5, 2008 at 2:13 AM, Trevor Johns <trevor at tjohns.net> wrote:
> On May 4, 2008, at 9:14 PM, John Beppu wrote:
>
>
> > - What was your primary language before you started coding in Ruby?
> >
>
>  C++ for desktop apps, PHP for web apps.
>
>
>
> > - What's your current programming language of choice?
> >
>
>
>  Ruby, of course. :)
>
>  Second choice would be Objective-C.
>
>  --
>  Trevor Johns
>  http://tjohns.net
>
>
>
>  _______________________________________________
>  Camping-list mailing list
>  Camping-list at rubyforge.org
>  http://rubyforge.org/mailman/listinfo/camping-list
>

From anibalrojas at gmail.com  Mon May  5 09:20:28 2008
From: anibalrojas at gmail.com (=?ISO-8859-1?Q?An=EDbal_Rojas?=)
Date: Tue, 6 May 2008 08:50:28 +1930
Subject: [poll] What was your primary language before you started coding
	in Ruby?
In-Reply-To: <21a10fe00805042114n571a94cbw92fedbd396571559@mail.gmail.com>
References: <21a10fe00805042114n571a94cbw92fedbd396571559@mail.gmail.com>
Message-ID: <dd83951f0805050620l742857fdn9ef004a30e17a922@mail.gmail.com>

Java (J2EE)

-- 
An?bal

On Mon, May 5, 2008 at 11:44 PM, John Beppu <john.beppu at gmail.com> wrote:
> This is an informal poll.
>
> If you are primarily a Ruby programmer,
> - What was your primary language before you started coding in Ruby?
> Else,
> - What's your current programming language of choice?
>
>
>
> I'll start:
>
> Perl
>
>
>
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
>

From peterretief at gmail.com  Mon May  5 09:55:19 2008
From: peterretief at gmail.com (peter retief)
Date: Mon, 5 May 2008 15:55:19 +0200
Subject: [poll] What was your primary language before you started coding
	in Ruby?
In-Reply-To: <c658be6b0805042333j442b521ck80982b87f764dd21@mail.gmail.com>
References: <21a10fe00805042114n571a94cbw92fedbd396571559@mail.gmail.com>
	<FB2006F0-5FC8-4928-BF8A-592E1F87F514@tjohns.net>
	<c658be6b0805042333j442b521ck80982b87f764dd21@mail.gmail.com>
Message-ID: <b85b3f460805050655r4d81dd79rd2be046dfbdd7c82@mail.gmail.com>

Also mostly php :(
Peter

2008/5/5 Eric Mill <kprojection at gmail.com>:

> PHP, mostly.  Some Perl, and some Java (but not since college), but
> yeah, mostly PHP.  I'm better off now.
>
> -- Eric
>
> On Mon, May 5, 2008 at 2:13 AM, Trevor Johns <trevor at tjohns.net> wrote:
> > On May 4, 2008, at 9:14 PM, John Beppu wrote:
> >
> >
> > > - What was your primary language before you started coding in Ruby?
> > >
> >
> >  C++ for desktop apps, PHP for web apps.
> >
> >
> >
> > > - What's your current programming language of choice?
> > >
> >
> >
> >  Ruby, of course. :)
> >
> >  Second choice would be Objective-C.
> >
> >  --
> >  Trevor Johns
> >  http://tjohns.net
> >
> >
> >
> >  _______________________________________________
> >  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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/camping-list/attachments/20080505/a5bff534/attachment-0001.html>

From mark.m.fredrickson at gmail.com  Mon May  5 10:35:52 2008
From: mark.m.fredrickson at gmail.com (Mark Fredrickson)
Date: Mon, 5 May 2008 09:35:52 -0500
Subject: [poll] What was your primary language before you started coding
	in Ruby?
In-Reply-To: <b85b3f460805050655r4d81dd79rd2be046dfbdd7c82@mail.gmail.com>
References: <21a10fe00805042114n571a94cbw92fedbd396571559@mail.gmail.com>
	<FB2006F0-5FC8-4928-BF8A-592E1F87F514@tjohns.net>
	<c658be6b0805042333j442b521ck80982b87f764dd21@mail.gmail.com>
	<b85b3f460805050655r4d81dd79rd2be046dfbdd7c82@mail.gmail.com>
Message-ID: <1D1F97DB-E2A5-4807-8373-0AC88D9F630C@gmail.com>

> Also mostly php :(

I feel your pain. I was there a few months ago. Professionally, I do  
1/2 Ruby, 1/2 JavaScript ATM. Learning Ruby pushed me to look at Lisp,  
and I've settled into Scheme as my main hobby and exploration tool  
these days. Ruby does borrow heavily from the Lisp tradition, and it  
has been fun to see Lispisms in Ruby's syntax and idiomatic style.  
They are more alike than different.

Cheers,
-Mark






From aredridel at nbtsc.org  Mon May  5 12:15:47 2008
From: aredridel at nbtsc.org (Aria Stewart)
Date: Mon, 5 May 2008 10:15:47 -0600
Subject: [poll] What was your primary language before you started coding
	in Ruby?
In-Reply-To: <21a10fe00805042114n571a94cbw92fedbd396571559@mail.gmail.com>
References: <21a10fe00805042114n571a94cbw92fedbd396571559@mail.gmail.com>
Message-ID: <33DC1EE8-1048-4951-8CF0-340DCD1CEB3F@nbtsc.org>


On May 4, 2008, at 10:14 PM, John Beppu wrote:

> This is an informal poll.
>
> If you are primarily a Ruby programmer,
> - What was your primary language before you started coding in Ruby?
> Else,
> - What's your current programming language of choice?


Perl, PHP, ObjectiveC, depending on task.

From chneukirchen at gmail.com  Wed May  7 07:46:07 2008
From: chneukirchen at gmail.com (Christian Neukirchen)
Date: Wed, 07 May 2008 13:46:07 +0200
Subject: [poll] What was your primary language before you started coding
	in Ruby?
In-Reply-To: <21a10fe00805042114n571a94cbw92fedbd396571559@mail.gmail.com>
	(John Beppu's message of "Sun\, 4 May 2008 21\:14\:20 -0700")
References: <21a10fe00805042114n571a94cbw92fedbd396571559@mail.gmail.com>
Message-ID: <m2wsm6xrpc.fsf@gmail.com>

"John Beppu" <john.beppu at gmail.com> writes:

> This is an informal poll.
>
> If you are primarily a Ruby programmer,
> - What was your primary language before you started coding in Ruby?
> Else,
> - What's your current programming language of choice?
>
>
>
> I'll start:
>
> Perl

awk, perl, C

-- 
Christian Neukirchen  <chneukirchen at gmail.com>  http://chneukirchen.org

From gregoire.lejeune at gmail.com  Wed May  7 08:18:03 2008
From: gregoire.lejeune at gmail.com (Gregoire LEJEUNE)
Date: Wed, 7 May 2008 14:18:03 +0200
Subject: [poll] What was your primary language before you started coding
	in Ruby?
In-Reply-To: <m2wsm6xrpc.fsf@gmail.com>
References: <21a10fe00805042114n571a94cbw92fedbd396571559@mail.gmail.com>
	<m2wsm6xrpc.fsf@gmail.com>
Message-ID: <1cf700d50805070518v7e67a1ebt6f68ddd823b52d3d@mail.gmail.com>

French, English, Spanish ;)

2008/5/7 Christian Neukirchen <chneukirchen at gmail.com>:
>
> "John Beppu" <john.beppu at gmail.com> writes:
>
>  > This is an informal poll.
>  >
>  > If you are primarily a Ruby programmer,
>  > - What was your primary language before you started coding in Ruby?
>  > Else,
>  > - What's your current programming language of choice?
>  >
>  >
>  >
>  > I'll start:
>  >
>  > Perl
>
>  awk, perl, C
>
>  --
>  Christian Neukirchen  <chneukirchen at gmail.com>  http://chneukirchen.org
>
>
> _______________________________________________
>  Camping-list mailing list
>  Camping-list at rubyforge.org
>  http://rubyforge.org/mailman/listinfo/camping-list
>

From joshua.schairbaum at gmail.com  Wed May  7 08:35:29 2008
From: joshua.schairbaum at gmail.com (Joshua Schairbaum)
Date: Wed, 7 May 2008 08:35:29 -0400
Subject: [poll] What was your primary language before you started coding
	in Ruby?
In-Reply-To: <1cf700d50805070518v7e67a1ebt6f68ddd823b52d3d@mail.gmail.com>
References: <21a10fe00805042114n571a94cbw92fedbd396571559@mail.gmail.com>
	<m2wsm6xrpc.fsf@gmail.com>
	<1cf700d50805070518v7e67a1ebt6f68ddd823b52d3d@mail.gmail.com>
Message-ID: <AA071540-E560-4654-89C3-0464142D651D@gmail.com>

This might seem shocking, but Ruby was the first language I ever  
learned, so I've never known anything different.  :)


On May 7, 2008, at 8:18 AM, Gregoire LEJEUNE wrote:

> French, English, Spanish ;)
>
> 2008/5/7 Christian Neukirchen <chneukirchen at gmail.com>:
>>
>> "John Beppu" <john.beppu at gmail.com> writes:
>>
>>> This is an informal poll.
>>>
>>> If you are primarily a Ruby programmer,
>>> - What was your primary language before you started coding in Ruby?
>>> Else,
>>> - What's your current programming language of choice?
>>>
>>>
>>>
>>> I'll start:
>>>
>>> Perl
>>
>> awk, perl, C
>>
>> --
>> Christian Neukirchen  <chneukirchen at gmail.com>  http://chneukirchen.org
>>
>>
>> _______________________________________________
>> 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 jtmitchum at gmail.com  Wed May  7 09:31:45 2008
From: jtmitchum at gmail.com (James Mitchum)
Date: Wed, 7 May 2008 08:31:45 -0500
Subject: [poll] What was your primary language before you started coding
	in Ruby?
In-Reply-To: <AA071540-E560-4654-89C3-0464142D651D@gmail.com>
References: <21a10fe00805042114n571a94cbw92fedbd396571559@mail.gmail.com>
	<m2wsm6xrpc.fsf@gmail.com>
	<1cf700d50805070518v7e67a1ebt6f68ddd823b52d3d@mail.gmail.com>
	<AA071540-E560-4654-89C3-0464142D651D@gmail.com>
Message-ID: <456669B9-AEAA-4AED-AFCA-0B75004370F8@gmail.com>

Same here - Ruby is my first and still favorite language. I'd hardly  
count my time with PHP as meaningful - so Ruby it is.
On May 7, 2008, at 7:35 AM, Joshua Schairbaum wrote:

> This might seem shocking, but Ruby was the first language I ever  
> learned, so I've never known anything different.  :)
>
>
> On May 7, 2008, at 8:18 AM, Gregoire LEJEUNE wrote:
>
>> French, English, Spanish ;)
>>
>> 2008/5/7 Christian Neukirchen <chneukirchen at gmail.com>:
>>>
>>> "John Beppu" <john.beppu at gmail.com> writes:
>>>
>>>> This is an informal poll.
>>>>
>>>> If you are primarily a Ruby programmer,
>>>> - What was your primary language before you started coding in Ruby?
>>>> Else,
>>>> - What's your current programming language of choice?
>>>>
>>>>
>>>>
>>>> I'll start:
>>>>
>>>> Perl
>>>
>>> awk, perl, C
>>>
>>> --
>>> Christian Neukirchen  <chneukirchen at gmail.com>  http://chneukirchen.org
>>>
>>>
>>> _______________________________________________
>>> 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 john.beppu at gmail.com  Wed May  7 15:56:18 2008
From: john.beppu at gmail.com (John Beppu)
Date: Wed, 7 May 2008 12:56:18 -0700
Subject: [poll] What was your primary language before you started coding
	in Ruby?
In-Reply-To: <1cf700d50805070518v7e67a1ebt6f68ddd823b52d3d@mail.gmail.com>
References: <21a10fe00805042114n571a94cbw92fedbd396571559@mail.gmail.com>
	<m2wsm6xrpc.fsf@gmail.com>
	<1cf700d50805070518v7e67a1ebt6f68ddd823b52d3d@mail.gmail.com>
Message-ID: <21a10fe00805071256g5dadbc78w856001990be80891@mail.gmail.com>

Ah, a memetic hacker.  ;-)

On Wed, May 7, 2008 at 5:18 AM, Gregoire LEJEUNE <gregoire.lejeune at gmail.com>
wrote:

> French, English, Spanish ;)
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/camping-list/attachments/20080507/7b67d196/attachment.html>

From somekool at gmail.com  Wed May  7 16:00:03 2008
From: somekool at gmail.com (Mathieu Jobin)
Date: Wed, 7 May 2008 16:00:03 -0400
Subject: [poll] What was your primary language before you started coding
	in Ruby?
In-Reply-To: <21a10fe00805071256g5dadbc78w856001990be80891@mail.gmail.com>
References: <21a10fe00805042114n571a94cbw92fedbd396571559@mail.gmail.com>
	<m2wsm6xrpc.fsf@gmail.com>
	<1cf700d50805070518v7e67a1ebt6f68ddd823b52d3d@mail.gmail.com>
	<21a10fe00805071256g5dadbc78w856001990be80891@mail.gmail.com>
Message-ID: <78181ce60805071300o7d1ec64dsb6eb16d713865379@mail.gmail.com>

C++, PHP or Bash depending on the purpose

French, English and Japanese for my other relations with non-binary
flesh and nerves made unmanageable systems.

2008/5/7 John Beppu <john.beppu at gmail.com>:
> Ah, a memetic hacker.  ;-)
>
> On Wed, May 7, 2008 at 5:18 AM, Gregoire LEJEUNE
> <gregoire.lejeune at gmail.com> wrote:
> > French, English, Spanish ;)
> >
> >
>
>
> _______________________________________________
>  Camping-list mailing list
>  Camping-list at rubyforge.org
>  http://rubyforge.org/mailman/listinfo/camping-list
>



-- 
the obvious is the prejudice.

From ironald at gmail.com  Thu May  8 10:58:18 2008
From: ironald at gmail.com (Ronald Evangelista)
Date: Thu, 8 May 2008 22:58:18 +0800
Subject: query strings built by R method can't handle multiple values from
	checkbox selections
Message-ID: <d344c820805080758n579797c6kc63db6a10319e95@mail.gmail.com>

query strings built by R method can't handle multiple values from checkbox
selections

R(SomeRoute, :reply_status=>%w{1 2 4})
should return
query_string="
http://localhost:3301/someroute/?reply_status_id=1&reply_status_id=2&reply_status_id=4
"

qsp(query_string) -> {"reply_status_id"=>["1", "2", "4"]}


from camping_unabridged.rb
    def R(c,*g)
      p,h=/\(.+?\)/,g.grep(Hash)
      g-=h
      raise "bad route" unless u = c.urls.find{|x|
        break x if x.scan(p).size == g.size &&
          /^#{x}\/?$/ =~ (x=g.inject(x){|x,a|
            x.sub p,C.escape((a[a.class.primary_key]rescue a))})
      }
      h.any?? u+"?"+h[0].map{|x|x.map{|z|C.escape z}*"="}*"&": u
    end

----
i think it would work if modified as:

    h[0].map{|x|
        k, v=x
        if v.is_a?Array
            v.map{|v2| [C.escape( k), C.escape( v2)]*"="} * "&"
        else
            x.map{|z| C.escape z}*"="
        end
    }*"&"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/camping-list/attachments/20080508/7147a02a/attachment-0001.html>

From john.beppu at gmail.com  Thu May  8 20:04:08 2008
From: john.beppu at gmail.com (John Beppu)
Date: Thu, 8 May 2008 17:04:08 -0700
Subject: query strings built by R method can't handle multiple values from
	checkbox selections
In-Reply-To: <d344c820805080758n579797c6kc63db6a10319e95@mail.gmail.com>
References: <d344c820805080758n579797c6kc63db6a10319e95@mail.gmail.com>
Message-ID: <21a10fe00805081704r3deed59x835cb6de6736472@mail.gmail.com>

As an side, I'm writing a Camping-like framework in Perl, and R() is still
on my to-do list.

I'm glad you posted this, because I probably would've ended up duplicating
that bug in my translation to Perl.

--beppu

On Thu, May 8, 2008 at 7:58 AM, Ronald Evangelista <ironald at gmail.com>
wrote:

> query strings built by R method can't handle multiple values from checkbox
> selections
>
> R(SomeRoute, :reply_status=>%w{1 2 4})
> should return
> query_string="
> http://localhost:3301/someroute/?reply_status_id=1&reply_status_id=2&reply_status_id=4
> "
>
> qsp(query_string) -> {"reply_status_id"=>["1", "2", "4"]}
>
>
> from camping_unabridged.rb
>     def R(c,*g)
>       p,h=/\(.+?\)/,g.grep(Hash)
>       g-=h
>       raise "bad route" unless u = c.urls.find{|x|
>         break x if x.scan(p).size == g.size &&
>           /^#{x}\/?$/ =~ (x=g.inject(x){|x,a|
>             x.sub p,C.escape((a[a.class.primary_key]rescue a))})
>       }
>       h.any?? u+"?"+h[0].map{|x|x.map{|z|C.escape z}*"="}*"&": u
>     end
>
> ----
> i think it would work if modified as:
>
>     h[0].map{|x|
>         k, v=x
>         if v.is_a?Array
>             v.map{|v2| [C.escape( k), C.escape( v2)]*"="} * "&"
>         else
>             x.map{|z| C.escape z}*"="
>         end
>     }*"&"
>
>
>
> _______________________________________________
> 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/20080508/f3653fe4/attachment.html>

From trevor at tjohns.net  Sat May 10 08:21:39 2008
From: trevor at tjohns.net (Trevor Johns)
Date: Sat, 10 May 2008 05:21:39 -0700
Subject: Camping-Omnibus Doesn't Work With Ruby v1.8.6
Message-ID: <48D6183F-1EB8-44AC-B806-12B923BFE312@tjohns.net>

I've noticed that the copy of Mongrel installed by the camping-omnibus  
gem doesn't work with Ruby 1.8.6. Or to be more specific,  
cgi_multipart_eof_fix (which Mongrel is dependent upon) doesn't work:

> $ sudo gem install mongrel --source http://code.whytheluckystiff.net
>
> ERROR:  Error installing mongrel:
> 	cgi_multipart_eof_fix requires Ruby version <= 1.8.5

It looks like the copy of Mongrel mirrored on  
code.whytheluckystiff.net is v1.0.1. The latest public release is  
v1.1.4.

Working around this is easy (just download the component parts  
individually from gems.rubyforge.org), but it might scare away some  
newbies who are following the directions on the wiki. Time to update  
the Gems hosted on code.whytheluckystiff.net?

On a related note, how come camping-omnibus doesn't exist on  
gems.rubyforge.org?

-- 
Trevor Johns
http://tjohns.net


From john.beppu at gmail.com  Wed May 14 23:27:25 2008
From: john.beppu at gmail.com (John Beppu)
Date: Wed, 14 May 2008 20:27:25 -0700
Subject: Squatting
Message-ID: <21a10fe00805142027w5ed2f08ax2637140dc7ee3eea@mail.gmail.com>

Hey Campers,

I liked Camping so much that I had to "port" it to Perl.  My framework is
called Squatting (as in http://en.wikipedia.org/wiki/Squatting), and you can
get it from the following places:

http://search.cpan.org/dist/Squatting/

http://github.com/beppu/squatting/tree/master

It's not a straight port of the Camping code, because Camping uses some
weird Ruby idioms that don't translate well to Perl.  However, I tried to
make the API retain the feel of Camping as best as I could under the
circumstances.

With that said, I did make a few significant deviations from Camping that
some of you may find interesting.

   - I used Continuity (http://continuity.tlt42.org/) as my foundation.
   This gives me the ability to implement RESTless controllers which will come
   in handy when I want to start playing with COMET.
   - I let multiple views coexist.  (Let's say you wanted to make a mobile
   version of your site.  I'd like to treat that as a separate view that uses
   the same controllers.)
   - Instead of defining your controllers as classes that inherit from
   whatever it is that R returns, you define your controllers as objects.  (I'm
   doing poor man's prototype-based OO as you'll see if you dig into the code.)
   - Similarly, views are objects, too.

(All the JavaScript I've been writing has clearly warped my mind.  I'm like,
"Screw classes!".  That was my attitude in college, too...  which is
probably why I didn't graduate, but I digress.)

Anyway, take a look, and amuse yourself.

--beppu

Disclaimer:  This is alpha level code, so don't be surprised if the API
mutates a little.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/camping-list/attachments/20080514/a4de0cf4/attachment.html>

From zimbatm at oree.ch  Thu May 15 05:24:41 2008
From: zimbatm at oree.ch (zimbatm)
Date: Thu, 15 May 2008 11:24:41 +0200
Subject: Squatting
In-Reply-To: <21a10fe00805142027w5ed2f08ax2637140dc7ee3eea@mail.gmail.com>
References: <21a10fe00805142027w5ed2f08ax2637140dc7ee3eea@mail.gmail.com>
Message-ID: <e3caf1460805150224g4304271cma1023d8f61bb0fb9@mail.gmail.com>

Haha, well done :)

Small rectification: Camping also allows multiple views per controller

2008/5/15 John Beppu <john.beppu at gmail.com>:
> Hey Campers,
>
> I liked Camping so much that I had to "port" it to Perl.  My framework is
> called Squatting (as in http://en.wikipedia.org/wiki/Squatting), and you can
> get it from the following places:
>
> http://search.cpan.org/dist/Squatting/
>
> http://github.com/beppu/squatting/tree/master
>
> It's not a straight port of the Camping code, because Camping uses some
> weird Ruby idioms that don't translate well to Perl.  However, I tried to
> make the API retain the feel of Camping as best as I could under the
> circumstances.
>
> With that said, I did make a few significant deviations from Camping that
> some of you may find interesting.
>
> I used Continuity (http://continuity.tlt42.org/) as my foundation.  This
> gives me the ability to implement RESTless controllers which will come in
> handy when I want to start playing with COMET.
> I let multiple views coexist.  (Let's say you wanted to make a mobile
> version of your site.  I'd like to treat that as a separate view that uses
> the same controllers.)
> Instead of defining your controllers as classes that inherit from whatever
> it is that R returns, you define your controllers as objects.  (I'm doing
> poor man's prototype-based OO as you'll see if you dig into the code.)
> Similarly, views are objects, too.
>
> (All the JavaScript I've been writing has clearly warped my mind.  I'm like,
> "Screw classes!".  That was my attitude in college, too...  which is
> probably why I didn't graduate, but I digress.)
>
> Anyway, take a look, and amuse yourself.
>
> --beppu
>
> Disclaimer:  This is alpha level code, so don't be surprised if the API
> mutates a little.
>
>
>
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
>

From john.beppu at gmail.com  Thu May 15 20:44:43 2008
From: john.beppu at gmail.com (John Beppu)
Date: Thu, 15 May 2008 17:44:43 -0700
Subject: Squatting
In-Reply-To: <e3caf1460805150224g4304271cma1023d8f61bb0fb9@mail.gmail.com>
References: <21a10fe00805142027w5ed2f08ax2637140dc7ee3eea@mail.gmail.com>
	<e3caf1460805150224g4304271cma1023d8f61bb0fb9@mail.gmail.com>
Message-ID: <21a10fe00805151744y28061fe3r1230404beaca2f8@mail.gmail.com>

On 5/15/08, zimbatm <zimbatm at oree.ch> wrote:
>
> Haha, well done :)
>
> Small rectification: Camping also allows multiple views per controller



Really?  How do you set up multiple views for a Camping app?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/camping-list/attachments/20080515/8af1500b/attachment.html>

From zimbatm at oree.ch  Fri May 16 05:05:53 2008
From: zimbatm at oree.ch (zimbatm)
Date: Fri, 16 May 2008 11:05:53 +0200
Subject: Squatting
In-Reply-To: <21a10fe00805151744y28061fe3r1230404beaca2f8@mail.gmail.com>
References: <21a10fe00805142027w5ed2f08ax2637140dc7ee3eea@mail.gmail.com>
	<e3caf1460805150224g4304271cma1023d8f61bb0fb9@mail.gmail.com>
	<21a10fe00805151744y28061fe3r1230404beaca2f8@mail.gmail.com>
Message-ID: <e3caf1460805160205i4741ba58sf7448e1201d6a50a@mail.gmail.com>

module MyApp
  module Controllers
    class Index < R '/', '/(.*)'
      def get(opts = nil)
        @opts = opts
        render( opts ? :opts : :index )
      end
    end
  end

  module Views
    def index
      h1 "Regular"
    end

    def opts
      h1 "Opts"
      p @opts
    end
  end
end

From blueberry at creativepony.com  Sat May 17 03:10:02 2008
From: blueberry at creativepony.com (Bluebie, Jenna)
Date: Sat, 17 May 2008 17:10:02 +1000
Subject: Setting cookies in service overloader thingo
Message-ID: <AF5B3781-74A0-4D9F-B404-8179756FB6EB@creativepony.com>

I'm implementing a simpler version of the Cookie Session Store in  
Rails 2.0. If you know what that is, skip the next paragraph.

A cookie session store stores the session data inside cookies, on the  
client, and signs them using a secret string, hashed together. The  
user can decode the cookie easily if they know much about computers  
and see what's inside, but they can't alter it because they can't  
generate the needed hash to sign it, and the server will ignore all  
cookie session data that isn't signed right. It's neat, you don't need  
a database, no file system clutter, and I think it feels really just a  
lot more natural this way.

Trouble is, I'm trying to make it work as a drop in replacement for  
the camping sessions mixin so people can 'upgrade' in either direction  
easily, consider this code however...

>     def service(*a)
>       if @cookies.identity
>         blob, secure_hash = @cookies.identity.to_s.split(':')
>         blob = Base64.decode64(blob)
>         data = Marshal.restore(blob)
>         data = {} unless secure_blob_hasher(blob) == secure_hash
>       else
>         blob = ''
>         data = {}
>       end
>
>       app = self.class.name.gsub(/^(\w+)::.+$/, '\1')
>       @state = (data[app] ||= Camping::H[])
>       hash_before = blob.hash
>       return super(*a)
>     ensure
>       if data
>         data[app] = @state
>         blob = Marshal.dump(data)
>         unless hash_before == blob.hash
>           secure_hash = secure_blob_hasher(blob)
>           @cookies.identity = Base64.encode64(blob).strip + ':' +  
> secure_hash
>         end
>       end
>     end

and there's quite a problem, check out that line, return super(*a),  
and look at the camping source, and soon enough one realises the  
reason this doesn't work at all is that the code inside the super is  
the code converting @cookies in to the Set-Cookie http header, so it's  
too late to set a cookie by the time the ensure block runs and tries  
to save the session.

What should I do? It feels dirty to copy code out of camping.rb that  
serializes the cookies, in effect making it do that twice every time  
the session data and any other cookie data changes (which wouldn't be  
a big deal for my app, but still seems nasty). Anyone got a better idea?


?
Jenna ?Where's my oats? Fox
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/camping-list/attachments/20080517/ff1d77d5/attachment-0001.html>

From blueberry at creativepony.com  Sat May 17 02:35:38 2008
From: blueberry at creativepony.com (Bluebie, Jenna)
Date: Sat, 17 May 2008 16:35:38 +1000
Subject: Setting cookies in service overloader thingo
Message-ID: <0F827756-468C-437E-9C0D-10A9946D2025@creativepony.com>

I'm implementing a simpler version of the Cookie Session Store in  
Rails 2.0. If you know what that is, skip the next paragraph.

A cookie session store stores the session data inside cookies, on the  
client, and signs them using a secret string, hashed together. The  
user can decode the cookie easily if they know much about computers  
and see what's inside, but they can't alter it because they can't  
generate the needed hash to sign it, and the server will ignore all  
cookie session data that isn't signed right. It's neat, you don't need  
a database, no file system clutter, and I think it feels really just a  
lot more natural this way.

Trouble is, I'm trying to make it work as a drop in replacement for  
the camping sessions mixin so people can 'upgrade' in either direction  
easily, consider this code however...

>     def service(*a)
>       if @cookies.identity
>         blob, secure_hash = @cookies.identity.to_s.split(':')
>         blob = Base64.decode64(blob)
>         data = Marshal.restore(blob)
>         data = {} unless secure_blob_hasher(blob) == secure_hash
>       else
>         blob = ''
>         data = {}
>       end
>
>       app = self.class.name.gsub(/^(\w+)::.+$/, '\1')
>       @state = (data[app] ||= Camping::H[])
>       hash_before = blob.hash
>       return super(*a)
>     ensure
>       if data
>         data[app] = @state
>         blob = Marshal.dump(data)
>         unless hash_before == blob.hash
>           secure_hash = secure_blob_hasher(blob)
>           @cookies.identity = Base64.encode64(blob).strip + ':' +  
> secure_hash
>         end
>       end
>     end

and there's quite a problem, check out that line, return super(*a),  
and look at the camping source, and soon enough one realises the  
reason this doesn't work at all is that the code inside the super is  
the code converting @cookies in to the Set-Cookie http header, so it's  
too late to set a cookie by the time the ensure block runs and tries  
to save the session.

What should I do? It feels dirty to copy code out of camping.rb that  
serializes the cookies, in effect making it do that job twice every  
time the session data and any other cookie data changes (which  
wouldn't be a big deal for my app, but still seems nasty). Anyone got  
a better idea?


?
Jenna ?Where's my oats? Fox
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/camping-list/attachments/20080517/77520531/attachment.html>

From zimbatm at oree.ch  Sat May 17 12:40:53 2008
From: zimbatm at oree.ch (zimbatm)
Date: Sat, 17 May 2008 18:40:53 +0200
Subject: Camping-Omnibus Doesn't Work With Ruby v1.8.6
In-Reply-To: <48D6183F-1EB8-44AC-B806-12B923BFE312@tjohns.net>
References: <48D6183F-1EB8-44AC-B806-12B923BFE312@tjohns.net>
Message-ID: <e3caf1460805170940r389e9da3t87fd336a5db0d364@mail.gmail.com>

Ok noted, it should probably be fixed once camping is released on rubyforge

2008/5/10 Trevor Johns <trevor at tjohns.net>:
> I've noticed that the copy of Mongrel installed by the camping-omnibus gem
> doesn't work with Ruby 1.8.6. Or to be more specific, cgi_multipart_eof_fix
> (which Mongrel is dependent upon) doesn't work:
>
>> $ sudo gem install mongrel --source http://code.whytheluckystiff.net
>>
>> ERROR:  Error installing mongrel:
>>        cgi_multipart_eof_fix requires Ruby version <= 1.8.5
>
> It looks like the copy of Mongrel mirrored on code.whytheluckystiff.net is
> v1.0.1. The latest public release is v1.1.4.
>
> Working around this is easy (just download the component parts individually
> from gems.rubyforge.org), but it might scare away some newbies who are
> following the directions on the wiki. Time to update the Gems hosted on
> code.whytheluckystiff.net?
>
> On a related note, how come camping-omnibus doesn't exist on
> gems.rubyforge.org?
>
> --
> Trevor Johns
> http://tjohns.net
>
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
>

From zimbatm at oree.ch  Sat May 17 12:41:46 2008
From: zimbatm at oree.ch (zimbatm)
Date: Sat, 17 May 2008 18:41:46 +0200
Subject: Setting cookies in service overloader thingo
In-Reply-To: <0F827756-468C-437E-9C0D-10A9946D2025@creativepony.com>
References: <0F827756-468C-437E-9C0D-10A9946D2025@creativepony.com>
Message-ID: <e3caf1460805170941m53fc1633odb92bdb38ea5e82f@mail.gmail.com>

Nice catch,

cookies support never really felt complete to me. Maybe we should put
it in a different module ?

Cheers,
  zimbatm

From blueberry at creativepony.com  Sat May 17 18:10:03 2008
From: blueberry at creativepony.com (Bluebie, Jenna)
Date: Sun, 18 May 2008 08:10:03 +1000
Subject: Setting cookies in service overloader thingo
In-Reply-To: <e3caf1460805170941m53fc1633odb92bdb38ea5e82f@mail.gmail.com>
References: <0F827756-468C-437E-9C0D-10A9946D2025@creativepony.com>
	<e3caf1460805170941m53fc1633odb92bdb38ea5e82f@mail.gmail.com>
Message-ID: <89AB2A46-722D-4480-8FDD-4C3F6DD8D886@creativepony.com>

I haven't read through all of camping yet, I only started playing with  
it seriously a few days ago, so I don't know where might be a better  
place for it. Maybe whatever it is which calls service could do the  
cookies.

it would be nice if there was a way to set cookies long term too,  
though it isn't really important and for my app, the only place I'd be  
using it is to duplicate the form filling out functionality for my  
openid login box that all modern browser's already provide.

It is really refreshing for cookies to be so simple. I have very mixed  
feelings about making them 'complete'.

If more complete cookie support were added, that would surely include  
the setting of expiry, this opens up another big change in that many  
apps set the same cookie over and over even though nothing has changed  
because they want the expiry to always be, for example, one week after  
the last page the user loaded. The framework currently doesn't make  
allowances for setting the same cookie over and over when no data has  
changed either.

Maybe it's best to stick with simple cookie support. If people really  
need much more I don't feel it unfair for them to need to hack it in  
themselves or move up to rails and the likes.

?
Jenna ?Where's my equestrian hat?? Fox

On 18/05/2008, at 2:41 AM, zimbatm wrote:

> Nice catch,
>
> cookies support never really felt complete to me. Maybe we should put
> it in a different module ?
>
> Cheers,
>  zimbatm
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list


From blueberry at creativepony.com  Sat May 17 18:18:11 2008
From: blueberry at creativepony.com (Bluebie, Jenna)
Date: Sun, 18 May 2008 08:18:11 +1000
Subject: Camping-Omnibus Doesn't Work With Ruby v1.8.6
In-Reply-To: <e3caf1460805170940r389e9da3t87fd336a5db0d364@mail.gmail.com>
References: <48D6183F-1EB8-44AC-B806-12B923BFE312@tjohns.net>
	<e3caf1460805170940r389e9da3t87fd336a5db0d364@mail.gmail.com>
Message-ID: <7ACBAC35-4088-408C-9DC9-E3C22A15517B@creativepony.com>

Yeah, and because ruby 1.8.6 comes with Mac OS X Leopard, that's  
probably scaring plenty of people (me included!)

?
Jenna ?The Omnibus? Fox
On 18/05/2008, at 2:40 AM, zimbatm wrote:

> Ok noted, it should probably be fixed once camping is released on  
> rubyforge
>
> 2008/5/10 Trevor Johns <trevor at tjohns.net>:
>> I've noticed that the copy of Mongrel installed by the camping- 
>> omnibus gem
>> doesn't work with Ruby 1.8.6. Or to be more specific,  
>> cgi_multipart_eof_fix
>> (which Mongrel is dependent upon) doesn't work:
>>
>>> $ sudo gem install mongrel --source http://code.whytheluckystiff.net
>>>
>>> ERROR:  Error installing mongrel:
>>>       cgi_multipart_eof_fix requires Ruby version <= 1.8.5
>>
>> It looks like the copy of Mongrel mirrored on  
>> code.whytheluckystiff.net is
>> v1.0.1. The latest public release is v1.1.4.
>>
>> Working around this is easy (just download the component parts  
>> individually
>> from gems.rubyforge.org), but it might scare away some newbies who  
>> are
>> following the directions on the wiki. Time to update the Gems  
>> hosted on
>> code.whytheluckystiff.net?
>>
>> On a related note, how come camping-omnibus doesn't exist on
>> gems.rubyforge.org?
>>
>> --
>> Trevor Johns
>> http://tjohns.net
>>
>> _______________________________________________
>> 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 john.beppu at gmail.com  Sun May 18 17:05:41 2008
From: john.beppu at gmail.com (John Beppu)
Date: Sun, 18 May 2008 14:05:41 -0700
Subject: Setting cookies in service overloader thingo
In-Reply-To: <89AB2A46-722D-4480-8FDD-4C3F6DD8D886@creativepony.com>
References: <0F827756-468C-437E-9C0D-10A9946D2025@creativepony.com>
	<e3caf1460805170941m53fc1633odb92bdb38ea5e82f@mail.gmail.com>
	<89AB2A46-722D-4480-8FDD-4C3F6DD8D886@creativepony.com>
Message-ID: <21a10fe00805181405k494c3d9fj60b331b1f097e726@mail.gmail.com>

On Sat, May 17, 2008 at 3:10 PM, Bluebie, Jenna <blueberry at creativepony.com>
wrote:

>
> Maybe it's best to stick with simple cookie support. If people really need
> much more I don't feel it unfair for them to need to hack it in themselves
> or move up to rails and the likes.
>

Move to Rails?  Now that's just crazy talk.  :P

Anyone who wants "complete" cookie support can add a little bit of code to
their Camping app that looks like this:

module Learning::CookieWrapper
  def service(*a)
    @cgi_cookies    = Camping::H.new
    @default_cookie = Camping::H.new.merge({ :path => '/' })
    response = super(*a)
    @cgi_cookies.each do |name, settings|
      c = @default_cookie.merge(settings);
      c.name = name
      cookie = CGI::Cookie.new(c);
      headers['Set-Cookie'].push(cookie.to_s)
    end
    response
  end
end

Then, in your controllers, you can add hashes to @cgi_cookie that will be
used to instantiate CGI::Cookie objects.

*Example Code:*

http://github.com/beppu/learning/commit/c6559d42adaf8624d836ecb8b4f6bfaf53255e47

http://github.com/beppu/learning/tree/master/learning.rb  (lines 35-48, 51)

http://github.com/beppu/learning/tree/master/learning/controllers.rb  (lines
142-150)

*Live Demo:*

http://learning.kicks-ass.org/

Submit a few bits of wisdom, and then go to:

http://learning.kicks-ass.org/env

Look at HTTP_COOKIE to verify that Camping can indeed have "complete" cookie
support w/ just a little bit of extra code.

Alternatively, if you have the Web Developer Toolbar for Firefox, you can
look at [Cookies | View Cookie Information].

--beppu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/camping-list/attachments/20080518/ecbab2d6/attachment-0001.html>

From blueberry at creativepony.com  Sun May 18 19:40:08 2008
From: blueberry at creativepony.com (Bluebie, Jenna)
Date: Mon, 19 May 2008 09:40:08 +1000
Subject: Problem with cookies in CGI mode
Message-ID: <EE7AE441-5A6C-4029-A9E1-9043F93C0AF1@creativepony.com>

So it took me ages to figure out how to get cookies set in my app, and  
here was the problem.

I'm using camping's built in CGI support, and with that you can have  
something like domain.com/blah/app.rb and that will go to your /  
route, which is okay, except that the path the cookies are set with is  
domain.com/blah/app.rb/

So if you try to use that url, none of your cookies get sent back to  
the server, but if you use domain.com/blah/app.rb/ everything works  
fine. Sure would be good if camping implemented a redirect for that  
situation. :)

?
Jenna ?Where's my cookie!? Fox


From blueberry at creativepony.com  Sun May 18 22:22:31 2008
From: blueberry at creativepony.com (Bluebie, Jenna)
Date: Mon, 19 May 2008 12:22:31 +1000
Subject: Error in the source code docs
Message-ID: <569B72F5-8BE5-47AC-8E8E-B9B38BB64F23@creativepony.com>

on like 257 of camping-unabridged.rb:

>     #   "http" + URL("/view/12")   #=> "http://test.ing/blog/view/12"

is wrong, the string should be "http:", or the result will be "http// 
test.ing/blob/view/12"


?
Jenna ?Who Isn't a? Fox

From blueberry at creativepony.com  Sun May 18 23:51:12 2008
From: blueberry at creativepony.com (Bluebie, Jenna)
Date: Mon, 19 May 2008 13:51:12 +1000
Subject: Sample Code, quick simple openid auth
Message-ID: <0107ABCC-B910-414B-A5E8-25E56E818280@creativepony.com>

You'll need to install the 'openid' gem for this, and require it in  
your camping app:

     class Login < R '/login'
       def get
         this_url = 'http:' + URL('/login').to_s
         unless input.finish.to_s == '1'
           # start doing the auth here
           begin
             oid_request = OpenID::Consumer.new(@state,  
nil).begin(input.openid_identity)
             oid_request.return_to_args['finish'] = '1'
             redirect(oid_request.redirect_url('http:' +  
URL('/').to_s, this_url))
           rescue OpenID::DiscoveryFailure
             return 'Couldn\'t find an OpenID at that address, are you  
sure it is one?'
           end
         else
           # finish the auth here
           response = OpenID::Consumer.new(@state,  
nil).complete(input, this_url)
           case response.status
           when OpenID::Consumer::SUCCESS
             @state.identity = response.identity_url.to_s
             return redirect(R(HomeScreen))
           when OpenID::Consumer::FAILURE
             'The OpenID thing doesn\'t think you really are that  
person, they said: ' + response.message
           end
         end
       end
     end

Then just point a form at /login with an input by the name of  
openid_identifier, and you have yourself some auth! It will set  
@state.identity to their OpenID URL. Using this you can auth people  
with existing aol, lifejournal, yahoo accounts, and a lot of littler  
openid provider's too. It could sure use some upgrades in the error  
reporting department, which you could hook up to your own error pages  
or whatever. I'll be using this in an app which doesn't use any  
relational databases, just file system storage. You'll probably want  
to change the 'return redirect(R(HomeScreen))' line near the end to  
some page in your app that logged in user's go to before you take this  
online too. :)

Public Domain.


?
Jenna
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/camping-list/attachments/20080519/79792dc8/attachment.html>

From aredridel at nbtsc.org  Mon May 19 13:33:33 2008
From: aredridel at nbtsc.org (Aria Stewart)
Date: Mon, 19 May 2008 11:33:33 -0600
Subject: Problem with cookies in CGI mode
In-Reply-To: <EE7AE441-5A6C-4029-A9E1-9043F93C0AF1@creativepony.com>
References: <EE7AE441-5A6C-4029-A9E1-9043F93C0AF1@creativepony.com>
Message-ID: <47E631FB-20F7-4363-9949-336F5A9CD59F@nbtsc.org>


On May 18, 2008, at 5:40 PM, Bluebie, Jenna wrote:

> So it took me ages to figure out how to get cookies set in my app,  
> and here was the problem.
>
> I'm using camping's built in CGI support, and with that you can have  
> something like domain.com/blah/app.rb and that will go to your /  
> route, which is okay, except that the path the cookies are set with  
> is domain.com/blah/app.rb/
>
> So if you try to use that url, none of your cookies get sent back to  
> the server, but if you use domain.com/blah/app.rb/ everything works  
> fine. Sure would be good if camping implemented a redirect for that  
> situation. :)



Indeed. The code for that is handler-specific -- there's similar  
issues in FastCGI.

Aria Stewart
aredridel at nbtsc.org




From blueberry at creativepony.com  Tue May 20 00:59:38 2008
From: blueberry at creativepony.com (Bluebie, Jenna)
Date: Tue, 20 May 2008 14:59:38 +1000
Subject: Sample Code, quick simple openid auth
In-Reply-To: <0107ABCC-B910-414B-A5E8-25E56E818280@creativepony.com>
References: <0107ABCC-B910-414B-A5E8-25E56E818280@creativepony.com>
Message-ID: <AD3A4F85-D2F2-4660-B78C-C490D545F1EF@creativepony.com>

Okay, so I cleaned this up a little, made it suck less when using it  
in CGI camping, and put it on the wiki (which should really support  
OpenID! I had to register a RubyForge account and had all problems  
getting the account activated to contribute! Darn you ruby forge!)

So here it is, OpenID on Wiki! http://code.whytheluckystiff.net/camping/wiki/AuthenticatingOpenIDs

Also, check out Cookie Sessions!

http://code.whytheluckystiff.net/camping/wiki/CookieSessions

They're hip, they're new, they're slightly worrying but if you think  
about it secure anyway, and they don't mess up your database or  
filesystem with a bunch of files!


From blueberry at creativepony.com  Tue May 20 01:30:17 2008
From: blueberry at creativepony.com (Bluebie, Jenna)
Date: Tue, 20 May 2008 15:30:17 +1000
Subject: Sample Code, quick simple openid auth
In-Reply-To: <AD3A4F85-D2F2-4660-B78C-C490D545F1EF@creativepony.com>
References: <0107ABCC-B910-414B-A5E8-25E56E818280@creativepony.com>
	<AD3A4F85-D2F2-4660-B78C-C490D545F1EF@creativepony.com>
Message-ID: <E05DED6D-CB2D-499E-8170-52252E2A1DE8@creativepony.com>

Also, here's a simple way to stop XSS dead! http://code.whytheluckystiff.net/camping/wiki/XssBeGoneWithSessions

?
Jenna ?is hoping all this will earn here some oats!? Fox

From judofyr at gmail.com  Tue May 20 04:01:21 2008
From: judofyr at gmail.com (Magnus Holm)
Date: Tue, 20 May 2008 10:01:21 +0200
Subject: Sample Code, quick simple openid auth
In-Reply-To: <E05DED6D-CB2D-499E-8170-52252E2A1DE8@creativepony.com>
References: <0107ABCC-B910-414B-A5E8-25E56E818280@creativepony.com>
	<AD3A4F85-D2F2-4660-B78C-C490D545F1EF@creativepony.com>
	<E05DED6D-CB2D-499E-8170-52252E2A1DE8@creativepony.com>
Message-ID: <391a49da0805200101q6c4a9148uced132b81485584f@mail.gmail.com>

Everyone can read their session, though. I can post an example which
encrypts everything (don't expect it to be super-fast).

On Tue, May 20, 2008 at 7:30 AM, Bluebie, Jenna <blueberry at creativepony.com>
wrote:

> Also, here's a simple way to stop XSS dead!
> http://code.whytheluckystiff.net/camping/wiki/XssBeGoneWithSessions
>
> ?
> Jenna "is hoping all this will earn here some oats!" Fox
>
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
>



-- 
Magnus Holm
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/camping-list/attachments/20080520/acf2bf34/attachment.html>

From blueberry at creativepony.com  Tue May 20 04:09:32 2008
From: blueberry at creativepony.com (Bluebie, Jenna)
Date: Tue, 20 May 2008 18:09:32 +1000
Subject: Sample Code, quick simple openid auth
In-Reply-To: <391a49da0805200101q6c4a9148uced132b81485584f@mail.gmail.com>
References: <0107ABCC-B910-414B-A5E8-25E56E818280@creativepony.com>
	<AD3A4F85-D2F2-4660-B78C-C490D545F1EF@creativepony.com>
	<E05DED6D-CB2D-499E-8170-52252E2A1DE8@creativepony.com>
	<391a49da0805200101q6c4a9148uced132b81485584f@mail.gmail.com>
Message-ID: <1BE8B24B-FF49-4E6C-9DEF-64EA34A512FA@creativepony.com>

Sure, but if you're building an app that keeps secrets about me from  
me, I'd rather not use it, thank you.


On 20/05/2008, at 6:01 PM, Magnus Holm wrote:

> Everyone can read their session, though. I can post an example which  
> encrypts everything (don't expect it to be super-fast).
>
> On Tue, May 20, 2008 at 7:30 AM, Bluebie, Jenna <blueberry at creativepony.com 
> > wrote:
> Also, here's a simple way to stop XSS dead! http://code.whytheluckystiff.net/camping/wiki/XssBeGoneWithSessions
>
> ?
> Jenna "is hoping all this will earn here some oats!" Fox
>
> _______________________________________________
> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/camping-list/attachments/20080520/8e8a5960/attachment-0001.html>

From judofyr at gmail.com  Tue May 20 05:01:32 2008
From: judofyr at gmail.com (Magnus Holm)
Date: Tue, 20 May 2008 11:01:32 +0200
Subject: Sample Code, quick simple openid auth
In-Reply-To: <1BE8B24B-FF49-4E6C-9DEF-64EA34A512FA@creativepony.com>
References: <0107ABCC-B910-414B-A5E8-25E56E818280@creativepony.com>
	<AD3A4F85-D2F2-4660-B78C-C490D545F1EF@creativepony.com>
	<E05DED6D-CB2D-499E-8170-52252E2A1DE8@creativepony.com>
	<391a49da0805200101q6c4a9148uced132b81485584f@mail.gmail.com>
	<1BE8B24B-FF49-4E6C-9DEF-64EA34A512FA@creativepony.com>
Message-ID: <391a49da0805200201v585b6824ud663b3cae02d69ff@mail.gmail.com>

Cookies can be stealt. I'm protecting you against yourself :-P

2008/5/20, Bluebie, Jenna <blueberry at creativepony.com>:
> Sure, but if you're building an app that keeps secrets about me from
> me, I'd rather not use it, thank you.
>
>
> On 20/05/2008, at 6:01 PM, Magnus Holm wrote:
>
>> Everyone can read their session, though. I can post an example which
>> encrypts everything (don't expect it to be super-fast).
>>
>> On Tue, May 20, 2008 at 7:30 AM, Bluebie, Jenna
>> <blueberry at creativepony.com
>> > wrote:
>> Also, here's a simple way to stop XSS dead!
>> http://code.whytheluckystiff.net/camping/wiki/XssBeGoneWithSessions
>>
>> ?
>> Jenna "is hoping all this will earn here some oats!" Fox
>>
>> _______________________________________________
>> 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
>
>


-- 
Magnus Holm

From blueberry at creativepony.com  Tue May 20 09:20:49 2008
From: blueberry at creativepony.com (Bluebie, Jenna)
Date: Tue, 20 May 2008 23:20:49 +1000
Subject: Sample Code, quick simple openid auth
In-Reply-To: <391a49da0805200201v585b6824ud663b3cae02d69ff@mail.gmail.com>
References: <0107ABCC-B910-414B-A5E8-25E56E818280@creativepony.com>
	<AD3A4F85-D2F2-4660-B78C-C490D545F1EF@creativepony.com>
	<E05DED6D-CB2D-499E-8170-52252E2A1DE8@creativepony.com>
	<391a49da0805200101q6c4a9148uced132b81485584f@mail.gmail.com>
	<1BE8B24B-FF49-4E6C-9DEF-64EA34A512FA@creativepony.com>
	<391a49da0805200201v585b6824ud663b3cae02d69ff@mail.gmail.com>
Message-ID: <D9CFDA1E-980A-42A0-87FB-792CA1481263@creativepony.com>

How does encrypting them make any difference against steal-ability?  
Wouldn't putting the IP address of the user be more to the point?  
Though that would lock out many user's from ISP's using proxies.

I'm certainly aware of XSS issues and even posted a simple way of  
blocking them in camping controllers which you'll find 3 replies ago.

Encrypting cookies wont change that issue one bit.


On 20/05/2008, at 7:01 PM, Magnus Holm wrote:

> Cookies can be stealt. I'm protecting you against yourself :-P
>
> 2008/5/20, Bluebie, Jenna <blueberry at creativepony.com>:
>> Sure, but if you're building an app that keeps secrets about me from
>> me, I'd rather not use it, thank you.
>>
>>
>> On 20/05/2008, at 6:01 PM, Magnus Holm wrote:
>>
>>> Everyone can read their session, though. I can post an example which
>>> encrypts everything (don't expect it to be super-fast).
>>>
>>> On Tue, May 20, 2008 at 7:30 AM, Bluebie, Jenna
>>> <blueberry at creativepony.com
>>>> wrote:
>>> Also, here's a simple way to stop XSS dead!
>>> http://code.whytheluckystiff.net/camping/wiki/XssBeGoneWithSessions
>>>
>>> ?
>>> Jenna "is hoping all this will earn here some oats!" Fox
>>>
>>> _______________________________________________
>>> 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
>>
>>
>
>
> -- 
> Magnus Holm
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list


From judofyr at gmail.com  Wed May 21 15:26:52 2008
From: judofyr at gmail.com (Magnus Holm)
Date: Wed, 21 May 2008 21:26:52 +0200
Subject: Rack, Camping 2.0++
Message-ID: <391a49da0805211226y7686f4e8vf5574a308ea0e4fa@mail.gmail.com>

===
1. Camping on Rack
===

I've just finished rewriting Camping to use Rack in the "core". I got rid of
(a little less) than 1kB in camping.rb and removed lots of un-necessary files
(lib/server/*.rb, fastcgi.rb & mongrel.rb).

bin/camping does now only provide WEBrick, Mongrel and console-support and
should only be used in development. It uses Rack::ShowExceptions to catch
error outside the app and I've also written a middleware for faking
X-Sendfile. For production you should create a rackup-file or setup Rack in
some other way:

  #!/usr/bin/env rackup
  # Auto-detects CGI & FastCGI
  # Start mongrel with: ./blog.ru -s mongrel -p 3301
  require 'blog'
  Blog.create
  run Blog

Some notes:
* Branch: http://github.com/judofyr/camping/commits/rack
* You have to rename camping-unabridged.rb to camping.rb in order to run apps.
* You're app is also a Rack-app  (aka respond_to?(:call))
* I'm using Rack::Request (@request) and Rack::Response (@response)
* Status, headers and body must be set using @status, @headers and @body,
  not @response.status, @response.headers or @response.body
* @headers is a Rack::Utils::HeaderHash
* @root, @input and @cookies behaves equally; @env is gone
* You can delete cookies with @response.delete_cookie("key")
* Set cookies with @cookies.key = ":)" or @response.set_cookie("key", ":)")
* You can also pass a Hash when you're setting cookies:
  @cookes.key = {:value => ":)", :expires => Time.now + 3600, :path => '/app'}
* I've removed #qsp, #un and #escape. Use Rack::Utils instead
* This should close #104, #130 and #153

===
2. ORM-agnostic?
===

What about making Camping ORM-agnostic? If it's only AR which requires glue,
we can just rename camping/db.rb to camping/ar.rb - if not we have to add
camping/og.rb, camping/dm.rb, camping/sequel.rb etc too.

===
3. Cookie Sessions as default
===

What do you think about using Cookie Sessions instead of database-based by
default (in camping/sessions.rb)? It's much lighter and makes it simpler to
create apps without database. It also helps making Camping ORM-agnostic.

I've fixed this in the cookie_session-branch (requires Rack) available at
http://github.com/judofyr/camping/commits/cookie_session (highly based on
Jenna's work)

===
4. Renaming camping-unabridged.rb to camping.rb?
===

I haven't touched camping.rb at all, do we really need to prove that it's a
micro-framework? It just makes development/releasing harder. Let's just forget
about the abridged version and rename camping-unabridged.rb to camping.rb!

===
5. Camping 2.0
===

Here's my plan:
* We agree on which of these four/three features we should implement
* _why or zimbatm (or someone who really knows Camping) double-checks
  everything and fixes any bugs.
* Releasing 2.0 - Make lots of hype so everybody ports their apps to 2.0
* Then we'll see if any bugs appear, fixes them quickly and releasing 2.1.

---

This is just some proposals, the community (aka YOU) have to decide what we
should do. So what are your thoughts?

---
Magnus Holm

From ernest.prabhakar at gmail.com  Wed May 21 16:09:00 2008
From: ernest.prabhakar at gmail.com (Ernest Prabhakar)
Date: Wed, 21 May 2008 13:09:00 -0700
Subject: Rack, Camping 2.0++
In-Reply-To: <391a49da0805211226y7686f4e8vf5574a308ea0e4fa@mail.gmail.com>
References: <391a49da0805211226y7686f4e8vf5574a308ea0e4fa@mail.gmail.com>
Message-ID: <38B85734-253F-4F28-849D-A8336874385B@gmail.com>

Hi Magnus,

On May 21, 2008, at 12:26 PM, Magnus Holm wrote:
> This is just some proposals, the community (aka YOU) have to decide  
> what we
> should do. So what are your thoughts?
>
Awesome work!  I say go for it. :-)

-enp



From blueberry at creativepony.com  Wed May 21 19:09:26 2008
From: blueberry at creativepony.com (Bluebie, Jenna)
Date: Thu, 22 May 2008 09:09:26 +1000
Subject: Rack, Camping 2.0++
In-Reply-To: <391a49da0805211226y7686f4e8vf5574a308ea0e4fa@mail.gmail.com>
References: <391a49da0805211226y7686f4e8vf5574a308ea0e4fa@mail.gmail.com>
Message-ID: <1AD57BF2-88CB-4883-9E79-2B1149AFB974@creativepony.com>

If you're going to build cookie sessions in to the core, it should  
either do the rails thing of using multiple cookies when one is not  
enough for the data, or raise a descriptive exception explaining why  
there's a problem and how switching to the database sessions thingo  
will solve that.

I totally agree with ditching the compressed version so long as there  
are new guidelines put in place as to how much camping is too much  
camping. We still need to fit it in our backpacks.

It would also be good if you continue to maintain some easy way to do  
the compression, so people who do care about size can get a smaller  
version. Someone might want to take camping with them everywhere they  
go in the form of a 3D barcode, loadable via the camera's on mobile  
phones and many computers, or maybe they've been running their website  
on a server they can only reach via TCP over Carrier Pigeon and it's  
important to them that they can upload camping.rb with the fewest  
pigeons possible.

Does Rack::Utils give us nice short easy escaping? Can we include in  
to camping in a way that they are just nice short methods?

?
Jenna

On 22/05/2008, at 5:26 AM, Magnus Holm wrote:

> ===
> 1. Camping on Rack
> ===
>
> I've just finished rewriting Camping to use Rack in the "core". I  
> got rid of
> (a little less) than 1kB in camping.rb and removed lots of un- 
> necessary files
> (lib/server/*.rb, fastcgi.rb & mongrel.rb).
>
> bin/camping does now only provide WEBrick, Mongrel and console- 
> support and
> should only be used in development. It uses Rack::ShowExceptions to  
> catch
> error outside the app and I've also written a middleware for faking
> X-Sendfile. For production you should create a rackup-file or setup  
> Rack in
> some other way:
>
>  #!/usr/bin/env rackup
>  # Auto-detects CGI & FastCGI
>  # Start mongrel with: ./blog.ru -s mongrel -p 3301
>  require 'blog'
>  Blog.create
>  run Blog
>
> Some notes:
> * Branch: http://github.com/judofyr/camping/commits/rack
> * You have to rename camping-unabridged.rb to camping.rb in order to  
> run apps.
> * You're app is also a Rack-app  (aka respond_to?(:call))
> * I'm using Rack::Request (@request) and Rack::Response (@response)
> * Status, headers and body must be set using @status, @headers and  
> @body,
>  not @response.status, @response.headers or @response.body
> * @headers is a Rack::Utils::HeaderHash
> * @root, @input and @cookies behaves equally; @env is gone
> * You can delete cookies with @response.delete_cookie("key")
> * Set cookies with @cookies.key = ":)" or  
> @response.set_cookie("key", ":)")
> * You can also pass a Hash when you're setting cookies:
>  @cookes.key = {:value => ":)", :expires => Time.now + 3600, :path  
> => '/app'}
> * I've removed #qsp, #un and #escape. Use Rack::Utils instead
> * This should close #104, #130 and #153
>
> ===
> 2. ORM-agnostic?
> ===
>
> What about making Camping ORM-agnostic? If it's only AR which  
> requires glue,
> we can just rename camping/db.rb to camping/ar.rb - if not we have  
> to add
> camping/og.rb, camping/dm.rb, camping/sequel.rb etc too.
>
> ===
> 3. Cookie Sessions as default
> ===
>
> What do you think about using Cookie Sessions instead of database- 
> based by
> default (in camping/sessions.rb)? It's much lighter and makes it  
> simpler to
> create apps without database. It also helps making Camping ORM- 
> agnostic.
>
> I've fixed this in the cookie_session-branch (requires Rack)  
> available at
> http://github.com/judofyr/camping/commits/cookie_session (highly  
> based on
> Jenna's work)
>
> ===
> 4. Renaming camping-unabridged.rb to camping.rb?
> ===
>
> I haven't touched camping.rb at all, do we really need to prove that  
> it's a
> micro-framework? It just makes development/releasing harder. Let's  
> just forget
> about the abridged version and rename camping-unabridged.rb to  
> camping.rb!
>
> ===
> 5. Camping 2.0
> ===
>
> Here's my plan:
> * We agree on which of these four/three features we should implement
> * _why or zimbatm (or someone who really knows Camping) double-checks
>  everything and fixes any bugs.
> * Releasing 2.0 - Make lots of hype so everybody ports their apps to  
> 2.0
> * Then we'll see if any bugs appear, fixes them quickly and  
> releasing 2.1.
>
> ---
>
> This is just some proposals, the community (aka YOU) have to decide  
> what we
> should do. So what are your thoughts?
>
> ---
> Magnus Holm
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list


From john.beppu at gmail.com  Wed May 21 20:56:53 2008
From: john.beppu at gmail.com (John Beppu)
Date: Wed, 21 May 2008 17:56:53 -0700
Subject: Rack, Camping 2.0++
In-Reply-To: <391a49da0805211226y7686f4e8vf5574a308ea0e4fa@mail.gmail.com>
References: <391a49da0805211226y7686f4e8vf5574a308ea0e4fa@mail.gmail.com>
Message-ID: <21a10fe00805211756m617e4879h8b3631434c2ae0f4@mail.gmail.com>

Impressive work.

On Wed, May 21, 2008 at 12:26 PM, Magnus Holm <judofyr at gmail.com> wrote:

> ===
> 1. Camping on Rack
> ===
>
> I've just finished rewriting Camping to use Rack in the "core". I got rid
> of
> (a little less) than 1kB in camping.rb and removed lots of un-necessary
> files
> (lib/server/*.rb, fastcgi.rb & mongrel.rb).
>
> bin/camping does now only provide WEBrick, Mongrel and console-support and
> should only be used in development. It uses Rack::ShowExceptions to catch
> error outside the app and I've also written a middleware for faking
> X-Sendfile. For production you should create a rackup-file or setup Rack in
> some other way:
>
>  #!/usr/bin/env rackup
>  # Auto-detects CGI & FastCGI
>  # Start mongrel with: ./blog.ru -s mongrel -p 3301
>  require 'blog'
>  Blog.create
>  run Blog
>
> Some notes:
> * Branch: http://github.com/judofyr/camping/commits/rack
> * You have to rename camping-unabridged.rb to camping.rb in order to run
> apps.
> * You're app is also a Rack-app  (aka respond_to?(:call))
> * I'm using Rack::Request (@request) and Rack::Response (@response)
> * Status, headers and body must be set using @status, @headers and @body,
>  not @response.status, @response.headers or @response.body
> * @headers is a Rack::Utils::HeaderHash
> * @root, @input and @cookies behaves equally; @env is gone
> * You can delete cookies with @response.delete_cookie("key")
> * Set cookies with @cookies.key = ":)" or @response.set_cookie("key", ":)")
> * You can also pass a Hash when you're setting cookies:
>  @cookes.key = {:value => ":)", :expires => Time.now + 3600, :path =>
> '/app'}
> * I've removed #qsp, #un and #escape. Use Rack::Utils instead
> * This should close #104, #130 and #153
>

These API changes sound reasonable to me.


>
> ===
> 2. ORM-agnostic?
> ===
>
> What about making Camping ORM-agnostic? If it's only AR which requires
> glue,
> we can just rename camping/db.rb to camping/ar.rb - if not we have to add
> camping/og.rb, camping/dm.rb, camping/sequel.rb etc too.
>

Fine w/ me.


>
> ===
> 3. Cookie Sessions as default
> ===
>
> What do you think about using Cookie Sessions instead of database-based by
> default (in camping/sessions.rb)? It's much lighter and makes it simpler to
> create apps without database. It also helps making Camping ORM-agnostic.
>
> I've fixed this in the cookie_session-branch (requires Rack) available at
> http://github.com/judofyr/camping/commits/cookie_session (highly based on
> Jenna's work)
>

As long as you organize the code such that it's easy to switch between
session storage schemes, I think this is fine.

===
> 4. Renaming camping-unabridged.rb to camping.rb?
> ===
>
> I haven't touched camping.rb at all, do we really need to prove that it's a
> micro-framework? It just makes development/releasing harder. Let's just
> forget
> about the abridged version and rename camping-unabridged.rb to camping.rb!
>

Perlvert that I am, I respected the 4KB obfuscation.  (Maybe that's just
me.  ;-)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/camping-list/attachments/20080521/3606b101/attachment-0001.html>

From why at whytheluckystiff.net  Thu May 22 02:38:39 2008
From: why at whytheluckystiff.net (_why)
Date: Thu, 22 May 2008 01:38:39 -0500
Subject: Rack, Camping 2.0++
In-Reply-To: <391a49da0805211226y7686f4e8vf5574a308ea0e4fa@mail.gmail.com>
References: <391a49da0805211226y7686f4e8vf5574a308ea0e4fa@mail.gmail.com>
Message-ID: <20080522063839.GR70833@beekeeper.hobix.com>

On Wed, May 21, 2008 at 09:26:52PM +0200, Magnus Holm wrote:
> I've just finished rewriting Camping to use Rack in the "core". I got rid of
> (a little less) than 1kB in camping.rb and removed lots of un-necessary files
> (lib/server/*.rb, fastcgi.rb & mongrel.rb).

Splendid!  If we can say Camping, the 3K Microframework, then I
think we will really have a reason to bump the big number.  I'll wait
for a reaction from zimbatm, but I am euphoric about these changes.

_why

From judofyr at gmail.com  Thu May 22 06:32:02 2008
From: judofyr at gmail.com (Magnus Holm)
Date: Thu, 22 May 2008 12:32:02 +0200
Subject: Rack, Camping 2.0++
In-Reply-To: <1AD57BF2-88CB-4883-9E79-2B1149AFB974@creativepony.com>
References: <391a49da0805211226y7686f4e8vf5574a308ea0e4fa@mail.gmail.com>
	<1AD57BF2-88CB-4883-9E79-2B1149AFB974@creativepony.com>
Message-ID: <391a49da0805220332l116702edyb28e4085b4af70ec@mail.gmail.com>

> If you're going to build cookie sessions in to the core, it should either do
> the rails thing of using multiple cookies when one is not enough for the
> data, or raise a descriptive exception explaining why there's a problem and
> how switching to the database sessions thingo will solve that.

Cookie Sessions: I think we should simply raise an error when the data is
larger than 4kB. Something is wrong when the cookie is larger than the
framework you're using.

> I totally agree with ditching the compressed version so long as there are
> new guidelines put in place as to how much camping is too much camping. We
> still need to fit it in our backpacks.
>
> It would also be good if you continue to maintain some easy way to do the
> compression, so people who do care about size can get a smaller version.
> Someone might want to take camping with them everywhere they go in the form
> of a 3D barcode, loadable via the camera's on mobile phones and many
> computers, or maybe they've been running their website on a server they can
> only reach via TCP over Carrier Pigeon and it's important to them that they
> can upload camping.rb with the fewest pigeons possible.

>Perlvert that I am, I respected the 4KB obfuscation.  (Maybe that's just me.  ;-)

It's alright for me to keep the compressed version, but can it live under
camping-compressed.rb (or something like that) and have the "real" version
under camping.rb?

> Does Rack::Utils give us nice short easy escaping? Can we include in to
> camping in a way that they are just nice short methods?

Rack::Utils gives us "nice short easy escaping" through Rack::Utils.escape and
Rack::Utils.unescape. Creating helper-methods will just cost bytes...

> As long as you organize the code such that it's easy to switch between
> session storage schemes, I think this is fine.

I've created a branch (orm_agnostic) where I've moved db.rb -> ar.rb and
session.rb -> ar/session.rb so you can plug in whatever you want.

--
Right now I have spread the code around three branches (rack, cookie_session
and orm_agnostic). Just tell me which we need, and I'll merge/rebase them to
the master for easy merging with why's repo (so you guys can continue to hack
with it).

Oh, and the documentation of session needs some cleanup, but I suck at
documentation so I'll leave it to you :-)
-- 
Magnus Holm

From blueberry at creativepony.com  Thu May 22 07:05:11 2008
From: blueberry at creativepony.com (Bluebie, Jenna)
Date: Thu, 22 May 2008 21:05:11 +1000
Subject: Rack, Camping 2.0++
In-Reply-To: <391a49da0805220332l116702edyb28e4085b4af70ec@mail.gmail.com>
References: <391a49da0805211226y7686f4e8vf5574a308ea0e4fa@mail.gmail.com>
	<1AD57BF2-88CB-4883-9E79-2B1149AFB974@creativepony.com>
	<391a49da0805220332l116702edyb28e4085b4af70ec@mail.gmail.com>
Message-ID: <A02C50D5-B51B-43F6-AC74-BC94218142D0@creativepony.com>

I really think shorter escaping methods are important, see if you  
can't include Rack::Utils or something
Aside from that, it all sounds yummy!


On 22/05/2008, at 8:32 PM, Magnus Holm wrote:

>> If you're going to build cookie sessions in to the core, it should  
>> either do
>> the rails thing of using multiple cookies when one is not enough  
>> for the
>> data, or raise a descriptive exception explaining why there's a  
>> problem and
>> how switching to the database sessions thingo will solve that.
>
> Cookie Sessions: I think we should simply raise an error when the  
> data is
> larger than 4kB. Something is wrong when the cookie is larger than the
> framework you're using.
>
>> I totally agree with ditching
>> the compressed version so long as there are
>> new guidelines put in place as to how much camping is too much  
>> camping. We
>> still need to fit it in our backpacks.
>>
>> It would also be good if you continue to maintain some easy way to  
>> do the
>> compression, so people who do care about size can get a smaller  
>> version.
>> Someone might want to take camping with them everywhere they go in  
>> the form
>> of a 3D barcode, loadable via the camera's on mobile phones and many
>> computers, or maybe they've been running their website on a server  
>> they can
>> only reach via TCP over Carrier Pigeon and it's important to them  
>> that they
>> can upload camping.rb with the fewest pigeons possible.
>
>> Perlvert that I am, I respected the 4KB obfuscation.  (Maybe that's  
>> just me.  ;-)
>
> It's alright for me to keep the compressed version, but can it live  
> under
> camping-compressed.rb (or something like that) and have the "real"  
> version
> under camping.rb?
>
>> Does Rack::Utils give us nice short easy escaping? Can we include  
>> in to
>> camping in a way that they are just nice short methods?
>
> Rack::Utils gives us "nice short easy escaping" through  
> Rack::Utils.escape and
> Rack::Utils.unescape. Creating helper-methods will just cost bytes...
>
>> As long as you organize the code such that it's easy to switch  
>> between
>> session storage schemes, I think this is fine.
>
> I've created a branch (orm_agnostic) where I've moved db.rb -> ar.rb  
> and
> session.rb -> ar/session.rb so you can plug in whatever you want.
>
> --
> Right now I have spread the code around three branches (rack,  
> cookie_session
> and orm_agnostic). Just tell me which we need, and I'll merge/rebase  
> them to
> the master for easy merging with why's repo (so you guys can  
> continue to hack
> with it).
>
> Oh, and the documentation of session needs some cleanup, but I suck at
> documentation so I'll leave it to you :-)
> -- 
> Magnus Holm
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list


From anibalrojas at gmail.com  Thu May 22 07:57:18 2008
From: anibalrojas at gmail.com (=?ISO-8859-1?Q?An=EDbal_Rojas?=)
Date: Fri, 23 May 2008 07:27:18 +1930
Subject: Rack, Camping 2.0++
In-Reply-To: <391a49da0805211226y7686f4e8vf5574a308ea0e4fa@mail.gmail.com>
References: <391a49da0805211226y7686f4e8vf5574a308ea0e4fa@mail.gmail.com>
Message-ID: <dd83951f0805220457r3c8e111fj537f7079b97c5fa0@mail.gmail.com>

Magnus,

On Thu, May 22, 2008 at 2:56 PM, Magnus Holm <judofyr at gmail.com> wrote:
> ===
> 1. Camping on Rack
> ===
>
> I've just finished rewriting Camping to use Rack in the "core". I got rid of
> (a little less) than 1kB in camping.rb and removed lots of un-necessary files
> (lib/server/*.rb, fastcgi.rb & mongrel.rb).

Cool, great work. The changes required by the apps are simple to accomplish.

> ===
> 2. ORM-agnostic?
> ===
>
> What about making Camping ORM-agnostic? If it's only AR which requires glue,
> we can just rename camping/db.rb to camping/ar.rb - if not we have to add
> camping/og.rb, camping/dm.rb, camping/sequel.rb etc too.

Interesting idea, not in the top of my list but I must confess Merb
has bring DataMapper and Sequel to my attention.
Being able to play with them easier in Camping would be interesting.

> ===
> 3. Cookie Sessions as default
> ===
>
> What do you think about using Cookie Sessions instead of database-based by
> default (in camping/sessions.rb)? It's much lighter and makes it simpler to
> create apps without database. It also helps making Camping ORM-agnostic.

We discussed it and tried  with our new Raisl  2 based applications. It works.

> ===
> 4. Renaming camping-unabridged.rb to camping.rb?
> ===
>
> I haven't touched camping.rb at all, do we really need to prove that it's a
> micro-framework? It just makes development/releasing harder. Let's just forget
> about the abridged version and rename camping-unabridged.rb to camping.rb!

Keeping Camping away from the bloat goes far beyond an arbitrary weight limit.
It is a nice way to promote Camping. It is catchy saying "In Less then
4K", period.

In any project keeping unnecessary artifacts is not a good practice,
their maintenance drag resources form the development of the real
working ones.

> ===
> 5. Camping 2.0
> ===
>
> Here's my plan:
> * We agree on which of these four/three features we should implement
> * _why or zimbatm (or someone who really knows Camping) double-checks
>  everything and fixes any bugs.
> * Releasing 2.0 - Make lots of hype so everybody ports their apps to 2.0
> * Then we'll see if any bugs appear, fixes them quickly and releasing 2.1.

Sounds good.

--
An?bal Rojas
http://hasmanydevelopers.com
http://rubycorner.com
http://anibal.rojas.com

> ---
>
> This is just some proposals, the community (aka YOU) have to decide what we
> should do. So what are your thoughts?
>
> ---
> Magnus Holm
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
>



-- 
An?bal

From ironald at gmail.com  Thu May 22 11:04:51 2008
From: ironald at gmail.com (ironald)
Date: Thu, 22 May 2008 23:04:51 +0800
Subject: Rack, Camping 2.0++
In-Reply-To: <391a49da0805211226y7686f4e8vf5574a308ea0e4fa@mail.gmail.com>
References: <391a49da0805211226y7686f4e8vf5574a308ea0e4fa@mail.gmail.com>
Message-ID: <48358B93.4040402@gmail.com>

Camping.goes :Forward

From jerry.west at ntlworld.com  Thu May 22 11:24:36 2008
From: jerry.west at ntlworld.com (Jerry West)
Date: Thu, 22 May 2008 16:24:36 +0100
Subject: Rack, Camping 2.0++
In-Reply-To: <391a49da0805211226y7686f4e8vf5574a308ea0e4fa@mail.gmail.com>
References: <391a49da0805211226y7686f4e8vf5574a308ea0e4fa@mail.gmail.com>
Message-ID: <48359034.9070905@ntlworld.com>

Excellent work; IMHO this makes camping a viable contender again!

+1 to your 2.0/2.1 plan

Jerry

Magnus Holm wrote:
> ===
> 5. Camping 2.0
> ===
>
> Here's my plan:
> * We agree on which of these four/three features we should implement
> * _why or zimbatm (or someone who really knows Camping) double-checks
>   everything and fixes any bugs.
> * Releasing 2.0 - Make lots of hype so everybody ports their apps to 2.0
> * Then we'll see if any bugs appear, fixes them quickly and releasing 2.1.
>
> ---
>
> This is just some proposals, the community (aka YOU) have to decide what we
> should do. So what are your thoughts?

From why at whytheluckystiff.net  Thu May 22 11:50:57 2008
From: why at whytheluckystiff.net (_why)
Date: Thu, 22 May 2008 10:50:57 -0500
Subject: Rack, Camping 2.0++
In-Reply-To: <dd83951f0805220457r3c8e111fj537f7079b97c5fa0@mail.gmail.com>
References: <391a49da0805211226y7686f4e8vf5574a308ea0e4fa@mail.gmail.com>
	<dd83951f0805220457r3c8e111fj537f7079b97c5fa0@mail.gmail.com>
Message-ID: <20080522155057.GS70833@beekeeper.hobix.com>

On Fri, May 23, 2008 at 07:27:18AM +1930, An?bal Rojas wrote:
> > ===
> > 4. Renaming camping-unabridged.rb to camping.rb?
> > ===
> >
> > I haven't touched camping.rb at all, do we really need to prove that it's a
> > micro-framework? It just makes development/releasing harder. Let's just forget
> > about the abridged version and rename camping-unabridged.rb to camping.rb!
> 
> Keeping Camping away from the bloat goes far beyond an arbitrary weight limit.
> It is a nice way to promote Camping. It is catchy saying "In Less then
> 4K", period.

Instead of saying the obfuscation "just makes development/releasing harder,"
try saying obfuscation "just makes flippancy/esotericism easier."

_why

From aredridel at nbtsc.org  Thu May 22 12:38:41 2008
From: aredridel at nbtsc.org (Aria Stewart)
Date: Thu, 22 May 2008 10:38:41 -0600
Subject: Rack, Camping 2.0++
In-Reply-To: <20080522063839.GR70833@beekeeper.hobix.com>
References: <391a49da0805211226y7686f4e8vf5574a308ea0e4fa@mail.gmail.com>
	<20080522063839.GR70833@beekeeper.hobix.com>
Message-ID: <704FC5EA-69A8-4335-B8D3-3BF1D54D206C@nbtsc.org>


On May 22, 2008, at 12:38 AM, _why wrote:

> On Wed, May 21, 2008 at 09:26:52PM +0200, Magnus Holm wrote:
>> I've just finished rewriting Camping to use Rack in the "core". I  
>> got rid of
>> (a little less) than 1kB in camping.rb and removed lots of un- 
>> necessary files
>> (lib/server/*.rb, fastcgi.rb & mongrel.rb).
>
> Splendid!  If we can say Camping, the 3K Microframework, then I
> think we will really have a reason to bump the big number.  I'll wait
> for a reaction from zimbatm, but I am euphoric about these changes.


Oh, that's wonderful! I really like it!

Aria Stewart
aredridel at nbtsc.org




From judofyr at gmail.com  Thu May 22 14:01:07 2008
From: judofyr at gmail.com (Magnus Holm)
Date: Thu, 22 May 2008 20:01:07 +0200
Subject: Rack, Camping 2.0++
In-Reply-To: <20080522155057.GS70833@beekeeper.hobix.com>
References: <391a49da0805211226y7686f4e8vf5574a308ea0e4fa@mail.gmail.com>
	<dd83951f0805220457r3c8e111fj537f7079b97c5fa0@mail.gmail.com>
	<20080522155057.GS70833@beekeeper.hobix.com>
Message-ID: <391a49da0805221101h4303155j161fa7a2c19b1fce@mail.gmail.com>

I must agree that the obfuscation is really impressive (specially in a
presentation
where you can include the full source on one slide). I just don't like
to touch it.
And unfortunately it doesn't evolve by itself.

I'm just tired of renaming camping-unabridged.rb to camping.rb in order to test
the apps, and then back again when I commit stuff.

I'll be perfectly fine if someone else creates the obfuscated version :-)

On Thu, May 22, 2008 at 5:50 PM, _why <why at whytheluckystiff.net> wrote:
> On Fri, May 23, 2008 at 07:27:18AM +1930, An?bal Rojas wrote:
>> > ===
>> > 4. Renaming camping-unabridged.rb to camping.rb?
>> > ===
>> >
>> > I haven't touched camping.rb at all, do we really need to prove that it's a
>> > micro-framework? It just makes development/releasing harder. Let's just forget
>> > about the abridged version and rename camping-unabridged.rb to camping.rb!
>>
>> Keeping Camping away from the bloat goes far beyond an arbitrary weight limit.
>> It is a nice way to promote Camping. It is catchy saying "In Less then
>> 4K", period.
>
> Instead of saying the obfuscation "just makes development/releasing harder,"
> try saying obfuscation "just makes flippancy/esotericism easier."
>
> _why
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
>



-- 
Magnus Holm

From ernest.prabhakar at gmail.com  Thu May 22 14:07:59 2008
From: ernest.prabhakar at gmail.com (Ernest Prabhakar)
Date: Thu, 22 May 2008 11:07:59 -0700
Subject: obfuscation Re: Rack, Camping 2.0++
In-Reply-To: <391a49da0805221101h4303155j161fa7a2c19b1fce@mail.gmail.com>
References: <391a49da0805211226y7686f4e8vf5574a308ea0e4fa@mail.gmail.com>
	<dd83951f0805220457r3c8e111fj537f7079b97c5fa0@mail.gmail.com>
	<20080522155057.GS70833@beekeeper.hobix.com>
	<391a49da0805221101h4303155j161fa7a2c19b1fce@mail.gmail.com>
Message-ID: <E2769D53-1EF2-4668-B7B5-500B94225596@gmail.com>

Hi Magnus,

On May 22, 2008, at 11:01 AM, Magnus Holm wrote:
> I must agree that the obfuscation is really impressive (specially in a
> presentation where you can include the full source on one slide). I  
> just don't like
> to touch it.
> And unfortunately it doesn't evolve by itself.
>
> I'm just tired of renaming camping-unabridged.rb to camping.rb in  
> order to test
> the apps, and then back again when I commit stuff.

> I'll be perfectly fine if someone else creates the obfuscated  
> version :-)

So, it sounds like there's a few options:

a) Automate the creation of the obfuscated version from the unabridged  
version

b) Tweak the system to run from "camping-unabridged.rb" (or a short  
name thereof, e.g. "campsrc")

c) Make the obfusc version "camping4k", and make camping-unabridged.rb  
the default camping.rb

Any of those seem viable?

-- Ernie P. 


>
>
> On Thu, May 22, 2008 at 5:50 PM, _why <why at whytheluckystiff.net>  
> wrote:
>> On Fri, May 23, 2008 at 07:27:18AM +1930, An?bal Rojas wrote:
>>>> ===
>>>> 4. Renaming camping-unabridged.rb to camping.rb?
>>>> ===
>>>>
>>>> I haven't touched camping.rb at all, do we really need to prove  
>>>> that it's a
>>>> micro-framework? It just makes development/releasing harder.  
>>>> Let's just forget
>>>> about the abridged version and rename camping-unabridged.rb to  
>>>> camping.rb!
>>>
>>> Keeping Camping away from the bloat goes far beyond an arbitrary  
>>> weight limit.
>>> It is a nice way to promote Camping. It is catchy saying "In Less  
>>> then
>>> 4K", period.
>>
>> Instead of saying the obfuscation "just makes development/releasing  
>> harder,"
>> try saying obfuscation "just makes flippancy/esotericism easier."
>>
>> _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 john.baylor at gmail.com  Thu May 22 14:34:50 2008
From: john.baylor at gmail.com (John Baylor)
Date: Thu, 22 May 2008 11:34:50 -0700
Subject: Camping-list Digest, Vol 23, Issue 8
In-Reply-To: <mailman.277.1211479270.13906.camping-list@rubyforge.org>
References: <mailman.277.1211479270.13906.camping-list@rubyforge.org>
Message-ID: <4d1897290805221134h6e6bcaben675b2ab8076e5a48@mail.gmail.com>

Removed 25% of the framework?  Gosh, I wish _why wasn't so darn verbose...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/camping-list/attachments/20080522/7612c03e/attachment.html>

From manfred at gmail.com  Thu May 22 14:44:45 2008
From: manfred at gmail.com (Manfred Stienstra)
Date: Thu, 22 May 2008 20:44:45 +0200
Subject: Rack, Camping 2.0++
In-Reply-To: <391a49da0805221101h4303155j161fa7a2c19b1fce@mail.gmail.com>
References: <391a49da0805211226y7686f4e8vf5574a308ea0e4fa@mail.gmail.com>
	<dd83951f0805220457r3c8e111fj537f7079b97c5fa0@mail.gmail.com>
	<20080522155057.GS70833@beekeeper.hobix.com>
	<391a49da0805221101h4303155j161fa7a2c19b1fce@mail.gmail.com>
Message-ID: <3DB297EE-F3FE-4FA6-BA96-45AF9DBEE9C1@gmail.com>


On May 22, 2008, at 8:01 PM, Magnus Holm wrote:

> I must agree that the obfuscation is really impressive (specially in a
> presentation where you can include the full source on one slide). I  
> just don't like
> to touch it.

I personally think that the esthetic properties of obfuscated source  
is what attracts quite a few people to the framework. I would really  
like to see it maintained as the primary distribution format.

Manfred

From jeremymcanally at gmail.com  Thu May 22 14:46:06 2008
From: jeremymcanally at gmail.com (Jeremy McAnally)
Date: Thu, 22 May 2008 14:46:06 -0400
Subject: Rack, Camping 2.0++
In-Reply-To: <3DB297EE-F3FE-4FA6-BA96-45AF9DBEE9C1@gmail.com>
References: <391a49da0805211226y7686f4e8vf5574a308ea0e4fa@mail.gmail.com>
	<dd83951f0805220457r3c8e111fj537f7079b97c5fa0@mail.gmail.com>
	<20080522155057.GS70833@beekeeper.hobix.com>
	<391a49da0805221101h4303155j161fa7a2c19b1fce@mail.gmail.com>
	<3DB297EE-F3FE-4FA6-BA96-45AF9DBEE9C1@gmail.com>
Message-ID: <d878fe460805221146r3d946a33id59f77ee09761717@mail.gmail.com>

I agree.

The obfuscation could probably be automated somehow with ParseTree and
ruby2ruby...I'm not entirely sure.  It'd be fun to toy with though.

--Jeremy

On Thu, May 22, 2008 at 2:44 PM, Manfred Stienstra <manfred at gmail.com> wrote:
>
> On May 22, 2008, at 8:01 PM, Magnus Holm wrote:
>
>> I must agree that the obfuscation is really impressive (specially in a
>> presentation where you can include the full source on one slide). I just
>> don't like
>> to touch it.
>
> I personally think that the esthetic properties of obfuscated source is what
> attracts quite a few people to the framework. I would really like to see it
> maintained as the primary distribution format.
>
> Manfred
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
>



-- 
http://jeremymcanally.com/
http://entp.com

Read my books:
Ruby in Practice (http://manning.com/mcanally/)
My free Ruby e-book (http://humblelittlerubybook.com/)

Or, my blogs:
http://mrneighborly.com
http://rubyinpractice.com

From judofyr at gmail.com  Thu May 22 15:03:14 2008
From: judofyr at gmail.com (Magnus Holm)
Date: Thu, 22 May 2008 21:03:14 +0200
Subject: Camping-list Digest, Vol 23, Issue 8
In-Reply-To: <4d1897290805221134h6e6bcaben675b2ab8076e5a48@mail.gmail.com>
References: <mailman.277.1211479270.13906.camping-list@rubyforge.org>
	<4d1897290805221134h6e6bcaben675b2ab8076e5a48@mail.gmail.com>
Message-ID: <391a49da0805221203y62ba5a52x335381910b2de4f2@mail.gmail.com>

Removed a little less than 1kB - added a new dependency with 4375 lines of code.

On Thu, May 22, 2008 at 8:34 PM, John Baylor <john.baylor at gmail.com> wrote:
> Removed 25% of the framework?  Gosh, I wish _why wasn't so darn verbose...
>
>
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
>



-- 
Magnus Holm

From blueberry at creativepony.com  Fri May 23 00:46:55 2008
From: blueberry at creativepony.com (Bluebie, Jenna)
Date: Fri, 23 May 2008 14:46:55 +1000
Subject: An issue for consideration
Message-ID: <DE066578-B2FC-4BAE-8BBD-E70884493E49@creativepony.com>

We've just come across an issue for consideration. I am avoiding some  
words which would allow people to find this message in an internet  
search who have questionable intentions, but wish to communicate a  
strong sense of caution. Consider someone who adds extra methods to  
their controller which they use in their main get/post methods to do  
things or to get secret data. Consider now, this http request:

> FOO / HTTP/1.1


And consider that camping allows methods to return a string and have  
that returned as a body. This could make for a lovely convenient form  
of RPC, but to those unaware, it seems there could be negative  
results. Aria has discovered with some testing that it is also  
possible to access helper methods remotely in this way, which is  
especially worth consideration as some of us use helper methods to do  
important things, and do not expect them to be directly accessible to  
the outside world.

In my own app, I will be using a service to filter all requests which  
don't use a standard http method. I'd like to suggest that in the next  
release of camping, we could do something like return unless ['GET',  
'POST', 'DELETE', 'HEAD'].include?(request_method), perhaps in the run  
method of camping. Or maybe we could raise an error. I'd also  
appreciate it if this update were deployed to rubygems servers without  
haste. I'll be sure to post the service I write to work around this  
issue just as soon as I'm done writing it.


?
Thoughtful Pony
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/camping-list/attachments/20080523/15535691/attachment.html>

From kprojection at gmail.com  Fri May 23 01:09:17 2008
From: kprojection at gmail.com (Eric Mill)
Date: Fri, 23 May 2008 01:09:17 -0400
Subject: Camping on Dreamhost
Message-ID: <c658be6b0805222209o73b4f8c3r2cc33506742506b9@mail.gmail.com>

I spent a few hours tonight getting Camping working with FastCGI on
Dreamhost.  I pieced together information from a blog post, an email thread,
and the SiteFive page on the Camping wiki, and posted my working results in
two places:

Camping wiki -
http://code.whytheluckystiff.net/camping/wiki/CampingOnDreamhost
Dreamhost wiki - http://wiki.dreamhost.com/Camping

Hopefully this helps somebody!

-- Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/camping-list/attachments/20080523/74ccda0e/attachment.html>

From blueberry at creativepony.com  Fri May 23 02:20:21 2008
From: blueberry at creativepony.com (Bluebie, Jenna)
Date: Fri, 23 May 2008 16:20:21 +1000
Subject: An issue for consideration
In-Reply-To: <DE066578-B2FC-4BAE-8BBD-E70884493E49@creativepony.com>
References: <DE066578-B2FC-4BAE-8BBD-E70884493E49@creativepony.com>
Message-ID: <1DEA639B-BD9D-4B59-AA89-4C013497F3E3@creativepony.com>

This should help. include Camping::ControllerSecurity in your  
controllers module or your Camping (or whatever Camping.goes has  
turned it in to) module, after requiring this:

> module Camping
>   module ControllerSecurity
>     def service(*a)
>       @method = 'get' unless ['get', 'post', 'delete',  
> 'head'].include?(@method.to_s.downcase)
>       super(*a)
>     end
>   end
> end


And the world should feel safe again, I think. I haven't really tested  
it properly, but what could go wrong? It certainly isn't making my app  
break.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/camping-list/attachments/20080523/81f1cb5e/attachment-0001.html>

From ironald at gmail.com  Fri May 23 05:22:55 2008
From: ironald at gmail.com (ronald.evangelista)
Date: Fri, 23 May 2008 17:22:55 +0800
Subject: R(c,*g) helper method can't handle nested hash input params
Message-ID: <48368CEF.70408@gmail.com>

params= {"search"=>"Search",
  "date_begin"=>"2007-05-01",
  "date_type"=>"created_on",
  "order"=>1,
  "report_type"=>"year_end",
  "person"=>
   {"reply_status_id"=>"1",
    "created_on"=>
     Tue, 01 May 2007 00:00:00 +0000..Fri, 23 May 2008 00:00:00 +0000},
  "date_end"=>"2008-05-23"}
R(Report,params)


=
 "/report/?search=Search&date_begin=2007-05-01&date_type=created_on&order
=1&report_type=year_end&person=reply_status_id1created_on2007-05-01T00%3A00%3A00
%2B00%3A00..2008-05-23T00%3A00%3A00%2B00%3A00&date_end=2008-05-23" 



      untested fix of module Helpers method R(c,*g)

    def R(c,*g)
      p,h=/\(.+?\)/,g.grep(Hash)
      g-=h
      raise "bad route" unless u = c.urls.find{|x|
        break x if x.scan(p).size == g.size &&
          /^#{x}\/?$/ =~ (x=g.inject(x){|x,a|
            x.sub p,C.escape((a[a.class.primary_key]rescue a))})
      }
      h.any?? u+"?"+h[0].map{|x|
         k, v = x
         if Hash===v
            name_ext, val = v.to_a.pop
            k="#{k}[#{name_ext}]"
            x=[k,val]
         end
         x.map{|z|
            C.escape(z)
            }*"="
         }*"&": u

    end            


hope this gets fixed in Camping 2.0


From zimbatm at oree.ch  Fri May 23 06:07:43 2008
From: zimbatm at oree.ch (zimbatm)
Date: Fri, 23 May 2008 12:07:43 +0200
Subject: obfuscation Re: Rack, Camping 2.0++
In-Reply-To: <E2769D53-1EF2-4668-B7B5-500B94225596@gmail.com>
References: <391a49da0805211226y7686f4e8vf5574a308ea0e4fa@mail.gmail.com>
	<dd83951f0805220457r3c8e111fj537f7079b97c5fa0@mail.gmail.com>
	<20080522155057.GS70833@beekeeper.hobix.com>
	<391a49da0805221101h4303155j161fa7a2c19b1fce@mail.gmail.com>
	<E2769D53-1EF2-4668-B7B5-500B94225596@gmail.com>
Message-ID: <e3caf1460805230307u204271dbwb3c42ce92262c270@mail.gmail.com>

2008/5/22 Ernest Prabhakar <ernest.prabhakar at gmail.com>:
> So, it sounds like there's a few options:
>
> a) Automate the creation of the obfuscated version from the unabridged
> version

Last time I checked, Ruby2Ruby didn't recognize all camping constructs
but it might be better now.

> b) Tweak the system to run from "camping-unabridged.rb" (or a short name
> thereof, e.g. "campsrc")

bin/camping could easily be tweaked to add a --unabridged command-line flag

> c) Make the obfusc version "camping4k", and make camping-unabridged.rb the
> default camping.rb

Ugh !

From judofyr at gmail.com  Fri May 23 06:16:15 2008
From: judofyr at gmail.com (Magnus Holm)
Date: Fri, 23 May 2008 12:16:15 +0200
Subject: An issue for consideration
In-Reply-To: <DE066578-B2FC-4BAE-8BBD-E70884493E49@creativepony.com>
References: <DE066578-B2FC-4BAE-8BBD-E70884493E49@creativepony.com>
Message-ID: <391a49da0805230316r51fb599bxb8b6ed4ff7a1ed6c@mail.gmail.com>

Good find!

1. If you run that on a real HTTP server (Apache, Nginx etc.) it will
just ignore it.
  Remember that  Mongrel/Thin should be served behind a proxy and are "lazy"
  about checking valid request.

2. A cool thing with the Rack-rewrite is that you can use Rack::Lint to validate
  the request/response according to the Rack-spec. So that will just raise:

Rack::Lint::LintError: REQUEST_METHOD unknown: FOO

3. I'm adding Rack::Lint as a middleware in bin/camping such that it's "safe" in
  development. If you're running Mongrel/Thin without proxy (madness!), you
  should also use Rack::Lint.

Do you think we should add a protection inside Camping too?

On Fri, May 23, 2008 at 6:46 AM, Bluebie, Jenna
<blueberry at creativepony.com> wrote:
> We've just come across an issue for consideration. I am avoiding some words
> which would allow people to find this message in an internet search who have
> questionable intentions, but wish to communicate a strong sense of caution.
> Consider someone who adds extra methods to their controller which they use
> in their main get/post methods to do things or to get secret data. Consider
> now, this http request:
>
> FOO / HTTP/1.1
>
> And consider that camping allows methods to return a string and have that
> returned as a body. This could make for a lovely convenient form of RPC, but
> to those unaware, it seems there could be negative results. Aria has
> discovered with some testing that it is also possible to access helper
> methods remotely in this way, which is especially worth consideration as
> some of us use helper methods to do important things, and do not expect them
> to be directly accessible to the outside world.
> In my own app, I will be using a service to filter all requests which don't
> use a standard http method. I'd like to suggest that in the next release of
> camping, we could do something like return unless ['GET', 'POST', 'DELETE',
> 'HEAD'].include?(request_method), perhaps in the run method of camping. Or
> maybe we could raise an error. I'd also appreciate it if this update were
> deployed to rubygems servers without haste. I'll be sure to post the service
> I write to work around this issue just as soon as I'm done writing it.
>
> ?
> Thoughtful Pony
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
>



-- 
Magnus Holm

From judofyr at gmail.com  Fri May 23 06:23:31 2008
From: judofyr at gmail.com (Magnus Holm)
Date: Fri, 23 May 2008 12:23:31 +0200
Subject: obfuscation Re: Rack, Camping 2.0++
In-Reply-To: <e3caf1460805230307u204271dbwb3c42ce92262c270@mail.gmail.com>
References: <391a49da0805211226y7686f4e8vf5574a308ea0e4fa@mail.gmail.com>
	<dd83951f0805220457r3c8e111fj537f7079b97c5fa0@mail.gmail.com>
	<20080522155057.GS70833@beekeeper.hobix.com>
	<391a49da0805221101h4303155j161fa7a2c19b1fce@mail.gmail.com>
	<E2769D53-1EF2-4668-B7B5-500B94225596@gmail.com>
	<e3caf1460805230307u204271dbwb3c42ce92262c270@mail.gmail.com>
Message-ID: <391a49da0805230323g726bc19m564ab66c6b4afb0@mail.gmail.com>

The problem is that almost all app require 'camping' and when bin/camping
require 'camping-unabridged' things gets pretty messy.

(I just realized that bin/camping could monkey-patch require such that when
the --unabridged-flag is set it require 'camping-unabridged' instead of
'camping'. But that's *really* dirty!)

On Fri, May 23, 2008 at 12:07 PM, zimbatm <zimbatm at oree.ch> wrote:
> 2008/5/22 Ernest Prabhakar <ernest.prabhakar at gmail.com>:
>> So, it sounds like there's a few options:
>>
>> a) Automate the creation of the obfuscated version from the unabridged
>> version
>
> Last time I checked, Ruby2Ruby didn't recognize all camping constructs
> but it might be better now.
>
>> b) Tweak the system to run from "camping-unabridged.rb" (or a short name
>> thereof, e.g. "campsrc")
>
> bin/camping could easily be tweaked to add a --unabridged command-line flag
>
>> c) Make the obfusc version "camping4k", and make camping-unabridged.rb the
>> default camping.rb
>
> Ugh !
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
>



-- 
Magnus Holm

From blueberry at creativepony.com  Fri May 23 08:18:07 2008
From: blueberry at creativepony.com (Bluebie, Jenna)
Date: Fri, 23 May 2008 22:18:07 +1000
Subject: An issue for consideration
In-Reply-To: <391a49da0805230316r51fb599bxb8b6ed4ff7a1ed6c@mail.gmail.com>
References: <DE066578-B2FC-4BAE-8BBD-E70884493E49@creativepony.com>
	<391a49da0805230316r51fb599bxb8b6ed4ff7a1ed6c@mail.gmail.com>
Message-ID: <7A37E137-9080-42B9-A68F-C1B6DEE92C71@creativepony.com>

Yeah I think it'd be good, or if not just make it not work on helper  
methods, just class methods in the controller, then it wouldn't be so  
nasty and unexpected.

It's good to hear i'm safe behind apache.


On 23/05/2008, at 8:16 PM, Magnus Holm wrote:

> Good find!
>
> 1. If you run that on a real HTTP server (Apache, Nginx etc.) it will
> just ignore it.
>  Remember that  Mongrel/Thin should be served behind a proxy and are  
> "lazy"
>  about checking valid request.
>
> 2. A cool thing with the Rack-rewrite is that you can use Rack::Lint  
> to validate
>  the request/response according to the Rack-spec. So that will just  
> raise:
>
> Rack::Lint::LintError: REQUEST_METHOD unknown: FOO
>
> 3. I'm adding Rack::Lint as a middleware in bin/camping such that  
> it's "safe" in
>  development. If you're running Mongrel/Thin without proxy  
> (madness!), you
>  should also use Rack::Lint.
>
> Do you think we should add a protection inside Camping too?
>
> On Fri, May 23, 2008 at 6:46 AM, Bluebie, Jenna
> <blueberry at creativepony.com> wrote:
>> We've just come across an issue for consideration. I am avoiding  
>> some words
>> which would allow people to find this message in an internet search  
>> who have
>> questionable intentions, but wish to communicate a strong sense of  
>> caution.
>> Consider someone who adds extra methods to their controller which  
>> they use
>> in their main get/post methods to do things or to get secret data.  
>> Consider
>> now, this http request:
>>
>> FOO / HTTP/1.1
>>
>> And consider that camping allows methods to return a string and  
>> have that
>> returned as a body. This could make for a lovely convenient form of  
>> RPC, but
>> to those unaware, it seems there could be negative results. Aria has
>> discovered with some testing that it is also possible to access  
>> helper
>> methods remotely in this way, which is especially worth  
>> consideration as
>> some of us use helper methods to do important things, and do not  
>> expect them
>> to be directly accessible to the outside world.
>> In my own app, I will be using a service to filter all requests  
>> which don't
>> use a standard http method. I'd like to suggest that in the next  
>> release of
>> camping, we could do something like return unless ['GET', 'POST',  
>> 'DELETE',
>> 'HEAD'].include?(request_method), perhaps in the run method of  
>> camping. Or
>> maybe we could raise an error. I'd also appreciate it if this  
>> update were
>> deployed to rubygems servers without haste. I'll be sure to post  
>> the service
>> I write to work around this issue just as soon as I'm done writing  
>> it.
>>
>> ?
>> Thoughtful Pony
>> _______________________________________________
>> 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 zimbatm at oree.ch  Fri May 23 09:18:48 2008
From: zimbatm at oree.ch (zimbatm)
Date: Fri, 23 May 2008 15:18:48 +0200
Subject: obfuscation Re: Rack, Camping 2.0++
In-Reply-To: <391a49da0805230323g726bc19m564ab66c6b4afb0@mail.gmail.com>
References: <391a49da0805211226y7686f4e8vf5574a308ea0e4fa@mail.gmail.com>
	<dd83951f0805220457r3c8e111fj537f7079b97c5fa0@mail.gmail.com>
	<20080522155057.GS70833@beekeeper.hobix.com>
	<391a49da0805221101h4303155j161fa7a2c19b1fce@mail.gmail.com>
	<E2769D53-1EF2-4668-B7B5-500B94225596@gmail.com>
	<e3caf1460805230307u204271dbwb3c42ce92262c270@mail.gmail.com>
	<391a49da0805230323g726bc19m564ab66c6b4afb0@mail.gmail.com>
Message-ID: <e3caf1460805230618g9c72361y8d5908663158bbc5@mail.gmail.com>

> The problem is that almost all app require 'camping' and when bin/camping
> require 'camping-unabridged' things gets pretty messy.

Right, didn't thought about that.. well then we have to come up with a
Ruby2Ruby version, isn't it ?

From aredridel at nbtsc.org  Fri May 23 09:56:45 2008
From: aredridel at nbtsc.org (Aria Stewart)
Date: Fri, 23 May 2008 07:56:45 -0600
Subject: An issue for consideration
In-Reply-To: <DE066578-B2FC-4BAE-8BBD-E70884493E49@creativepony.com>
References: <DE066578-B2FC-4BAE-8BBD-E70884493E49@creativepony.com>
Message-ID: <553BE373-A72D-4836-9DB6-B7E98230CF43@nbtsc.org>


On May 22, 2008, at 10:46 PM, Bluebie, Jenna wrote:

> We've just come across an issue for consideration. I am avoiding  
> some words which would allow people to find this message in an  
> internet search who have questionable intentions, but wish to  
> communicate a strong sense of caution. Consider someone who adds  
> extra methods to their controller which they use in their main get/ 
> post methods to do things or to get secret data. Consider now, this  
> http request:
>
>> FOO / HTTP/1.1
>
>
> And consider that camping allows methods to return a string and have  
> that returned as a body. This could make for a lovely convenient  
> form of RPC, but to those unaware, it seems there could be negative  
> results. Aria has discovered with some testing that it is also  
> possible to access helper methods remotely in this way, which is  
> especially worth consideration as some of us use helper methods to  
> do important things, and do not expect them to be directly  
> accessible to the outside world.
>
> In my own app, I will be using a service to filter all requests  
> which don't use a standard http method. I'd like to suggest that in  
> the next release of camping, we could do something like return  
> unless ['GET', 'POST', 'DELETE', 'HEAD'].include?(request_method),  
> perhaps in the run method of camping. Or maybe we could raise an  
> error. I'd also appreciate it if this update were deployed to  
> rubygems servers without haste. I'll be sure to post the service I  
> write to work around this issue just as soon as I'm done writing it.
>
>

return unless ['GET', 'POST', 'DELETE', 'HEAD'].include? 
(ControllerClass.instance_methods(false)) -- only use methods defined  
directly in the controller?

> ?
> Thoughtful Pony
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list

Aria Stewart
aredridel at nbtsc.org




From why at whytheluckystiff.net  Fri May 23 10:40:14 2008
From: why at whytheluckystiff.net (_why)
Date: Fri, 23 May 2008 09:40:14 -0500
Subject: An issue for consideration
In-Reply-To: <391a49da0805230316r51fb599bxb8b6ed4ff7a1ed6c@mail.gmail.com>
References: <DE066578-B2FC-4BAE-8BBD-E70884493E49@creativepony.com>
	<391a49da0805230316r51fb599bxb8b6ed4ff7a1ed6c@mail.gmail.com>
Message-ID: <20080523144014.GY70833@beekeeper.hobix.com>

On Fri, May 23, 2008 at 12:16:15PM +0200, Magnus Holm wrote:
> Do you think we should add a protection inside Camping too?

No, if Rack comes with Rack::Lint and Camping now depends on Rack,
then it'd be redundant to have it in Camping as well, you know?

_why

From kprojection at gmail.com  Fri May 23 12:40:45 2008
From: kprojection at gmail.com (Eric Mill)
Date: Fri, 23 May 2008 12:40:45 -0400
Subject: obfuscation Re: Rack, Camping 2.0++
In-Reply-To: <e3caf1460805230618g9c72361y8d5908663158bbc5@mail.gmail.com>
References: <391a49da0805211226y7686f4e8vf5574a308ea0e4fa@mail.gmail.com>
	<dd83951f0805220457r3c8e111fj537f7079b97c5fa0@mail.gmail.com>
	<20080522155057.GS70833@beekeeper.hobix.com>
	<391a49da0805221101h4303155j161fa7a2c19b1fce@mail.gmail.com>
	<E2769D53-1EF2-4668-B7B5-500B94225596@gmail.com>
	<e3caf1460805230307u204271dbwb3c42ce92262c270@mail.gmail.com>
	<391a49da0805230323g726bc19m564ab66c6b4afb0@mail.gmail.com>
	<e3caf1460805230618g9c72361y8d5908663158bbc5@mail.gmail.com>
Message-ID: <c658be6b0805230940u39c32fc4ra99efe2dd1c412ff@mail.gmail.com>

How is camping.rb created from camping-unabridged.rb?  By hand?  If that's
the case, you can't expect the compressed camping.rb to be maintained once
more than _why and zimbatm start wanting to contribute, you know?  If it can
be done by script, then by all means let's do that and include that script
in the repository.

-- Eric

On Fri, May 23, 2008 at 9:18 AM, zimbatm <zimbatm at oree.ch> wrote:

> > The problem is that almost all app require 'camping' and when bin/camping
> > require 'camping-unabridged' things gets pretty messy.
>
> Right, didn't thought about that.. well then we have to come up with a
> Ruby2Ruby version, isn't it ?
> _______________________________________________
> 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/20080523/963309b4/attachment-0001.html>

From zimbatm at oree.ch  Fri May 23 17:18:49 2008
From: zimbatm at oree.ch (zimbatm)
Date: Fri, 23 May 2008 23:18:49 +0200
Subject: Rack, Camping 2.0++
In-Reply-To: <20080522063839.GR70833@beekeeper.hobix.com>
References: <391a49da0805211226y7686f4e8vf5574a308ea0e4fa@mail.gmail.com>
	<20080522063839.GR70833@beekeeper.hobix.com>
Message-ID: <e3caf1460805231418u264603ebu58b54c16bfe06d70@mail.gmail.com>

2008/5/22 _why <why at whytheluckystiff.net>:
> Splendid!  If we can say Camping, the 3K Microframework, then I
> think we will really have a reason to bump the big number.  I'll wait
> for a reaction from zimbatm, but I am euphoric about these changes.

Wasn't the one who codes who leads ? :)

From zimbatm at oree.ch  Fri May 23 17:20:12 2008
From: zimbatm at oree.ch (zimbatm)
Date: Fri, 23 May 2008 23:20:12 +0200
Subject: obfuscation Re: Rack, Camping 2.0++
In-Reply-To: <c658be6b0805230940u39c32fc4ra99efe2dd1c412ff@mail.gmail.com>
References: <391a49da0805211226y7686f4e8vf5574a308ea0e4fa@mail.gmail.com>
	<dd83951f0805220457r3c8e111fj537f7079b97c5fa0@mail.gmail.com>
	<20080522155057.GS70833@beekeeper.hobix.com>
	<391a49da0805221101h4303155j161fa7a2c19b1fce@mail.gmail.com>
	<E2769D53-1EF2-4668-B7B5-500B94225596@gmail.com>
	<e3caf1460805230307u204271dbwb3c42ce92262c270@mail.gmail.com>
	<391a49da0805230323g726bc19m564ab66c6b4afb0@mail.gmail.com>
	<e3caf1460805230618g9c72361y8d5908663158bbc5@mail.gmail.com>
	<c658be6b0805230940u39c32fc4ra99efe2dd1c412ff@mail.gmail.com>
Message-ID: <e3caf1460805231420x5dd7be1cg9675b18c0feeaf86@mail.gmail.com>

> How is camping.rb created from camping-unabridged.rb?  By hand?
Err.. yes. This is a kind of art you know ?

From john.beppu at gmail.com  Fri May 23 17:36:23 2008
From: john.beppu at gmail.com (John Beppu)
Date: Fri, 23 May 2008 14:36:23 -0700
Subject: Camping-list Digest, Vol 23, Issue 8
In-Reply-To: <4d1897290805221134h6e6bcaben675b2ab8076e5a48@mail.gmail.com>
References: <mailman.277.1211479270.13906.camping-list@rubyforge.org>
	<4d1897290805221134h6e6bcaben675b2ab8076e5a48@mail.gmail.com>
Message-ID: <21a10fe00805231436g78fbccc0r85f474db26de0af4@mail.gmail.com>

What pains me is that my Perl clone is weighing in at a bloated 6.6k after I
run it through:  cat `find -name '*.pm' -print` | perltidy -npro -dac -dws
-i 0 | sed '/^\s*$/d' | perl -pe 's/ +/ /g' | wc
.

I was never an expert golfer <http://perlgolf.sourceforge.net/>, but
still....

*sigh*

--beppu

On Thu, May 22, 2008 at 11:34 AM, John Baylor <john.baylor at gmail.com> wrote:

> Removed 25% of the framework?  Gosh, I wish _why wasn't so darn verbose...
>
>
> _______________________________________________
> 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/20080523/45bafe06/attachment.html>

From judofyr at gmail.com  Fri May 23 17:36:51 2008
From: judofyr at gmail.com (Magnus Holm)
Date: Fri, 23 May 2008 23:36:51 +0200
Subject: Rack, Camping 2.0++
In-Reply-To: <e3caf1460805231418u264603ebu58b54c16bfe06d70@mail.gmail.com>
References: <391a49da0805211226y7686f4e8vf5574a308ea0e4fa@mail.gmail.com>
	<20080522063839.GR70833@beekeeper.hobix.com>
	<e3caf1460805231418u264603ebu58b54c16bfe06d70@mail.gmail.com>
Message-ID: <391a49da0805231436m334778a8qe04c90e111c66d69@mail.gmail.com>

So should I just merge/rebase everything to my master, so _why can merge
it into his? Some more notes:

* camping/db.rb -> camping/ar.rb
* camping/session.rb -> camping/ar/session.rb
* CookieSession -> camping/session.rb

The documentation and the names (Camping::Session, Camping::ARSession?)
needs some fixing. I'll let the leader decide :-)

On Fri, May 23, 2008 at 11:18 PM, zimbatm <zimbatm at oree.ch> wrote:
> 2008/5/22 _why <why at whytheluckystiff.net>:
>> Splendid!  If we can say Camping, the 3K Microframework, then I
>> think we will really have a reason to bump the big number.  I'll wait
>> for a reaction from zimbatm, but I am euphoric about these changes.
>
> Wasn't the one who codes who leads ? :)
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
>



-- 
Magnus Holm

From john.beppu at gmail.com  Fri May 23 19:17:37 2008
From: john.beppu at gmail.com (John Beppu)
Date: Fri, 23 May 2008 16:17:37 -0700
Subject: Rack, Camping 2.0++
In-Reply-To: <391a49da0805211226y7686f4e8vf5574a308ea0e4fa@mail.gmail.com>
References: <391a49da0805211226y7686f4e8vf5574a308ea0e4fa@mail.gmail.com>
Message-ID: <21a10fe00805231617r7912722bo77e82618c1fdd3fd@mail.gmail.com>

Does being implemented on top of Rack mean that Camping will get the
concurrency described on pages 17..21 of
http://yeahnah.org/files/rack-presentation-oct-07.pdf ?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/camping-list/attachments/20080523/24601934/attachment.html>

From whateley at gmail.com  Fri May 23 19:21:34 2008
From: whateley at gmail.com (Brendan Taylor)
Date: Fri, 23 May 2008 17:21:34 -0600
Subject: An issue for consideration
In-Reply-To: <1DEA639B-BD9D-4B59-AA89-4C013497F3E3@creativepony.com>
References: <DE066578-B2FC-4BAE-8BBD-E70884493E49@creativepony.com>
	<1DEA639B-BD9D-4B59-AA89-4C013497F3E3@creativepony.com>
Message-ID: <20080523232134.GA7506@nyarlathotep.necronomicorp.com>

On Fri, May 23, 2008 at 04:20:21PM +1000, Bluebie, Jenna wrote:
> This should help. include Camping::ControllerSecurity in your controllers 
> module or your Camping (or whatever Camping.goes has turned it in to) 
> module, after requiring this:
>
>> module Camping
>>   module ControllerSecurity
>>     def service(*a)
>>       @method = 'get' unless ['get', 'post', 'delete', 
>> 'head'].include?(@method.to_s.downcase)
>>       super(*a)
>>     end
>>   end
>> end
>
>
> And the world should feel safe again, I think. I haven't really tested it 
> properly, but what could go wrong? It certainly isn't making my app break.

You missed PUT :)

I can imagine situations where you'd want to be able to use more
esoteric HTTP methods (like OPTIONS, or any of WebDAV's many extension
methods). I don't have a better solution though, and this may be Good
Enough?.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/camping-list/attachments/20080523/56d7b37e/attachment.bin>

From zimbatm at oree.ch  Fri May 23 19:28:46 2008
From: zimbatm at oree.ch (zimbatm)
Date: Sat, 24 May 2008 01:28:46 +0200
Subject: Rack, Camping 2.0++
In-Reply-To: <391a49da0805231436m334778a8qe04c90e111c66d69@mail.gmail.com>
References: <391a49da0805211226y7686f4e8vf5574a308ea0e4fa@mail.gmail.com>
	<20080522063839.GR70833@beekeeper.hobix.com>
	<e3caf1460805231418u264603ebu58b54c16bfe06d70@mail.gmail.com>
	<391a49da0805231436m334778a8qe04c90e111c66d69@mail.gmail.com>
Message-ID: <e3caf1460805231628j4dfec5es12e11d6768e53fda@mail.gmail.com>

2008/5/23 Magnus Holm <judofyr at gmail.com>:
> So should I just merge/rebase everything to my master, so _why can merge
> it into his? Some more notes:
>
> * camping/db.rb -> camping/ar.rb
> * camping/session.rb -> camping/ar/session.rb
> * CookieSession -> camping/session.rb
>
> The documentation and the names (Camping::Session, Camping::ARSession?)
> needs some fixing. I'll let the leader decide :-)

You are the leader now :)

If I where you, I'd take some time checking the documentation
generates well. Last time I checked, it was a mess.

From kprojection at gmail.com  Fri May 23 19:31:01 2008
From: kprojection at gmail.com (Eric Mill)
Date: Fri, 23 May 2008 19:31:01 -0400
Subject: An issue for consideration
In-Reply-To: <20080523232134.GA7506@nyarlathotep.necronomicorp.com>
References: <DE066578-B2FC-4BAE-8BBD-E70884493E49@creativepony.com>
	<1DEA639B-BD9D-4B59-AA89-4C013497F3E3@creativepony.com>
	<20080523232134.GA7506@nyarlathotep.necronomicorp.com>
Message-ID: <c658be6b0805231631q3d997391xcfb6497e467778d@mail.gmail.com>

You at least want to allow what's in the HTTP spec -- that's HEAD,
TRACE, OPTIONS, and CONNECT, on top of the GET/POST/PUT/DELETE.

-- Eric

On Fri, May 23, 2008 at 7:21 PM, Brendan Taylor <whateley at gmail.com> wrote:
> On Fri, May 23, 2008 at 04:20:21PM +1000, Bluebie, Jenna wrote:
>> This should help. include Camping::ControllerSecurity in your controllers
>> module or your Camping (or whatever Camping.goes has turned it in to)
>> module, after requiring this:
>>
>>> module Camping
>>>   module ControllerSecurity
>>>     def service(*a)
>>>       @method = 'get' unless ['get', 'post', 'delete',
>>> 'head'].include?(@method.to_s.downcase)
>>>       super(*a)
>>>     end
>>>   end
>>> end
>>
>>
>> And the world should feel safe again, I think. I haven't really tested it
>> properly, but what could go wrong? It certainly isn't making my app break.
>
> You missed PUT :)
>
> I can imagine situations where you'd want to be able to use more
> esoteric HTTP methods (like OPTIONS, or any of WebDAV's many extension
> methods). I don't have a better solution though, and this may be Good
> Enough?.
>
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
>

From judofyr at gmail.com  Sat May 24 12:51:06 2008
From: judofyr at gmail.com (Magnus Holm)
Date: Sat, 24 May 2008 18:51:06 +0200
Subject: Rack, Camping 2.0++
In-Reply-To: <e3caf1460805231628j4dfec5es12e11d6768e53fda@mail.gmail.com>
References: <391a49da0805211226y7686f4e8vf5574a308ea0e4fa@mail.gmail.com>
	<20080522063839.GR70833@beekeeper.hobix.com>
	<e3caf1460805231418u264603ebu58b54c16bfe06d70@mail.gmail.com>
	<391a49da0805231436m334778a8qe04c90e111c66d69@mail.gmail.com>
	<e3caf1460805231628j4dfec5es12e11d6768e53fda@mail.gmail.com>
Message-ID: <391a49da0805240951x2f1177f8q52412d6e2a6666a4@mail.gmail.com>

I don't want to be the leader. I just want to contribute to one of the sweetest
framework that exists in the Rubyverse!

I'm going to contribute with what I can, and I suck at writing documentation and
I have no intention to learn RDoc (ATM, maybe another day).

(I still think that _why is the true leader of Camping.)

On Sat, May 24, 2008 at 1:28 AM, zimbatm <zimbatm at oree.ch> wrote:
> 2008/5/23 Magnus Holm <judofyr at gmail.com>:
>> So should I just merge/rebase everything to my master, so _why can merge
>> it into his? Some more notes:
>>
>> * camping/db.rb -> camping/ar.rb
>> * camping/session.rb -> camping/ar/session.rb
>> * CookieSession -> camping/session.rb
>>
>> The documentation and the names (Camping::Session, Camping::ARSession?)
>> needs some fixing. I'll let the leader decide :-)
>
> You are the leader now :)
>
> If I where you, I'd take some time checking the documentation
> generates well. Last time I checked, it was a mess.
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
>



-- 
Magnus Holm

From jeremymcanally at gmail.com  Sat May 24 16:32:05 2008
From: jeremymcanally at gmail.com (Jeremy McAnally)
Date: Sat, 24 May 2008 16:32:05 -0400
Subject: Rack, Camping 2.0++
In-Reply-To: <391a49da0805240951x2f1177f8q52412d6e2a6666a4@mail.gmail.com>
References: <391a49da0805211226y7686f4e8vf5574a308ea0e4fa@mail.gmail.com>
	<20080522063839.GR70833@beekeeper.hobix.com>
	<e3caf1460805231418u264603ebu58b54c16bfe06d70@mail.gmail.com>
	<391a49da0805231436m334778a8qe04c90e111c66d69@mail.gmail.com>
	<e3caf1460805231628j4dfec5es12e11d6768e53fda@mail.gmail.com>
	<391a49da0805240951x2f1177f8q52412d6e2a6666a4@mail.gmail.com>
Message-ID: <d878fe460805241332n20e4eed0v6cd2dd209b800d27@mail.gmail.com>

If you can point to areas to document or changes you are making that
need documentation, I'd be happy to write it for you.

--Jeremy

On Sat, May 24, 2008 at 12:51 PM, Magnus Holm <judofyr at gmail.com> wrote:
> I don't want to be the leader. I just want to contribute to one of the sweetest
> framework that exists in the Rubyverse!
>
> I'm going to contribute with what I can, and I suck at writing documentation and
> I have no intention to learn RDoc (ATM, maybe another day).
>
> (I still think that _why is the true leader of Camping.)
>
> On Sat, May 24, 2008 at 1:28 AM, zimbatm <zimbatm at oree.ch> wrote:
>> 2008/5/23 Magnus Holm <judofyr at gmail.com>:
>>> So should I just merge/rebase everything to my master, so _why can merge
>>> it into his? Some more notes:
>>>
>>> * camping/db.rb -> camping/ar.rb
>>> * camping/session.rb -> camping/ar/session.rb
>>> * CookieSession -> camping/session.rb
>>>
>>> The documentation and the names (Camping::Session, Camping::ARSession?)
>>> needs some fixing. I'll let the leader decide :-)
>>
>> You are the leader now :)
>>
>> If I where you, I'd take some time checking the documentation
>> generates well. Last time I checked, it was a mess.
>> _______________________________________________
>> 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
>



-- 
http://jeremymcanally.com/
http://entp.com

Read my books:
Ruby in Practice (http://manning.com/mcanally/)
My free Ruby e-book (http://humblelittlerubybook.com/)

Or, my blogs:
http://mrneighborly.com
http://rubyinpractice.com

From judofyr at gmail.com  Sat May 24 18:25:08 2008
From: judofyr at gmail.com (Magnus Holm)
Date: Sun, 25 May 2008 00:25:08 +0200
Subject: Camping 2.0 - What's left?
Message-ID: <391a49da0805241525h1627d95m8fc0928680f12da1@mail.gmail.com>

I've just sent a pull-request to _why with my changes[1] and here is some
things that I think needs to be done before a (possible) release:

* The cookie session is named Camping::Session and is placed in
camping/session.rb. Maybe this should be called Camping::CookieSession or???

* The ActiveRecord session is named Camping::ARSession and is placed in
camping/ar/session.rb. Maybe it should be called Camping::AR::Session or???

* The documentation of cookie sessions is just utterly wrong. Can someone
clean it up?

* The documentation in camping-unabridged.rb and README are almost duplicates.
camping-unabridged.rb should only contain about the differences between
camping.rb and camping-unabrdiged.rb, while README should be all about Camping
(IMO). We must also add that apps should be run using Rack, and The Camping
Server is only for development.

* The flipbook-template produces some weird output once in a while. See [2].
Anyone knows RDoc-templates? We should also include all the methods in a list,
since they're spread between Base, Helpers and Controllers. And Controllers
won't be documented since it has a "X =" in front of it (doc-ability vs
size?).

* Some investigating of how to use Camping with DataMapper, Sequel and Og, and
if they require any glue. Should the other ORMs also have tables prefixed with
the app name?

* What about a little guide of how to make your app Camping 2.0 "compatible"?

* Cleaning up the wiki to be 2.0 only?

* <insert your wish>

I'm not saying I won't do any of these things, I just want to push this code
so other can contribute too. (I suck at docs + decisions).

Oh, and I've included `rake ruby_diff` which will use Ruby2Ruby to translate
camping.rb & camping-unabridged.rb to "proper" Ruby and show a diff. Really
useful when synchronizing the two files.

camping.rb is now at 3171 bytes (77% of 4kB)!

(I realize that we don't need to target all of these issues for 2.0,
we must have
something left for 2.1 :-)

[1] http://github.com/judofyr/camping [2]
http://camping.rubyforge.org/classes/Camping/H.html vs
http://camping.rubyforge.org/classes/WEBrick.html

---
Magnus "We're missing _why in #camping" Holm

From why at hobix.com  Sat May 24 23:21:56 2008
From: why at hobix.com (_why)
Date: Sat, 24 May 2008 22:21:56 -0500
Subject: Camping 2.0 - What's left?
In-Reply-To: <391a49da0805241525h1627d95m8fc0928680f12da1@mail.gmail.com>
References: <391a49da0805241525h1627d95m8fc0928680f12da1@mail.gmail.com>
Message-ID: <20080525032155.GC70833@beekeeper.hobix.com>

On Sun, May 25, 2008 at 12:25:08AM +0200, Magnus Holm wrote:
> I've just sent a pull-request to _why with my changes[1] and here is some
> things that I think needs to be done before a (possible) release:

It's been merged, great work, Magnus.  I'm not quite to the point of
addressing all of your questions, I'm just trying some of my old
apps on this latest stuff.

So, what's the reason for getting rid of @env?  Well, I see that
Rack::Request is a wrapper for all those vars.  I think I'm still
going to allow @env, though, for compatibility with old apps.

_why

From why at whytheluckystiff.net  Sat May 24 23:43:01 2008
From: why at whytheluckystiff.net (_why)
Date: Sat, 24 May 2008 22:43:01 -0500
Subject: Camping 2.0 - What's left?
In-Reply-To: <391a49da0805241525h1627d95m8fc0928680f12da1@mail.gmail.com>
References: <391a49da0805241525h1627d95m8fc0928680f12da1@mail.gmail.com>
Message-ID: <20080525034301.GD70833@beekeeper.hobix.com>

On Sun, May 25, 2008 at 12:25:08AM +0200, Magnus Holm wrote:
> * The cookie session is named Camping::Session and is placed in
> camping/session.rb. Maybe this should be called Camping::CookieSession or???

You know, these cookie sessions seem like they could be a problem.
A lot of sessions would contain just the hash and the user name.
So, spoof the user name and you're in, you know?

_why

From blueberry at creativepony.com  Sun May 25 02:00:49 2008
From: blueberry at creativepony.com (Bluebie, Jenna)
Date: Sun, 25 May 2008 16:00:49 +1000
Subject: Camping 2.0 - What's left?
In-Reply-To: <20080525034301.GD70833@beekeeper.hobix.com>
References: <391a49da0805241525h1627d95m8fc0928680f12da1@mail.gmail.com>
	<20080525034301.GD70833@beekeeper.hobix.com>
Message-ID: <864E5404-85BB-458A-B6E6-A0BD35030BB4@creativepony.com>

No, that isn't a problem. The cookie contains a marshaled string of  
the @store variable, but it also has after it a ':' and then an SHA256  
hash of the marshaled string combined with a secret value the user  
needs to set in their controller with something like:

@@state_secret = "secret thingy here"

Unfortunately, it is totally insecure if that isn't set, and I guess  
we should raise an error in that case, or maybe just make a random  
value, though that would cause problems in servers using multiple  
running copies of ruby, and in CGI, cluster server systems, and so on.  
Ideally I wanted to make the fallback string be the source code for  
the main app file, which I figured would be unique enough and secret  
enough in most situations, but couldn't figure out how from the  
context of a module.

Rails gets around this issue by having a 'generator' which includes a  
random code at the time of app creation hard coded in, and ships with  
cookie sessions as the default session store for convenience. The  
rails implementation is a bit more complex in that it can span the  
session data over multiple cookies if it won't fit in just one. I  
personally think if app developers are trying to stuff more than 4k of  
stuff in a session they should get errors anyway to teach them that  
it's not appropriate, regardless of the storage system.

Anyway, if the attacker doesn't know the value of @state_secret, and  
the hashing algorithm in use isn't broken, changing any character in  
the cookie will cause it to be ignored and a new session created. They  
could brute force it, but SHA256 has a pretty decent hash length and  
that would take some serious time.

It's much the same concept as 'signing' used in various other systems.  
In this case instead of an expensive encryption certificate as the  
secret, we have a made up string.


?
Jenna

On 25/05/2008, at 1:43 PM, _why wrote:

> On Sun, May 25, 2008 at 12:25:08AM +0200, Magnus Holm wrote:
>> * The cookie session is named Camping::Session and is placed in
>> camping/session.rb. Maybe this should be called  
>> Camping::CookieSession or???
>
> You know, these cookie sessions seem like they could be a problem.
> A lot of sessions would contain just the hash and the user name.
> So, spoof the user name and you're in, you know?
>
> _why
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list


From blueberry at creativepony.com  Sun May 25 02:02:37 2008
From: blueberry at creativepony.com (Bluebie, Jenna)
Date: Sun, 25 May 2008 16:02:37 +1000
Subject: Camping 2.0 - What's left?
In-Reply-To: <20080525034301.GD70833@beekeeper.hobix.com>
References: <391a49da0805241525h1627d95m8fc0928680f12da1@mail.gmail.com>
	<20080525034301.GD70833@beekeeper.hobix.com>
Message-ID: <CCED0E15-9239-45C9-8DB4-CA63C3947D65@creativepony.com>

I forgot to mention though, the signing just stops users from changing  
the session data without the server knowing, it doesn't stop them from  
reading it. Any data in the session when using the cookie sessions  
store only needs to be base64 decoded and unmarshaled with ruby to  
find out what's inside. As far as i'm concerned, any app that's  
keeping secrets from me about me is not the kind of app I want to be  
using anyway.


On 25/05/2008, at 1:43 PM, _why wrote:

> On Sun, May 25, 2008 at 12:25:08AM +0200, Magnus Holm wrote:
>> * The cookie session is named Camping::Session and is placed in
>> camping/session.rb. Maybe this should be called  
>> Camping::CookieSession or???
>
> You know, these cookie sessions seem like they could be a problem.
> A lot of sessions would contain just the hash and the user name.
> So, spoof the user name and you're in, you know?
>
> _why
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list


From kprojection at gmail.com  Sun May 25 02:25:53 2008
From: kprojection at gmail.com (Eric Mill)
Date: Sun, 25 May 2008 02:25:53 -0400
Subject: Camping 2.0 - What's left?
In-Reply-To: <CCED0E15-9239-45C9-8DB4-CA63C3947D65@creativepony.com>
References: <391a49da0805241525h1627d95m8fc0928680f12da1@mail.gmail.com>
	<20080525034301.GD70833@beekeeper.hobix.com>
	<CCED0E15-9239-45C9-8DB4-CA63C3947D65@creativepony.com>
Message-ID: <c658be6b0805242325l4673b630l61803064aaaf68f7@mail.gmail.com>

"As far as i'm concerned, any app that's keeping secrets from me about
me is not the kind of app I want to be using anyway."

I feel like I just read this exact line somewhere else in the last few days...

-- Eric

On Sun, May 25, 2008 at 2:02 AM, Bluebie, Jenna
<blueberry at creativepony.com> wrote:
> I forgot to mention though, the signing just stops users from changing the
> session data without the server knowing, it doesn't stop them from reading
> it. Any data in the session when using the cookie sessions store only needs
> to be base64 decoded and unmarshaled with ruby to find out what's inside. As
> far as i'm concerned, any app that's keeping secrets from me about me is not
> the kind of app I want to be using anyway.
>
>
> On 25/05/2008, at 1:43 PM, _why wrote:
>
>> On Sun, May 25, 2008 at 12:25:08AM +0200, Magnus Holm wrote:
>>>
>>> * The cookie session is named Camping::Session and is placed in
>>> camping/session.rb. Maybe this should be called Camping::CookieSession
>>> or???
>>
>> You know, these cookie sessions seem like they could be a problem.
>> A lot of sessions would contain just the hash and the user name.
>> So, spoof the user name and you're in, you know?
>>
>> _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 chneukirchen at gmail.com  Sun May 25 05:38:30 2008
From: chneukirchen at gmail.com (Christian Neukirchen)
Date: Sun, 25 May 2008 11:38:30 +0200
Subject: Rack, Camping 2.0++
In-Reply-To: <391a49da0805211226y7686f4e8vf5574a308ea0e4fa@mail.gmail.com>
	(Magnus Holm's message of "Wed\, 21 May 2008 21\:26\:52 +0200")
References: <391a49da0805211226y7686f4e8vf5574a308ea0e4fa@mail.gmail.com>
Message-ID: <m2mymesoyx.fsf@gmail.com>

"Magnus Holm" <judofyr at gmail.com> writes:

> I've just finished rewriting Camping to use Rack in the "core". I got rid of
> (a little less) than 1kB in camping.rb and removed lots of un-necessary files
> (lib/server/*.rb, fastcgi.rb & mongrel.rb).

Yay!

Please tell me when rack/adapters/camping.rb can be removed.

-- 
Christian Neukirchen  <chneukirchen at gmail.com>  http://chneukirchen.org

From judofyr at gmail.com  Sun May 25 08:45:15 2008
From: judofyr at gmail.com (Magnus Holm)
Date: Sun, 25 May 2008 14:45:15 +0200
Subject: Camping 2.0 - What's left?
In-Reply-To: <20080525034301.GD70833@beekeeper.hobix.com>
References: <391a49da0805241525h1627d95m8fc0928680f12da1@mail.gmail.com>
	<20080525034301.GD70833@beekeeper.hobix.com>
Message-ID: <391a49da0805250545s7879e1f8h6ec158a63f3e575e@mail.gmail.com>

You're absolutely right. Not anymore, though. I fixed in my cs-branch.
Now it will save the data in three cookies: camping_blob, camping_hash
and camping_time. The secure_blob_hasher includes the remote IP and
the user agent, and it has also a timeout on 15 minutes (which can be overridden
with @@state_timeout).

http://github.com/judofyr/camping/commits/cs

On Sun, May 25, 2008 at 5:43 AM, _why <why at whytheluckystiff.net> wrote:
> On Sun, May 25, 2008 at 12:25:08AM +0200, Magnus Holm wrote:
>> * The cookie session is named Camping::Session and is placed in
>> camping/session.rb. Maybe this should be called Camping::CookieSession or???
>
> You know, these cookie sessions seem like they could be a problem.
> A lot of sessions would contain just the hash and the user name.
> So, spoof the user name and you're in, you know?
>
> _why
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
>



-- 
Magnus Holm

From zimbatm at oree.ch  Sun May 25 08:47:39 2008
From: zimbatm at oree.ch (zimbatm)
Date: Sun, 25 May 2008 14:47:39 +0200
Subject: Rack, Camping 2.0++
In-Reply-To: <391a49da0805211226y7686f4e8vf5574a308ea0e4fa@mail.gmail.com>
References: <391a49da0805211226y7686f4e8vf5574a308ea0e4fa@mail.gmail.com>
Message-ID: <e3caf1460805250547g579a9c6ej83593f7090d23829@mail.gmail.com>

Just wanted to comment a bit more :

2008/5/21 Magnus Holm <judofyr at gmail.com>:
> I've just finished rewriting Camping to use Rack in the "core". I got rid of
> (a little less) than 1kB in camping.rb and removed lots of un-necessary files
> (lib/server/*.rb, fastcgi.rb & mongrel.rb).

This is good ! I believe lib/camping/server.rb could be merged to
bin/camping since it's not really reusable.

> * I've removed #qsp, #un and #escape. Use Rack::Utils instead

Not sure if this is handy but let's see it in real-world usage

> ===
> 2. ORM-agnostic?
> ===

I don't mind ORM.

> ===
> 3. Cookie Sessions as default
> ===

Don't use sessions :)

> ===
> 4. Renaming camping-unabridged.rb to camping.rb?
> ===
>
> I haven't touched camping.rb at all, do we really need to prove that it's a
> micro-framework? It just makes development/releasing harder. Let's just forget
> about the abridged version and rename camping-unabridged.rb to camping.rb!

This is not that hard to do. Maybe I should add some shortening tricks document.
I propose platterizing to be done only before release.

The short version should live in the camping-mural.rb file, like the
long version lives in camping-unabridged.rb . `rake release` and `rake
devel` symlink or symlink those files to camping.rb. This should avoid
having to move things around constantly.

From blueberry at creativepony.com  Sun May 25 09:04:44 2008
From: blueberry at creativepony.com (Bluebie, Jenna)
Date: Sun, 25 May 2008 23:04:44 +1000
Subject: Camping 2.0 - What's left?
In-Reply-To: <391a49da0805250545s7879e1f8h6ec158a63f3e575e@mail.gmail.com>
References: <391a49da0805241525h1627d95m8fc0928680f12da1@mail.gmail.com>
	<20080525034301.GD70833@beekeeper.hobix.com>
	<391a49da0805250545s7879e1f8h6ec158a63f3e575e@mail.gmail.com>
Message-ID: <514C67F3-9888-4423-BF98-1317A457175F@creativepony.com>

That's no good, a significant amount of ISP's do not route requests  
from one user to one web host via the same routes on each request, and  
when they use proxy servers, as AOL does, that means every request  
comes from a different IP address, even though it's the same user.  
Worse still, the IP addresses of the proxy server's are located all  
around the world, so even geolocation fails.

Ditch the remote IP check or it wont work at all for a lot of users. I  
also feel 15 minutes is dodgy. I like session cookies, not timed  
cookies. The user closes the browser and the cookie dies, nice and  
simple. If you want to use a timeout, how about something that wont  
have any real downsides like a day or two?

The user agent is probably safe, but some plugins add text to the user  
agent, so if the user upgrades flash for instance, the session is  
instantly voided and unusable as flash's version number will change.

The only one of these which limits usefulness of cookie stealing to  
attackers is the IP check which is totally unusable in the real world  
internet. Timeouts are just annoying and I don't think extremely high  
security apps which would suit 15 minute timeouts are really the  
target audience of Camping.


?
Jenna

On 25/05/2008, at 10:45 PM, Magnus Holm wrote:

> You're absolutely right. Not anymore, though. I fixed in my cs-branch.
> Now it will save the data in three cookies: camping_blob, camping_hash
> and camping_time. The secure_blob_hasher includes the remote IP and
> the user agent, and it has also a timeout on 15 minutes (which can  
> be overridden
> with @@state_timeout).
>
> http://github.com/judofyr/camping/commits/cs
>
> On Sun, May 25, 2008 at 5:43 AM, _why <why at whytheluckystiff.net>  
> wrote:
>> On Sun, May 25, 2008 at 12:25:08AM +0200, Magnus Holm wrote:
>>> * The cookie session is named Camping::Session and is placed in
>>> camping/session.rb. Maybe this should be called  
>>> Camping::CookieSession or???
>>
>> You know, these cookie sessions seem like they could be a problem.
>> A lot of sessions would contain just the hash and the user name.
>> So, spoof the user name and you're in, you know?
>>
>> _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 judofyr at gmail.com  Sun May 25 09:56:22 2008
From: judofyr at gmail.com (Magnus Holm)
Date: Sun, 25 May 2008 15:56:22 +0200
Subject: Camping 2.0 - What's left?
In-Reply-To: <514C67F3-9888-4423-BF98-1317A457175F@creativepony.com>
References: <391a49da0805241525h1627d95m8fc0928680f12da1@mail.gmail.com>
	<20080525034301.GD70833@beekeeper.hobix.com>
	<391a49da0805250545s7879e1f8h6ec158a63f3e575e@mail.gmail.com>
	<514C67F3-9888-4423-BF98-1317A457175F@creativepony.com>
Message-ID: <391a49da0805250656m5ae0d145tfb4c88ae372405e2@mail.gmail.com>

So there isn't really any way to be safe against XSS and at the same
time support
all users? Then ignore my "patch", and we should just make it clear
that the data
is in clear-text within the cookie and you must be very careful with
validating the
input.

On Sun, May 25, 2008 at 3:04 PM, Bluebie, Jenna
<blueberry at creativepony.com> wrote:
> That's no good, a significant amount of ISP's do not route requests from one
> user to one web host via the same routes on each request, and when they use
> proxy servers, as AOL does, that means every request comes from a different
> IP address, even though it's the same user. Worse still, the IP addresses of
> the proxy server's are located all around the world, so even geolocation
> fails.
>
> Ditch the remote IP check or it wont work at all for a lot of users. I also
> feel 15 minutes is dodgy. I like session cookies, not timed cookies. The
> user closes the browser and the cookie dies, nice and simple. If you want to
> use a timeout, how about something that wont have any real downsides like a
> day or two?
>
> The user agent is probably safe, but some plugins add text to the user
> agent, so if the user upgrades flash for instance, the session is instantly
> voided and unusable as flash's version number will change.
>
> The only one of these which limits usefulness of cookie stealing to
> attackers is the IP check which is totally unusable in the real world
> internet. Timeouts are just annoying and I don't think extremely high
> security apps which would suit 15 minute timeouts are really the target
> audience of Camping.
>
>
> ?
> Jenna
>
> On 25/05/2008, at 10:45 PM, Magnus Holm wrote:
>
>> You're absolutely right. Not anymore, though. I fixed in my cs-branch.
>> Now it will save the data in three cookies: camping_blob, camping_hash
>> and camping_time. The secure_blob_hasher includes the remote IP and
>> the user agent, and it has also a timeout on 15 minutes (which can be
>> overridden
>> with @@state_timeout).
>>
>> http://github.com/judofyr/camping/commits/cs
>>
>> On Sun, May 25, 2008 at 5:43 AM, _why <why at whytheluckystiff.net> wrote:
>>>
>>> On Sun, May 25, 2008 at 12:25:08AM +0200, Magnus Holm wrote:
>>>>
>>>> * The cookie session is named Camping::Session and is placed in
>>>> camping/session.rb. Maybe this should be called Camping::CookieSession
>>>> or???
>>>
>>> You know, these cookie sessions seem like they could be a problem.
>>> A lot of sessions would contain just the hash and the user name.
>>> So, spoof the user name and you're in, you know?
>>>
>>> _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
>
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
>



-- 
Magnus Holm

From julian.tarkhanov at gmail.com  Sun May 25 10:25:37 2008
From: julian.tarkhanov at gmail.com (Julian Tarkhanov)
Date: Sun, 25 May 2008 16:25:37 +0200
Subject: Camping 2.0 - What's left?
In-Reply-To: <391a49da0805241525h1627d95m8fc0928680f12da1@mail.gmail.com>
References: <391a49da0805241525h1627d95m8fc0928680f12da1@mail.gmail.com>
Message-ID: <91C138D6-B45F-4B35-BF99-94512A6D80D8@gmail.com>


On 25 mei 2008, at 00:25, Magnus Holm wrote:

> * <insert your wish>

* Are deeply nested query arguments and tricky bits like checkbox  
arrays/param arrays handled properly (and in a Camping-compatible  
manner, AFAIK in Camping
the first parameter wins as opposed to Rails) by Rack? What happens  
with file uploads?

* I loved Camping::H too much, don't see a big deal in wrappint the  
request/env hashes into it (also to avoid substantial code scavenging)

From judofyr at gmail.com  Sun May 25 11:06:13 2008
From: judofyr at gmail.com (Magnus Holm)
Date: Sun, 25 May 2008 17:06:13 +0200
Subject: Camping 2.0 - What's left?
In-Reply-To: <91C138D6-B45F-4B35-BF99-94512A6D80D8@gmail.com>
References: <391a49da0805241525h1627d95m8fc0928680f12da1@mail.gmail.com>
	<91C138D6-B45F-4B35-BF99-94512A6D80D8@gmail.com>
Message-ID: <391a49da0805250806x155c57d6g6aed84ad20a3c49f@mail.gmail.com>

On Sun, May 25, 2008 at 4:25 PM, Julian Tarkhanov
<julian.tarkhanov at gmail.com> wrote:
>
> On 25 mei 2008, at 00:25, Magnus Holm wrote:
>
>> * <insert your wish>
>
> * Are deeply nested query arguments and tricky bits like checkbox
> arrays/param arrays handled properly (and in a Camping-compatible manner,
> AFAIK in Camping
> the first parameter wins as opposed to Rails) by Rack?

Rack doesn't do anything special with queries ending in [] and [key], so we're
cleaning it up in Base#initialize.

It works with arrays and hashes, but not perfectly when they're nested. Could
you write some examples of how they should be handled? Here's a helper to see
what Camping does today: http://pastie.caboo.se/private/53towf4gox3di0k6c8zhw

I think we could use almost the same code if we just move it out to a helper
and do some recursive magic.

>What happens with file uploads?

No idea! Maybe Christian Neukirchen can answer what Rack::Request does with
it? There isn't any file-upload specific code in Camping now.

> * I loved Camping::H too much, don't see a big deal in wrappint the
> request/env hashes into it (also to avoid substantial code scavenging)

It would be easier to remove Camping::H for good, but I like #method_missing
for getting out the values... Unless we want to get it under the 3kB-mark, I
don't think it's worth to remove it. We're far away from 4kB!

> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
>

-- 
Magnus Holm

From ernest.prabhakar at gmail.com  Sun May 25 17:45:44 2008
From: ernest.prabhakar at gmail.com (Ernest Prabhakar)
Date: Sun, 25 May 2008 14:45:44 -0700
Subject: camping-mural.rb Re: Rack, Camping 2.0++
In-Reply-To: <e3caf1460805250547g579a9c6ej83593f7090d23829@mail.gmail.com>
References: <391a49da0805211226y7686f4e8vf5574a308ea0e4fa@mail.gmail.com>
	<e3caf1460805250547g579a9c6ej83593f7090d23829@mail.gmail.com>
Message-ID: <57D31B5D-2CC5-4F5C-9DA9-A5D0C8E9193B@gmail.com>

Hi Z,

On May 25, 2008, at 5:47 AM, zimbatm wrote:

>> I haven't touched camping.rb at all, do we really need to prove  
>> that it's a
>> micro-framework? It just makes development/releasing harder. Let's  
>> just forget
>> about the abridged version and rename camping-unabridged.rb to  
>> camping.rb!
>
> This is not that hard to do. Maybe I should add some shortening  
> tricks document.
> I propose platterizing to be done only before release.
>
> The short version should live in the camping-mural.rb file, like the
> long version lives in camping-unabridged.rb . `rake release` and `rake
> devel` symlink or symlink those files to camping.rb. This should avoid
> having to move things around constantly.

I think that's a great suggestion!

-- Ernie P.

From aredridel at nbtsc.org  Sun May 25 17:45:35 2008
From: aredridel at nbtsc.org (Aria Stewart)
Date: Sun, 25 May 2008 15:45:35 -0600
Subject: Camping 2.0 - What's left?
In-Reply-To: <20080525034301.GD70833@beekeeper.hobix.com>
References: <391a49da0805241525h1627d95m8fc0928680f12da1@mail.gmail.com>
	<20080525034301.GD70833@beekeeper.hobix.com>
Message-ID: <1211751935.25558.1.camel@localhost>

On Sat, 2008-05-24 at 22:43 -0500, _why wrote:
> On Sun, May 25, 2008 at 12:25:08AM +0200, Magnus Holm wrote:
> > * The cookie session is named Camping::Session and is placed in
> > camping/session.rb. Maybe this should be called Camping::CookieSession or???
> 
> You know, these cookie sessions seem like they could be a problem.
> A lot of sessions would contain just the hash and the user name.
> So, spoof the user name and you're in, you know?

Agreed, without an HMAC signature.


From zimbatm at oree.ch  Sun May 25 18:39:43 2008
From: zimbatm at oree.ch (zimbatm)
Date: Mon, 26 May 2008 00:39:43 +0200
Subject: camping-mural.rb Re: Rack, Camping 2.0++
In-Reply-To: <57D31B5D-2CC5-4F5C-9DA9-A5D0C8E9193B@gmail.com>
References: <391a49da0805211226y7686f4e8vf5574a308ea0e4fa@mail.gmail.com>
	<e3caf1460805250547g579a9c6ej83593f7090d23829@mail.gmail.com>
	<57D31B5D-2CC5-4F5C-9DA9-A5D0C8E9193B@gmail.com>
Message-ID: <e3caf1460805251539h7ae38211j1b7e20c60b1f4601@mail.gmail.com>

2008/5/25 Ernest Prabhakar <ernest.prabhakar at gmail.com>:
> Hi Z,
>
> On May 25, 2008, at 5:47 AM, zimbatm wrote:
>
>>> I haven't touched camping.rb at all, do we really need to prove that it's
>>> a
>>> micro-framework? It just makes development/releasing harder. Let's just
>>> forget
>>> about the abridged version and rename camping-unabridged.rb to
>>> camping.rb!
>>
>> This is not that hard to do. Maybe I should add some shortening tricks
>> document.
>> I propose platterizing to be done only before release.
>>
>> The short version should live in the camping-mural.rb file, like the
>> long version lives in camping-unabridged.rb . `rake release` and `rake
>> devel` symlink or symlink those files to camping.rb. This should avoid
>> having to move things around constantly.
>
> I think that's a great suggestion!

It's now on my branch, but I named it camping-shortshort.rb

http://github.com/zimbatm/camping/tree/master

From why at whytheluckystiff.net  Sun May 25 18:45:13 2008
From: why at whytheluckystiff.net (_why)
Date: Sun, 25 May 2008 17:45:13 -0500
Subject: Rack, Camping 2.0++
In-Reply-To: <e3caf1460805250547g579a9c6ej83593f7090d23829@mail.gmail.com>
References: <391a49da0805211226y7686f4e8vf5574a308ea0e4fa@mail.gmail.com>
	<e3caf1460805250547g579a9c6ej83593f7090d23829@mail.gmail.com>
Message-ID: <20080525224513.GE70833@beekeeper.hobix.com>

On Sun, May 25, 2008 at 02:47:39PM +0200, zimbatm wrote:
> This is not that hard to do. Maybe I should add some shortening tricks document.
> I propose platterizing to be done only before release.

No, let's not have rules.  I don't feel comfortable with having
coding standards or any protocol on Camping.  The point of Camping
is to have very ugly, tricky code that goes against all the rules that
people make for "beautiful" code these days.  To show that ugly code
can do beautiful things, maybe.

I don't want to demonize anyone here, I just want to express the
ideas that make Camping different.  Camping's personality is 80x50.
It is like the little gears of a watch that are all meshed together
into a tight little mind-bending machine.  The challenge of Camping
isn't to figure out how to automate obfuscation.  The challenge is
to bring new tricks into the code that push Ruby's parser and make
everyone look twice.  Not all code needs to be a factory, some of
it can just be origami.

_why

From why at whytheluckystiff.net  Sun May 25 18:49:58 2008
From: why at whytheluckystiff.net (_why)
Date: Sun, 25 May 2008 17:49:58 -0500
Subject: Camping 2.0 - What's left?
In-Reply-To: <391a49da0805250545s7879e1f8h6ec158a63f3e575e@mail.gmail.com>
References: <391a49da0805241525h1627d95m8fc0928680f12da1@mail.gmail.com>
	<20080525034301.GD70833@beekeeper.hobix.com>
	<391a49da0805250545s7879e1f8h6ec158a63f3e575e@mail.gmail.com>
Message-ID: <20080525224958.GF70833@beekeeper.hobix.com>

On Sun, May 25, 2008 at 02:45:15PM +0200, Magnus Holm wrote:
> You're absolutely right. Not anymore, though. I fixed in my cs-branch.
> Now it will save the data in three cookies: camping_blob, camping_hash
> and camping_time. The secure_blob_hasher includes the remote IP and
> the user agent, and it has also a timeout on 15 minutes (which can be overridden
> with @@state_timeout).

Okay, this is merged.  You are swift!  But I think I agree with Jenna,
I didn't get the cookie session that well before and now I like it and
now I care.  So I might revert these changes back to the more
relaxed technique.

_why

From zimbatm at oree.ch  Sun May 25 18:51:31 2008
From: zimbatm at oree.ch (zimbatm)
Date: Mon, 26 May 2008 00:51:31 +0200
Subject: Rack, Camping 2.0++
In-Reply-To: <20080525224513.GE70833@beekeeper.hobix.com>
References: <391a49da0805211226y7686f4e8vf5574a308ea0e4fa@mail.gmail.com>
	<e3caf1460805250547g579a9c6ej83593f7090d23829@mail.gmail.com>
	<20080525224513.GE70833@beekeeper.hobix.com>
Message-ID: <e3caf1460805251551sbf170d5y862ea87838b21d45@mail.gmail.com>

2008/5/26 _why <why at whytheluckystiff.net>:
> On Sun, May 25, 2008 at 02:47:39PM +0200, zimbatm wrote:
>> This is not that hard to do. Maybe I should add some shortening tricks document.
>> I propose platterizing to be done only before release.
>
> No, let's not have rules.  I don't feel comfortable with having
> coding standards or any protocol on Camping.  The point of Camping
> is to have very ugly, tricky code that goes against all the rules that
> people make for "beautiful" code these days.  To show that ugly code
> can do beautiful things, maybe.

No ! No rules ! I was proposing to write the parchment of the grand
masters of obfuscation, giving the secret of ruby parsing intricacies
to the surviving generations of mainstream railzors. Or maybe should
it be kept away of the rubinius spec-writing minions ? I don't know.

From blueberry at creativepony.com  Sun May 25 19:04:34 2008
From: blueberry at creativepony.com (Bluebie, Jenna)
Date: Mon, 26 May 2008 09:04:34 +1000
Subject: Camping 2.0 - What's left?
In-Reply-To: <1211751935.25558.1.camel@localhost>
References: <391a49da0805241525h1627d95m8fc0928680f12da1@mail.gmail.com>
	<20080525034301.GD70833@beekeeper.hobix.com>
	<1211751935.25558.1.camel@localhost>
Message-ID: <45373472-2889-4ED9-AA11-A290A88FAA47@creativepony.com>

*quickly looks up HMAC* Sure, I guess we are doing that!

@magnus: App writers should not be encouraged to carefully validate  
the session data, the SHA256 hashing does that job. They should trust  
the data totally if they have set a good @@state_secret. Nobody can at  
any point alter the data in the hash, they can only look at it.  
Perhaps it's worth mentioning that if one is not using a technology  
like TLS (https) that it would be inappropriate to use CookieSessions  
to store passwords due to the unencrypted nature of the data, though  
in this situation, the user has probably logged in with a http request  
that involved actually sending their password in real clear text,  
where this data is a bit more obscure, base 64 encoded ruby  
marshaling, but never the less easy enough to decode by anyone who  
knows their stuff, especially if they know that the app is built using  
camping and ruby. I'd really like to encourage the use of OpenID so  
your user's never need to send you their password or other secrets,  
and thus nothing secret goes in clear text if you can't afford an SSL  
certificate. Most user's of OpenID have Identity Providers who use SSL  
when they ask for a password or similar secrets.

They can surely be sure nobody has tampered with it. Leave the  
validation to the things users can supply, not things in our HMAC- 
SHA256 verified session data.

As far as XSS goes, I've put on the wiki one simple solution: http://code.whytheluckystiff.net/camping/wiki/XssBeGoneWithSessions

But it's something we can't automate from inside camping without being  
annoying. It could potentially be automated if we included javascript  
in the output of every page that did some magic on all the links and  
forms, or if we took over every :href attribute used anywhere in  
markaby and included logic to add the query string part with the sign  
value, but if we do build this in to the core of camping, then users  
would also be forced to use sessions in their app, and it would be  
added to url's which don't need it.

The problem with XSS is simply that an attacker can make a request to  
your app from the user with their cookies all in place simply by doing  
something like: <img src="http://app.com/user_account/ 
delete_everything" />. Switching to POST doesn't help much as the  
attacker could place a form inside an iFrame and use javascript to  
post it to the address when the target user visits the page. The  
attacker cannot actually see what's in the cookie due to browser  
security policy, so it's safe for us to store a secret number in the  
session even in cookies, and require that secret number to make a  
request.

Simply, the attacker doesn't know the secret code, and the user gets a  
new one every time they login. If we applied it to all url's, the user  
would only have to paste a link to the app somewhere for the attacker  
to know the code and be able to attack them, which is why it's best  
used only on destructive actions which quickly redirect back to URL's  
which contain no signing code in their address.

The reason nobody can ever spoof a session is that they can never  
generate the needed hash because they don't have the @@state_secret  
piece of text needed to do so, hopefully! This presents a challenge  
for open source. We really need to raise an error if anyone tries to  
use CookieSessions without setting the @state_secret to something  
other than nil or "". Maybe one good solution is to add logic to  
CookieSessions so that if it is run without a @@state_secret supplied,  
it creates a file containing the state_secret, filling it with totally  
random characters. This too is a terrible security risk though, as the  
camping app may be being run in a webserver like apache or lighttpd,  
and that state_secret file generated may be readable by the web  
server. If an attacker can simply download a file telling them the  
state secret, it's game over. The only sensible default I could think  
of was the source code to the application itself, still problematic  
for open source, but would allow people to build apps without  
specifying an @state_secret and have a unique value used anyway. As  
they change the source code during development, they would be  
repeatedly signed out. I couldn't figure out a way to do this well  
with the current release of camping.


?
Jenna

On 26/05/2008, at 7:45 AM, Aria Stewart wrote:

> On Sat, 2008-05-24 at 22:43 -0500, _why wrote:
>> On Sun, May 25, 2008 at 12:25:08AM +0200, Magnus Holm wrote:
>>> * The cookie session is named Camping::Session and is placed in
>>> camping/session.rb. Maybe this should be called  
>>> Camping::CookieSession or???
>>
>> You know, these cookie sessions seem like they could be a problem.
>> A lot of sessions would contain just the hash and the user name.
>> So, spoof the user name and you're in, you know?
>
> Agreed, without an HMAC signature.
>
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list


From anibalrojas at gmail.com  Sun May 25 20:18:35 2008
From: anibalrojas at gmail.com (=?ISO-8859-1?Q?An=EDbal_Rojas?=)
Date: Sun, 25 May 2008 19:48:35 -0430
Subject: Camping 2.0 - What's left?
In-Reply-To: <45373472-2889-4ED9-AA11-A290A88FAA47@creativepony.com>
References: <391a49da0805241525h1627d95m8fc0928680f12da1@mail.gmail.com>
	<20080525034301.GD70833@beekeeper.hobix.com>
	<1211751935.25558.1.camel@localhost>
	<45373472-2889-4ED9-AA11-A290A88FAA47@creativepony.com>
Message-ID: <dd83951f0805251718k36dfe461yddd780589157f34@mail.gmail.com>

Agreed all the previous stuff...

> The reason nobody can ever spoof a session is that they can never generate
> the needed hash because they don't have the @@state_secret piece of text
> needed to do so, hopefully! This presents a challenge for open source. We
> really need to raise an error if anyone tries to use CookieSessions without
> setting the @state_secret to something other than nil or "". Maybe one good

I don't think raising a error is _required_, filling the log with a
meaningful message / advice should be enough.

> solution is to add logic to CookieSessions so that if it is run without a
> @@state_secret supplied, it creates a file containing the state_secret,
> filling it with totally random characters. This too is a terrible security
> risk though, as the camping app may be being run in a webserver like apache
> or lighttpd, and that state_secret file generated may be readable by the web
> server. If an attacker can simply download a file telling them the state
> secret, it's game over. The only sensible default I could think of was the
> source code to the application itself, still problematic for open source,
> but would allow people to build apps without specifying an @state_secret and

Interesting idea.

> have a unique value used anyway. As they change the source code during
> development, they would be repeatedly signed out. I couldn't figure out a

I think it would be more a annoyance than a real trouble for the users.
The Web in intrinsecally broken.

> way to do this well with the current release of camping.

For you idea of using the source cod (I think it could be more than
enough) I think anotehr variations could be:

- Using a directory listing of the app.
- The value of a environment variable (
- The timestamp (or something derived) of the folder containing the app.
- The path where the app is intalled
- etc

-- 
An?bal


>
> ?
> Jenna
>
> On 26/05/2008, at 7:45 AM, Aria Stewart wrote:
>
>> On Sat, 2008-05-24 at 22:43 -0500, _why wrote:
>>>
>>> On Sun, May 25, 2008 at 12:25:08AM +0200, Magnus Holm wrote:
>>>>
>>>> * The cookie session is named Camping::Session and is placed in
>>>> camping/session.rb. Maybe this should be called Camping::CookieSession
>>>> or???
>>>
>>> You know, these cookie sessions seem like they could be a problem.
>>> A lot of sessions would contain just the hash and the user name.
>>> So, spoof the user name and you're in, you know?
>>
>> Agreed, without an HMAC signature.
>>
>> _______________________________________________
>> 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  Sun May 25 20:23:31 2008
From: blueberry at creativepony.com (Bluebie, Jenna)
Date: Mon, 26 May 2008 10:23:31 +1000
Subject: Camping 2.0 - What's left?
In-Reply-To: <dd83951f0805251718k36dfe461yddd780589157f34@mail.gmail.com>
References: <391a49da0805241525h1627d95m8fc0928680f12da1@mail.gmail.com>
	<20080525034301.GD70833@beekeeper.hobix.com>
	<1211751935.25558.1.camel@localhost>
	<45373472-2889-4ED9-AA11-A290A88FAA47@creativepony.com>
	<dd83951f0805251718k36dfe461yddd780589157f34@mail.gmail.com>
Message-ID: <ACA5D167-223A-48D5-B782-481819405BCD@creativepony.com>


On 26/05/2008, at 10:18 AM, An?bal Rojas wrote:

> Agreed all the previous stuff...
>
>> The reason nobody can ever spoof a session is that they can never  
>> generate
>> the needed hash because they don't have the @@state_secret piece of  
>> text
>> needed to do so, hopefully! This presents a challenge for open  
>> source. We
>> really need to raise an error if anyone tries to use CookieSessions  
>> without
>> setting the @state_secret to something other than nil or "". Maybe  
>> one good
>
> I don't think raising a error is _required_, filling the log with a
> meaningful message / advice should be enough.
>
>> solution is to add logic to CookieSessions so that if it is run  
>> without a
>> @@state_secret supplied, it creates a file containing the  
>> state_secret,
>> filling it with totally random characters. This too is a terrible  
>> security
>> risk though, as the camping app may be being run in a webserver  
>> like apache
>> or lighttpd, and that state_secret file generated may be readable  
>> by the web
>> server. If an attacker can simply download a file telling them the  
>> state
>> secret, it's game over. The only sensible default I could think of  
>> was the
>> source code to the application itself, still problematic for open  
>> source,
>> but would allow people to build apps without specifying an  
>> @state_secret and
>
> Interesting idea.
>
>> have a unique value used anyway. As they change the source code  
>> during
>> development, they would be repeatedly signed out. I couldn't figure  
>> out a
>
> I think it would be more a annoyance than a real trouble for the  
> users.
> The Web in intrinsecally broken.
>
>> way to do this well with the current release of camping.
>
> For you idea of using the source cod (I think it could be more than
> enough) I think anotehr variations could be:
>
> - Using a directory listing of the app.
> - The value of a environment variable (
> - The timestamp (or something derived) of the folder containing the  
> app.
> - The path where the app is intalled
> - etc

I don't like any of these, it has to be something a remote attacker  
cannot find out the value to. Remote attacker could potentially get a  
directory listing, guess the value of an environment variable, find  
out the timestamp from a webserver's directory listing, and guess the  
path the app is installed to. The secret HAS to be a secret, it can't  
be something anyone else has any chance of guessing or finding out  
remotely.

>
>
> -- 
> An?bal
>
>
>>
>> ?
>> Jenna
>>
>> On 26/05/2008, at 7:45 AM, Aria Stewart wrote:
>>
>>> On Sat, 2008-05-24 at 22:43 -0500, _why wrote:
>>>>
>>>> On Sun, May 25, 2008 at 12:25:08AM +0200, Magnus Holm wrote:
>>>>>
>>>>> * The cookie session is named Camping::Session and is placed in
>>>>> camping/session.rb. Maybe this should be called  
>>>>> Camping::CookieSession
>>>>> or???
>>>>
>>>> You know, these cookie sessions seem like they could be a problem.
>>>> A lot of sessions would contain just the hash and the user name.
>>>> So, spoof the user name and you're in, you know?
>>>
>>> Agreed, without an HMAC signature.
>>>
>>> _______________________________________________
>>> 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  Sun May 25 21:26:38 2008
From: anibalrojas at gmail.com (=?ISO-8859-1?Q?An=EDbal_Rojas?=)
Date: Mon, 26 May 2008 20:56:38 +1930
Subject: Camping 2.0 - What's left?
In-Reply-To: <ACA5D167-223A-48D5-B782-481819405BCD@creativepony.com>
References: <391a49da0805241525h1627d95m8fc0928680f12da1@mail.gmail.com>
	<20080525034301.GD70833@beekeeper.hobix.com>
	<1211751935.25558.1.camel@localhost>
	<45373472-2889-4ED9-AA11-A290A88FAA47@creativepony.com>
	<dd83951f0805251718k36dfe461yddd780589157f34@mail.gmail.com>
	<ACA5D167-223A-48D5-B782-481819405BCD@creativepony.com>
Message-ID: <dd83951f0805251826k2e8c993bmc1c19268d45e4556@mail.gmail.com>

Yes, but the idea is using this as default, and warning about it.

Any webdeveloper lazy enough to ignore 1st The instructions, 2nd the
warnings is beyond any help.

A framework can't replace intelligence

On Mon, May 26, 2008 at 7:53 PM, Bluebie, Jenna
<blueberry at creativepony.com> wrote:
>
> On 26/05/2008, at 10:18 AM, An?bal Rojas wrote:
>
>> Agreed all the previous stuff...
>>
>>> The reason nobody can ever spoof a session is that they can never
>>> generate
>>> the needed hash because they don't have the @@state_secret piece of text
>>> needed to do so, hopefully! This presents a challenge for open source. We
>>> really need to raise an error if anyone tries to use CookieSessions
>>> without
>>> setting the @state_secret to something other than nil or "". Maybe one
>>> good
>>
>> I don't think raising a error is _required_, filling the log with a
>> meaningful message / advice should be enough.
>>
>>> solution is to add logic to CookieSessions so that if it is run without a
>>> @@state_secret supplied, it creates a file containing the state_secret,
>>> filling it with totally random characters. This too is a terrible
>>> security
>>> risk though, as the camping app may be being run in a webserver like
>>> apache
>>> or lighttpd, and that state_secret file generated may be readable by the
>>> web
>>> server. If an attacker can simply download a file telling them the state
>>> secret, it's game over. The only sensible default I could think of was
>>> the
>>> source code to the application itself, still problematic for open source,
>>> but would allow people to build apps without specifying an @state_secret
>>> and
>>
>> Interesting idea.
>>
>>> have a unique value used anyway. As they change the source code during
>>> development, they would be repeatedly signed out. I couldn't figure out a
>>
>> I think it would be more a annoyance than a real trouble for the users.
>> The Web in intrinsecally broken.
>>
>>> way to do this well with the current release of camping.
>>
>> For you idea of using the source cod (I think it could be more than
>> enough) I think anotehr variations could be:
>>
>> - Using a directory listing of the app.
>> - The value of a environment variable (
>> - The timestamp (or something derived) of the folder containing the app.
>> - The path where the app is intalled
>> - etc
>
> I don't like any of these, it has to be something a remote attacker cannot
> find out the value to. Remote attacker could potentially get a directory
> listing, guess the value of an environment variable, find out the timestamp
> from a webserver's directory listing, and guess the path the app is
> installed to. The secret HAS to be a secret, it can't be something anyone
> else has any chance of guessing or finding out remotely.
>
>>
>>
>> --
>> An?bal
>>
>>
>>>
>>> ?
>>> Jenna
>>>
>>> On 26/05/2008, at 7:45 AM, Aria Stewart wrote:
>>>
>>>> On Sat, 2008-05-24 at 22:43 -0500, _why wrote:
>>>>>
>>>>> On Sun, May 25, 2008 at 12:25:08AM +0200, Magnus Holm wrote:
>>>>>>
>>>>>> * The cookie session is named Camping::Session and is placed in
>>>>>> camping/session.rb. Maybe this should be called Camping::CookieSession
>>>>>> or???
>>>>>
>>>>> You know, these cookie sessions seem like they could be a problem.
>>>>> A lot of sessions would contain just the hash and the user name.
>>>>> So, spoof the user name and you're in, you know?
>>>>
>>>> Agreed, without an HMAC signature.
>>>>
>>>> _______________________________________________
>>>> 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
>



-- 
An?bal

From why at whytheluckystiff.net  Mon May 26 00:45:09 2008
From: why at whytheluckystiff.net (_why)
Date: Sun, 25 May 2008 23:45:09 -0500
Subject: Camping 2.0 - What's left?
In-Reply-To: <dd83951f0805251826k2e8c993bmc1c19268d45e4556@mail.gmail.com>
References: <391a49da0805241525h1627d95m8fc0928680f12da1@mail.gmail.com>
	<20080525034301.GD70833@beekeeper.hobix.com>
	<1211751935.25558.1.camel@localhost>
	<45373472-2889-4ED9-AA11-A290A88FAA47@creativepony.com>
	<dd83951f0805251718k36dfe461yddd780589157f34@mail.gmail.com>
	<ACA5D167-223A-48D5-B782-481819405BCD@creativepony.com>
	<dd83951f0805251826k2e8c993bmc1c19268d45e4556@mail.gmail.com>
Message-ID: <20080526044508.GG70833@beekeeper.hobix.com>

On Mon, May 26, 2008 at 08:56:38PM +1930, An?bal Rojas wrote:
> Yes, but the idea is using this as default, and warning about it.

Then your idea of using `pwd` is pretty good, since it's not
immediately obvious.  Or the timestamp of $0 might be good.  If the
timestamp (or the path) changes, then the sessions merely expire.
I guess that's good enough with the warnings there, too.

_why

From blueberry at creativepony.com  Mon May 26 01:41:45 2008
From: blueberry at creativepony.com (Bluebie, Jenna)
Date: Mon, 26 May 2008 15:41:45 +1000
Subject: Camping 2.0 - What's left?
In-Reply-To: <20080526044508.GG70833@beekeeper.hobix.com>
References: <391a49da0805241525h1627d95m8fc0928680f12da1@mail.gmail.com>
	<20080525034301.GD70833@beekeeper.hobix.com>
	<1211751935.25558.1.camel@localhost>
	<45373472-2889-4ED9-AA11-A290A88FAA47@creativepony.com>
	<dd83951f0805251718k36dfe461yddd780589157f34@mail.gmail.com>
	<ACA5D167-223A-48D5-B782-481819405BCD@creativepony.com>
	<dd83951f0805251826k2e8c993bmc1c19268d45e4556@mail.gmail.com>
	<20080526044508.GG70833@beekeeper.hobix.com>
Message-ID: <65C566FD-E3DF-440D-853A-0BB0C32D9EBA@creativepony.com>

Yeah, I suppose that's reasonable.. the timestamp even on The Camping  
Server and stuff would still be unique to the system.. it's a short  
secret, but it's better than nothing. Warnings and defaulting to that  
sounds like a good idea to me!

I beg to differ on those who don't follow instructions and don't  
listen to warnings being beyond help. There should be a good default. :)

I frequently don't follow instructions!


On 26/05/2008, at 2:45 PM, _why wrote:

> On Mon, May 26, 2008 at 08:56:38PM +1930, An?bal Rojas wrote:
>> Yes, but the idea is using this as default, and warning about it.
>
> Then your idea of using `pwd` is pretty good, since it's not
> immediately obvious.  Or the timestamp of $0 might be good.  If the
> timestamp (or the path) changes, then the sessions merely expire.
> I guess that's good enough with the warnings there, too.
>
> _why
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list


From anibalrojas at gmail.com  Mon May 26 10:26:26 2008
From: anibalrojas at gmail.com (=?ISO-8859-1?Q?An=EDbal_Rojas?=)
Date: Tue, 27 May 2008 09:56:26 +1930
Subject: Camping 2.0 - What's left?
In-Reply-To: <65C566FD-E3DF-440D-853A-0BB0C32D9EBA@creativepony.com>
References: <391a49da0805241525h1627d95m8fc0928680f12da1@mail.gmail.com>
	<20080525034301.GD70833@beekeeper.hobix.com>
	<1211751935.25558.1.camel@localhost>
	<45373472-2889-4ED9-AA11-A290A88FAA47@creativepony.com>
	<dd83951f0805251718k36dfe461yddd780589157f34@mail.gmail.com>
	<ACA5D167-223A-48D5-B782-481819405BCD@creativepony.com>
	<dd83951f0805251826k2e8c993bmc1c19268d45e4556@mail.gmail.com>
	<20080526044508.GG70833@beekeeper.hobix.com>
	<65C566FD-E3DF-440D-853A-0BB0C32D9EBA@creativepony.com>
Message-ID: <dd83951f0805260726m28018567wcffeaddfd3768cef@mail.gmail.com>

Me neither ;-) And talking about instructions, the Wiki will need a
Extreme Make Over to catch up with the code.

-- 
An?bal

On Tue, May 27, 2008 at 1:11 AM, Bluebie, Jenna
<blueberry at creativepony.com> wrote:
> Yeah, I suppose that's reasonable.. the timestamp even on The Camping Server
> and stuff would still be unique to the system.. it's a short secret, but
> it's better than nothing. Warnings and defaulting to that sounds like a good
> idea to me!
>
> I beg to differ on those who don't follow instructions and don't listen to
> warnings being beyond help. There should be a good default. :)
>
> I frequently don't follow instructions!
>
>
> On 26/05/2008, at 2:45 PM, _why wrote:
>
>> On Mon, May 26, 2008 at 08:56:38PM +1930, An?bal Rojas wrote:
>>>
>>> Yes, but the idea is using this as default, and warning about it.
>>
>> Then your idea of using `pwd` is pretty good, since it's not
>> immediately obvious.  Or the timestamp of $0 might be good.  If the
>> timestamp (or the path) changes, then the sessions merely expire.
>> I guess that's good enough with the warnings there, too.
>>
>> _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 john.beppu at gmail.com  Tue May 27 00:24:35 2008
From: john.beppu at gmail.com (John Beppu)
Date: Mon, 26 May 2008 21:24:35 -0700
Subject: Camping Technique -- Multiple Layouts
Message-ID: <21a10fe00805262124v79e7fb7eme4b590f60a5c5ba4@mail.gmail.com>

Hey Campers,

Here's a little technique you can use to support multiple layouts within a
Camping app.

def layout
  @layout ||= 'default'
  send("#{@layout}_layout") { yield }
end

The minimum you have to do after this is define a *default_layout*, but (as
you can hopefully see) you may define any number of arbitrary layouts to
wrap your content in.

Just set *@layout* in your controllers, and when it comes time to render a
view, be sure a layout w/ the name "#{@layout}_layout" exists.

--beppu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/camping-list/attachments/20080526/419861f2/attachment.html>

From ironald at gmail.com  Tue May 27 01:05:22 2008
From: ironald at gmail.com (ronald.evangelista)
Date: Tue, 27 May 2008 13:05:22 +0800
Subject: Camping Technique -- Multiple Layouts
In-Reply-To: <21a10fe00805262124v79e7fb7eme4b590f60a5c5ba4@mail.gmail.com>
References: <21a10fe00805262124v79e7fb7eme4b590f60a5c5ba4@mail.gmail.com>
Message-ID: <483B9692.7010700@gmail.com>

cool! i'll try that.

From aredridel at nbtsc.org  Tue May 27 14:28:56 2008
From: aredridel at nbtsc.org (Aria Stewart)
Date: Tue, 27 May 2008 12:28:56 -0600
Subject: An issue for consideration
In-Reply-To: <20080523232134.GA7506@nyarlathotep.necronomicorp.com>
References: <DE066578-B2FC-4BAE-8BBD-E70884493E49@creativepony.com>
	<1DEA639B-BD9D-4B59-AA89-4C013497F3E3@creativepony.com>
	<20080523232134.GA7506@nyarlathotep.necronomicorp.com>
Message-ID: <67595D08-8BFE-4786-8E6B-1B7986567CD3@nbtsc.org>


On May 23, 2008, at 5:21 PM, Brendan Taylor wrote:
>
> You missed PUT :)
>
> I can imagine situations where you'd want to be able to use more
> esoteric HTTP methods (like OPTIONS, or any of WebDAV's many extension
> methods). I don't have a better solution though, and this may be Good
> Enough?.

Indeed. I have a CalDAV server started using Camping as a basis.

From ironald at gmail.com  Wed May 28 12:18:19 2008
From: ironald at gmail.com (ronald.evangelista)
Date: Thu, 29 May 2008 00:18:19 +0800
Subject: Plug-in support for Camping Apps
Message-ID: <483D85CB.3070902@gmail.com>

# camping_plugin.rb
# plug-in support for Camping Apps
# require 'lib/camping_plugin'
# override R helper method to your liking :-)

module Camping
   module PluginHelpers
      def R_with_module(c,*g)
         p,h=/\(.+?\)/,g.grep(Hash)
         g-=h
         raise "bad route" unless u = c.urls.find{|x|
            break x if x.scan(p).size == g.size &&
            /^#{x}\/?$/ =~ (x=g.inject(x){|x,a|
            x.sub p,C.escape((a[a.class.primary_key]rescue a))})
         }
         if h.any?
            l = proc{|_,o,n|o.u(n,&m)rescue([*o]<<n)}
            h[0].values.grep(Hash).each{ |a|
               k, v = h[0].index(a), a
               h[0].u( h[0].delete(k).inject(H[]){|m, a|
               m.u( H[[k,a[0]].join("[")<<"]", a[1]], &l)}, &l)
            }
            h[0].rehash

            u+"?"+h[0].map{|x|
               k, v = x
               Array===v ? v.map{|v2| [k, v2].map{|z| C.escape z}*"="} * 
"&" : x.map{|z| C.escape z}*"="
            }*"&"
         else
            u
         end
      end
   end
end
#init plug-in
Camping::Helpers.send(:include, Camping::PluginHelpers)
Camping::Helpers.class_eval { alias_method_chain :R, :module }


From john.beppu at gmail.com  Wed May 28 13:23:33 2008
From: john.beppu at gmail.com (John Beppu)
Date: Wed, 28 May 2008 10:23:33 -0700
Subject: Plug-in support for Camping Apps
In-Reply-To: <483D85CB.3070902@gmail.com>
References: <483D85CB.3070902@gmail.com>
Message-ID: <21a10fe00805281023h72e69ab9lde8ae99b07b4829@mail.gmail.com>

What does this do?  Can you give an example of how someone might use this?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/camping-list/attachments/20080528/4c184cd4/attachment.html>

From ironald at gmail.com  Thu May 29 11:48:35 2008
From: ironald at gmail.com (ronald.evangelista)
Date: Thu, 29 May 2008 23:48:35 +0800
Subject: Plug-in support for Camping Apps
In-Reply-To: <21a10fe00805281023h72e69ab9lde8ae99b07b4829@mail.gmail.com>
References: <21a10fe00805281023h72e69ab9lde8ae99b07b4829@mail.gmail.com>
Message-ID: <483ED053.30106@gmail.com>

in theory it should be as easy as that, ...  ala-rails.
would be nice to have genuine support for plug-ins .
will peruse zimbatm's 'equipment' to get more inspiration
or maybe we can set a standard on how to add Camping plug-ins.

anyway, this is how i've used it:   'quick n dirty '

# helpers_plugin.rb
# it would be nice to have a genuine support for plugins
# plug-in support for Camping Apps to override original Camping::Helper 
methods
# otherwise you can only override methods if you code directly into your 
App::Helpers
# like so:
#
# module App::Helpers
#  def R(c, *g)
#     ":-)"
#  end
# end
#
# why? check out 
http://rubyforge.org/pipermail/camping-list/2007-November/000545.html by 
zimbatm
#
#  pseudo-flattens a hash
# {"nested_params"=>{"a"=>"1", "b"=>["1", "2", "3"]}, "param1"=>"10", 
"param2"=>"1..10"}.flatten
# >> {"nested_params[b]"=>[1, 2, 3], "nested_params[a]"=>1, 
"param1"=>10, "param2"=>1..10}
class Hash
   def flatten
      m = proc{|_,o,n|o.u(n,&m)rescue([*o]+[n].flatten)}
      values.grep(Hash).each do |a|
         k, v = index(a), a
         u(delete(k).inject(Hash[]){|h, a|
         h.u(Hash[[k,a[0]].join("[")<<"]", a[1]], &m)},
         &m)
      end
      rehash
   end
   alias_method :u, :merge!
end
# required/loaded after the camping library to work
module Camping
   module PluginHelpers
      # override R helper method to your liking :-)
      def R_with_plugin(c,*g)
         p,h=/\(.+?\)/,g.grep(Hash)
         g-=h
         raise "bad route" unless u = c.urls.find{|x|
            break x if x.scan(p).size == g.size &&
            /^#{x}\/?$/ =~ (x=g.inject(x){|x,a|
            x.sub p,C.escape((a[a.class.primary_key]rescue a))})
         }
         h.any? ? u+"?"+h[0].flatten.map{|x|
               k, v = x
               Array===v ? v.map{|v2| [k, v2].map{|z| C.escape z}*"="} * 
"&" : x.map{|z| C.escape z}*"=" }*"&" : u
      end
   end
end

# in your app:
# %w[camping  camping/session lib/plugins/helpers_plugin pp].each{|l| 
require  l}
#  use Camping.makes method instead of goes
#
# Camping.makes :MyApp, :plugins=>[:plugin_helpers]
#
#    R in your views
#    you can now use nested hash params
#    a 'view', :href=>R(ViewPost, post, 'param1'=>10, 'param2'=>1..10, 
'nested_params'=>{'a'=>1, 'b'=>[1, 2, 3]})
#    ...
#
#    check values of @input
#
#    class ViewPost < R '/post/(\d+)', '/post/(\d+)/(\w+)'
#      include PostHelper
#      def get(id, action=nil)
#         @post = model_class.find(id)
#         pp input # >> {"nested_params"=>{"a"=>"1", "b"=>["1", "2", 
"3"]},  "param1"=>"10",  "param2"=>"1..10"}
#                  # original R implementation returns 
{"nested_params"=>"a1b123", "param1"=>"10", "param2"=>"1..10"}
#                  #
#        @params = @input # then you can pass em around like form data 
perhaps changing values, ie 'page'=>999
#         case action
#         when 'edit'
#            render :update_post
#         else
#            render :view_post
#         end
#      end
#   end

module Camping
   def self.makes(*a)
      h = a.grep(Hash)
      a-=h
      app = a.shift
      Camping.goes app
      @App=const_get( app.to_s)
      h.pop[:plugins].each{|s| self.load_plugin s} if h.any?
   end
   def self.load_plugin(symbol)
      plugin_module = "Camping::#{symbol.to_s.camelize}".constantize
      @App::Helpers.send(:include, plugin_module)
      @App::Helpers.module_eval {
         plugin_module.instance_methods.map{|m|
            target_method = m.gsub(/_with_plugin/,'')
            alias_method_chain(target_method, :plugin) if 
instance_methods.include?(target_method)
         }
      }
   end
end


From judofyr at gmail.com  Fri May 30 08:38:14 2008
From: judofyr at gmail.com (Magnus Holm)
Date: Fri, 30 May 2008 14:38:14 +0200
Subject: Plug-in support for Camping Apps
In-Reply-To: <483ED053.30106@gmail.com>
References: <21a10fe00805281023h72e69ab9lde8ae99b07b4829@mail.gmail.com>
	<483ED053.30106@gmail.com>
Message-ID: <391a49da0805300538o376190c7td640aa8b7ad7a3f1@mail.gmail.com>

Why not just do something like this?

  require 'camping'
  require 'awesome_plugin
  Camping.goes :Example
  Example.needs AwesomePlugin

  # needs is defined as:
  module Camping
    def self.needs(m)
      include(m)
    end
  end

  # The plugin:
  module AwesomePlugin
    def service(*a)
      # Do some stuff
      super(*a)
    end
  end

On Thu, May 29, 2008 at 5:48 PM, ronald.evangelista <ironald at gmail.com> wrote:
> in theory it should be as easy as that, ...  ala-rails.
> would be nice to have genuine support for plug-ins .
> will peruse zimbatm's 'equipment' to get more inspiration
> or maybe we can set a standard on how to add Camping plug-ins.
>
> anyway, this is how i've used it:   'quick n dirty '
>
> # helpers_plugin.rb
> # it would be nice to have a genuine support for plugins
> # plug-in support for Camping Apps to override original Camping::Helper
> methods
> # otherwise you can only override methods if you code directly into your
> App::Helpers
> # like so:
> #
> # module App::Helpers
> #  def R(c, *g)
> #     ":-)"
> #  end
> # end
> #
> # why? check out
> http://rubyforge.org/pipermail/camping-list/2007-November/000545.html by
> zimbatm
> #
> #  pseudo-flattens a hash
> # {"nested_params"=>{"a"=>"1", "b"=>["1", "2", "3"]}, "param1"=>"10",
> "param2"=>"1..10"}.flatten
> # >> {"nested_params[b]"=>[1, 2, 3], "nested_params[a]"=>1, "param1"=>10,
> "param2"=>1..10}
> class Hash
>  def flatten
>     m = proc{|_,o,n|o.u(n,&m)rescue([*o]+[n].flatten)}
>     values.grep(Hash).each do |a|
>        k, v = index(a), a
>        u(delete(k).inject(Hash[]){|h, a|
>        h.u(Hash[[k,a[0]].join("[")<<"]", a[1]], &m)},
>        &m)
>     end
>     rehash
>  end
>  alias_method :u, :merge!
> end
> # required/loaded after the camping library to work
> module Camping
>  module PluginHelpers
>     # override R helper method to your liking :-)
>     def R_with_plugin(c,*g)
>        p,h=/\(.+?\)/,g.grep(Hash)
>        g-=h
>        raise "bad route" unless u = c.urls.find{|x|
>           break x if x.scan(p).size == g.size &&
>           /^#{x}\/?$/ =~ (x=g.inject(x){|x,a|
>           x.sub p,C.escape((a[a.class.primary_key]rescue a))})
>        }
>        h.any? ? u+"?"+h[0].flatten.map{|x|
>              k, v = x
>              Array===v ? v.map{|v2| [k, v2].map{|z| C.escape z}*"="} * "&" :
> x.map{|z| C.escape z}*"=" }*"&" : u
>     end
>  end
> end
>
> # in your app:
> # %w[camping  camping/session lib/plugins/helpers_plugin pp].each{|l|
> require  l}
> #  use Camping.makes method instead of goes
> #
> # Camping.makes :MyApp, :plugins=>[:plugin_helpers]
> #
> #    R in your views
> #    you can now use nested hash params
> #    a 'view', :href=>R(ViewPost, post, 'param1'=>10, 'param2'=>1..10,
> 'nested_params'=>{'a'=>1, 'b'=>[1, 2, 3]})
> #    ...
> #
> #    check values of @input
> #
> #    class ViewPost < R '/post/(\d+)', '/post/(\d+)/(\w+)'
> #      include PostHelper
> #      def get(id, action=nil)
> #         @post = model_class.find(id)
> #         pp input # >> {"nested_params"=>{"a"=>"1", "b"=>["1", "2", "3"]},
>  "param1"=>"10",  "param2"=>"1..10"}
> #                  # original R implementation returns
> {"nested_params"=>"a1b123", "param1"=>"10", "param2"=>"1..10"}
> #                  #
> #        @params = @input # then you can pass em around like form data
> perhaps changing values, ie 'page'=>999
> #         case action
> #         when 'edit'
> #            render :update_post
> #         else
> #            render :view_post
> #         end
> #      end
> #   end
>
> module Camping
>  def self.makes(*a)
>     h = a.grep(Hash)
>     a-=h
>     app = a.shift
>     Camping.goes app
>     @App=const_get( app.to_s)
>     h.pop[:plugins].each{|s| self.load_plugin s} if h.any?
>  end
>  def self.load_plugin(symbol)
>     plugin_module = "Camping::#{symbol.to_s.camelize}".constantize
>     @App::Helpers.send(:include, plugin_module)
>     @App::Helpers.module_eval {
>        plugin_module.instance_methods.map{|m|
>           target_method = m.gsub(/_with_plugin/,'')
>           alias_method_chain(target_method, :plugin) if
> instance_methods.include?(target_method)
>        }
>     }
>  end
> end
>
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
>



-- 
Magnus Holm