I would like to implement Custom Authentication

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Added custom authenicator in web.config
2. Added a breakpoint on my service and authenticator and called service.
3. Debuggers stops at execute and never runs Authenticate.

What is the expected output? What do you see instead?
I was hoping to use out of the box Custom authenticator example as per the 
visual studio 2010 WCF Rest Service with API key example project (available 
from the online templates section in file -> new project)

What version of the product are you using? On what operating system?
latest servicestack on windows 7 vs 2010

Please provide any additional information below.
Am I missing something. Does service stack have existing extension behaviour 
for authorisation that I am missed?

Original issue reported on code.google.com by LepardUK on 11 Oct 2010 at 2:51

[GoogleCodeExporter]

I'll have to see if I can get a copy of VS.NET 2010 somewhere to see what the 
new WCF REST mechanism is like to see if it isn't too ugly and supportable for 
implementations outside of WCF.

I normally roll my own authentication/session scheme as it lets me have greater 
control over the user's auth/session and lets me store it in any ICacheClient 
of my choosing. I have an example of the approach I normally take in these 
classes: http://bit.ly/bolwP2

In order to handle each request generically, I have an IService base class and 
mark each RequestDTO I want to authenticate with a IRequiresUserSession which 
is just an interface with a UserId/SessionId pair. The base class simply 
detects if the Request DTO is an 'IRequiresUserSession' and if so validates 
that it is a valid session. If it is, calls the sub classes IService 
implementation otherwise throws an Auth Error.

I'll try to put an example of this in ServiceStack's Example project when I get 
time this weekend to show you what I mean. Normally Auth is handled with 
cookies but I always like to be explicit in my web services definition and have 
always needed the UserId for all my authenticated requests. Also it's more 
testable if the UserId/SessionId pair is decoupled from the Server's HTTP 
Request and explicitly set on the DTO's.

Original comment by demis.be...@gmail.com on 11 Oct 2010 at 3:28

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I have resolved this issue by creating

public abstract class MyServiceBase<TRequest> : ServiceBase<TRequest>, 
IRequiresRequestContext 

and creating

protected override object Run(TRequest request)
        {
            if (Authorise())
                return RunService(request);
            else {}
                 }

and my bool Authorise does my required validation. I wondered if it might be 
helpful to others if this was baked into the framework. The base implementation 
could contain an overridable Authorise method that just returns true in the 
base?

Original comment by LepardUK on 12 Oct 2010 at 8:42

[GoogleCodeExporter]

Yeah, that looks like it will work, the base-class is in-line with the approach 
to what I would do. I don't really like 'baking in' auth/session into the 
framework since it proposes the use of a single implementation and IMHO 
complicates it for everybody who wants to use an alternate scheme. 

I much prefer to have 'extensions' project on the side like I'm doing with 
ServiceStack.ServiceInterface so users can opt-in the extra functionality if it 
suits them. I will look to provide a better auth/session story in there at some 
stage.

Original comment by demis.be...@gmail.com on 12 Oct 2010 at 8:56

[GoogleCodeExporter]

Hi LeparkUK,

Do you have a more complete example on how this worked for you?

Rui

Original comment by ruionwri...@gmail.com on 25 Mar 2011 at 12:50

[GoogleCodeExporter]

Sorry. Do to issues with service stack at the time (now resolved) I was unable 
to progress any further with the framework at that time and due to time 
constraints I had to continue without, so I no longer have my code. 

Original comment by LepardUK on 25 Mar 2011 at 12:55