Changes to Auth classes

Demis Bellot

unread,

Jan 16, 2012, 11:27:11 AM1/16/12

to servic...@googlegroups.com

Note: I've done a major Rewrite to Authentication on the weekend.

All AuthConfig classes have all been re-factored to work the same way with all of the logic now inside the AuthProvider classes - which is why they've been re-named to AuthProviders.

The best way to see a demo of it is still in the SocialBootstrapApi project:

https://github.com/ServiceStack/SocialBootstrapApi/blob/master/src/SocialBootstrapApi/App_Start/ServiceStackFramework.cs#L149

The heirachy of AuthProvider classes looks like:

AuthProvider : IAuthProvider

+ TwitterAuthProvider

+ FacebookAuthProvider

+ CredentialsAuthProvider (for Username / Password)

+ BasicAuthProvider

There are generally 2 ways for extending, if you want to provide your own OAuth implementation you would sub class AuthProvider (or implement IAuthProvider) and override the Authenticate() method which holds the entire implementation of your service. The AuthService now has no real implementation of its own, it just checks the Auth Provider .IsAuthorized() method to see if the user is already authenticated, if not it calls the Authenticate() method.

If you just want to provide an AuthProvider which checks User/Pass you can sub class the CredentialsAuthProvider and implement TryAuthenticate.

There is one hook remaining on the AuthUserSession which gets fired after a successful OnAuthenticated on all providers, for Credentials providers the tokes/authIfo params will be null.

The CustomUserSession on the SocialBootstrapApi project shows an example of how you can take advantage of it to provide your own post-auth logic, e.g. save the UserAuth info in your own database.

We plan to write more documentation about this in the future, just wanted to drop a quick note about the breaking changes and would like some feedback or issues.

Cheers,