DigestAuthorizerContributor hard coded WWW-Authenticate response

[Greg Sochanik]

Hi,

I'm about half way through my implementation of OAuth in OpenRasta. Have gone down the [RequiresOAuth] attribute route in a straight copy of the OpenRasta.Security.RequiresAuthenticationAttribute model which I thought was a terrific way of implementing it in a "per-method" scenario.

Only problem is.... DigestAuthorizerContributor is automatically set up as an IPipelineContributor and it manually overwrites the WWW-Authenticate response header with Digest Authentication if context.OperationResult is OperationResult.Unauthorized, which it is if you aren't able to authorize.

Now, I saw this: http://trac.caffeine-it.com/openrasta/ticket/118#comment:1, but the url to the commit gives me a 404. 

So, that leaves me with 3 options that I can see:

1. Create my own OperationResult (which I really don't want to do)

2. Figure out a way to stop DigestAuthorizerContributor from running.

3. Try and track down the above commit.

Anybody know if there's a way I can do option number 2? 

Has this been fixed elsewhere?

Any other ideas that may help me?

Cheers,

Greg

[Bob Gregory]

We use Castle as our IOC framework. YMMV.

1) Setup Castle as your dependency resolver by implementing IDependencyResolverAccessor

public class foo : IDependencyResolverAccessor

{

   public IDependencyResolver Resolver

        {

            get

            {

                return new WindsorDependencyResolver(Container);

            }

        }

}

2) In your configure method, remove the dependency from the pipeline.

 public static void RemoveDigestAuthorisationContributor(IWindsorContainer container)

        {

            var contributors = container.Kernel.GetHandlers(typeof(IPipelineContributor));

            var digestContributor = contributors.SingleOrDefault(i => i.ComponentModel.Implementation == typeof(DigestAuthorizerContributor));

            container.Kernel.RemoveComponent(digestContributor.ComponentModel.Name);

        }

Alternatively, you can implement your own DependencyRegistrar. We've recently done this in order to mess about with the ICodecRepository implementation, but that's more work and probably not indicated in your use case.

 -- Bob

--
An infinite number of mathematicians walk into a bar. The first one orders a beer. The second orders half a beer. The third, a quarter of a beer. The bartender says "You're all idiots", and pours two beers.

[Bob Gregory]

The missing point from that mail is: because OR uses dependency injection, you can remove the contributor entirely from the container. If you're using an existing container - castle, ninject, autofac, whatever - then it's pretty trivial, otherwise you can play around with the registrar.

I *might* submit a new registrar at some point with some extra hooks for doing that kinda interception, but don't hold your breath.

 -- B

[Greg Sochanik]

Ahh - just thought of something. The container that actually has the DigestAuthorizerContributor is the OpenRasta one, not my custom Dependency resolver one.

How do I hook into the OpenRasta container to remove DigestAuthorizerContributor?

[Bob Gregory]

The code I posted is for removing the OR one.

If you're using your own IOC container, it's easier. I'm not sure if there's a means to remove components from the OR dependency manager, so your options are: 1) monkey with the DependencyRegistrar or 2) use a custom IOC container and remove it with the container's API.

 -- B

[Greg Sochanik]

Yup, it certainly was. I had just read your email incorrectly and implemented it in the wrong place! 

Thanks, I guess it's not ideal to have to remove components after the fact, but it'll do for now.  

[Bob Gregory]

Yeah, it would be neatest if the DependencyRegistrar were easier to configure, but I'm buggered if I can come up with a sensible API for doing so.

 -- B

[Aaron Janes]

[Sebastien Lambla]

The supported way to remove the default components being registered in OR is to override the dependency registrar, especially important for things like partial support…

 

Seb

[Sebastien Lambla]

You may want to switch to OpenRasta 2.1, which is available as an openwrap package, as it provides for extensible authentication mechanisms.

 

Seb

[Greg Sochanik]

Thanks - will look at that too. 

[Shane22]

When we implemented Basic authorisation we ran into the same problem and worked around it by simply specifiying the pipeline order in relation to the baked-in Digest contributor.

ie:

public void Initialize(IPipeline pipelineRunner)
{
    pipelineRunner.Notify(ReadCredentials)
                .After<KnownStages.IBegin>()
                .And.Before<KnownStages.IHandlerSelection>()
                .And.Before<DigestAuthorizerContributor>();

    pipelineRunner.Notify(WriteCredentialRequest)
                .After<KnownStages.IOperationResultInvocation>()
                .And.After<DigestAuthorizerContributor>()
                .And.Before<KnownStages.IResponseCoding>();
}

As neither Seb or Greg has suggested this it may not be the preferred method, although it's working fine for us.

[Shane22]

Ack, sorry, first post and I get people's names wrong. I meant
'neither Seb or Bob'.

[Sebastien Lambla]

Indeed, but do know that the DigestAuthorizerContributor has been removed from OpenRasta 2.1 so you may want to watch out for that, as your code may not be portable to later versions. I may re-add it as a shim to make sure ordering doesn’t break in 2.1 and remove it altogether in 3.0.

 

 

 

From: open...@googlegroups.com [mailto:open...@googlegroups.com] On Behalf Of Shane22

Sent: 09 March 2011 11:32
To: open...@googlegroups.com