On Sun, 2009-04-19 at 22:14 -0500, Luke Kanies wrote:
> +1, comment below
>
> On Apr 19, 2009, at 11:38 AM, Brice Figureau wrote:
>
> >
> > Signed-off-by: Brice Figureau
> > ---
> > lib/puppet/network/http/mongrel/rest.rb |7 +++
> > lib/puppet/network/http/webrick/rest.rb |8 +++
On Apr 19, 2009, at 1:51 PM, Christian Hofstaedtler wrote:
>
> From: Christian Hofstaedtler
>
> This lays the ground: a wrapper for the REST handler, and an
> application
> confirming to the Rack standard.
>
> Signed-off-by: Christian Hofstaedtler
> ---
> lib/puppet/feature/base.rb
+1
On Apr 19, 2009, at 11:59 AM, Brice Figureau wrote:
>
> The target generation was wrong, as it created some
> strange target for isolated test files.
> It now creates two types of targets:
>
> * directory targets, like:
> rake integration/network/server
> or
> rake unit/network
>
> Those run
+1
On Apr 19, 2009, at 11:58 AM, Brice Figureau wrote:
>
> Since the introduction of fixing RSpec to 1.2.2, we don't
> support anymore running RSpec directly ala:
>
> ruby spec/unit/type.rb
> or
> spec/unit/type.rb
>
> This patch fixes this.
>
> Signed-off-by: Brice Figureau
> ---
> spec/spec_h
+1
On Apr 19, 2009, at 11:38 AM, Brice Figureau wrote:
>
> Introduces a new auth.conf directive (auth or authenticated) which
> takes an argument (on,yes/off,no).
> This can be used to restrict an ACL to only some state of
> authentication of a REST request.
> If no auth directive is given, both
Very nice. A couple of comments below.
On Apr 19, 2009, at 11:38 AM, Brice Figureau wrote:
>
> Before this change, unauthenticated REST requests where
> inconditionnaly
> allowed, as long as they were to the certificate terminus.
> This could be a security hole, so now the REST requests, auth
+1, comment below
On Apr 19, 2009, at 11:38 AM, Brice Figureau wrote:
>
> Signed-off-by: Brice Figureau
> ---
> lib/puppet/network/http/mongrel/rest.rb |7 +++
> lib/puppet/network/http/webrick/rest.rb |8
> spec/unit/network/http/mongrel/rest.rb |5 +++--
> spec/unit/net
+1, a couple of comments below.
On Apr 19, 2009, at 11:38 AM, Brice Figureau wrote:
>
> The idea is to raise an AuthorizationException at the same place
> we check the authorization instead of in an upper level to be
> able to spot where the authorization took place in the exception
> backtrace.
On Apr 19, 2009, at 9:15 AM, Brice Figureau wrote:
>
> Hi,
>
> I'm trying to implement Luke's latest comment on #1875: where
> authenticated and unauthenticated requests should follow the same code
> path (ie there are ACL for authenticated and unauthenticated
> requests),
> instead of simply a
On Apr 19, 2009, at 12:05 AM, James Turnbull wrote:
>
> My issue is troubleshooting. Puppet is somewhat famous for some fairly
> cryptic error messages. I can see #2 being a real bloody nightmare to
> fix issues with. So I am not against the concept but error handling
> would need to be enhanced
* Paul Nasrat [090419 22:38]:
>
> 2009/4/19 Christian Hofstaedtler :
> > Brice asked me to refresh Rack support in Puppet, especially with regard to
> > the new REST handlers. While Puppet 0.24.6+ already has support for REST
> > (with XMLRPC), I felt that it would be better to start fresh.
>
>
2009/4/19 Christian Hofstaedtler :
>
>
> Bruce asked me to refresh Rack support in Puppet, especially with regard to
> the new REST handlers. While Puppet 0.24.6+ already has support for REST
> (with XMLRPC), I felt that it would be better to start fresh.
Can you make your branch tickets/1909:
h
2009/4/19 Christian Hofstaedtler :
>
> Integrating rack nicely has multiple aspects, and I seek input on
> all of them:
>
> * Passenger (AKA mod_rails for Apache) shall again be supported
> (see wiki:UsingPassenger). Passenger obviously expects rack applications
> to completely follow the rack spe
Integrating rack nicely has multiple aspects, and I seek input on
all of them:
* Passenger (AKA mod_rails for Apache) shall again be supported
(see wiki:UsingPassenger). Passenger obviously expects rack applications
to completely follow the rack specification, including the need for
a "config.r
From: Christian Hofstaedtler
This lays the ground: a wrapper for the REST handler, and an application
confirming to the Rack standard.
Signed-off-by: Christian Hofstaedtler
---
lib/puppet/feature/base.rb |3 +
lib/puppet/network/http/rack.rb | 45 +++
lib/puppet/netwo
Bruce asked me to refresh Rack support in Puppet, especially with regard to
the new REST handlers. While Puppet 0.24.6+ already has support for REST
(with XMLRPC), I felt that it would be better to start fresh.
0001-Puppet-as-a-Rack-application adds a true Rack application class, which
just d
From: Christian Hofstaedtler
As RackREST will not stay the only handler for HTTP requests via Rack,
we make the required interface explicit by providing a base class and
moving the client authentication there.
Signed-off-by: Christian Hofstaedtler
---
lib/puppet/network/http/rack/httphandler.
From: Christian Hofstaedtler
Signed-off-by: Christian Hofstaedtler
---
lib/puppet/network/http/rack.rb| 21 -
lib/puppet/network/http/rack/xmlrpc.rb | 46
spec/unit/network/http/rack.rb | 29 +-
spec/unit/network/http/rack/xmlrpc.rb | 182 +
>>
>>
>>
>> IMHO, one of Puppet's overall goals in modeling the sysadmin domain
>> is
>> to try to make it as hard as possible to lead down unexpected paths.
>
> Heh. I find this a bit funny since it was at your request that I
> filed this ticket and implemented this work. :)
>>
Hey I just me
The target generation was wrong, as it created some
strange target for isolated test files.
It now creates two types of targets:
* directory targets, like:
rake integration/network/server
or
rake unit/network
Those run all tests in a specific directory
* spec targets like:
rake unit:indirector:
Since the introduction of fixing RSpec to 1.2.2, we don't
support anymore running RSpec directly ala:
ruby spec/unit/type.rb
or
spec/unit/type.rb
This patch fixes this.
Signed-off-by: Brice Figureau
---
spec/spec_helper.rb |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --gi
The idea is to raise an AuthorizationException at the same place
we check the authorization instead of in an upper level to be
able to spot where the authorization took place in the exception
backtrace.
Moreover, this changes also makes Rights::allowed? to return
the matching acl so that the uppe
Signed-off-by: Brice Figureau
---
lib/puppet/network/http/mongrel/rest.rb |7 +++
lib/puppet/network/http/webrick/rest.rb |8
spec/unit/network/http/mongrel/rest.rb |5 +++--
spec/unit/network/http/webrick/rest.rb |7 +--
4 files changed, 23 insertions(+), 4 de
Before this change, unauthenticated REST requests where inconditionnaly
allowed, as long as they were to the certificate terminus.
This could be a security hole, so now the REST requests, authenticated
or unauthenticated are all submitted to the REST authorization
layer.
The default authorizations
Introduces a new auth.conf directive (auth or authenticated) which
takes an argument (on,yes/off,no).
This can be used to restrict an ACL to only some state of
authentication of a REST request.
If no auth directive is given, both type of requests are used.
Signed-off-by: Brice Figureau
---
lib/
Hi,
I'm resending only patch from 08 to 11, as the 7 first patches didn't change.
Changelog since v2:
* patch 08: I moved as deeply as possible the place where we throw the
AuthorizationError
on deny so that we don't have to leak private structures to the outside just to
get information
abou
Hi,
I'm trying to implement Luke's latest comment on #1875: where
authenticated and unauthenticated requests should follow the same code
path (ie there are ACL for authenticated and unauthenticated requests),
instead of simply allowing unauthenticated requests for the certificate
access as I
Hello everyone,
I am working on developing a monit provider for puppet but I seem to
have run into a (simple) issue.
I have defined a new property called "pid" which I want to be able to
specify in site.pp
Here's my current site.pp
node default
{
monit
{
"mongrel":
pid = > "manish",
28 matches
Mail list logo
