Authentication provider

[CMircea]

An authentication provider, with support for local and external authentication, as well as some customization features.

Local authentication is classic username/password, with secure by default settings (eg. BCrypt for hashing with high work factor, salted and peppered); external requires implementing an interface and registering that implementation (will add some OAuth/OpenID providers later).

Configuration is done via the static property AuthProvider.Configuration. You just have to specify a document store (the default provider creates a new session for each method) and you're ready to go.

The authenticator and encoder can be customized (i.e. if you don't want to use ASP.NET`s forms authentication). I strongly advise against customizing the default encoder, it is secure enough for all applications.

[PureKrome]

If your suggesting Google/Facebook/Twitter for external authentication -> https://github.com/PureKrome/WorldDomination.Web.Authentication

It is independent of any repository or session, etc.

[mattjohnsonpint]

Is MVC required here? Shouldn't one be able to use this provider with WebForms if they liked? If so, please rename the project to Raven.Contrib.AspNet and changed the default namespace to Raven.AspNet.

As we did on the other projects, we'll keep "Contrib" off of namespaces and use it in the project and assembly name only.

[mattjohnsonpint]

@PureKrome World Domination is pretty neat, but I don't think it's a good candidate for the raven contrib project. As you said, it's independent of any repository or session. I like that cmircea's library specifically targets RavenDB and pulls in DNOA, since that is the same route the the providers shipping with the asp.net templates take. We are just swapping out SQL/EF for Raven, but not making too many other opinions.

Keep up the good work on World Domination. But it doesn't belong merged here.

[CMircea]

I will use DNOA. I have already implemented providers for Facebook, Twitter, LinkedIn and anything with OpenID and will port them over. WD only targets the main three; DNOA can target anything well enough.

MVC is not required ATM, but might be. I have zero experience with WebForms and cannot guarantee anything will work in WebForms. For this project Contrib should be in the namespace, since it doesn't extent Raven itself per-se. Client was out of place.

The idea is to have this targeted directly for RavenDB, with some options to customize stuff. It doesn't need to do everything, just to provide some helpful starting points.

[mattjohnsonpint]

ok. Agreed. Thanks again!

[PureKrome]

Back at work after a lovely night sleep

"but I don't think it's a good candidate for the raven contrib project."

heh :smile: 150% agreed! Even more so, I very strongly don't think authentication should be part of the RavenDb contrib stuff. I also never suggested my package should be in here - I was (poorly) trying to suggest that we already have code for authentication out there. Let people leverage it.

So now you've merged Auth stuff into this :( I think this should be seriously reviewed. Suddenly, we've got some functionality that might leverage RavenDb but is not extending it.

Put it this way -> the contrib project should be for stuff which improves on and extends RavenDb. In an awesome world (i think we have <24 hours left before we all die, right? lol) Hibernating Rhino's will cherry pick the best of the best in this package and promote it up to the main repo. Think of this as a testing ground :smile:

Authentication with Facebook, etc has -nothing what so ever- to do with RavenDb! This was why I specificially made that package! Just because MS added it in and (cringe cringe cringe) tied it closely to simple membership I think is woeful and wrong.

So i really really think that having -any- authentication is really wrong in RavenDb. What you do with your authentication details is totally independent of RavenDb. Sure! I stick my creds and claims in a Raven database. that's -really- simple.

Oh - and who -really really really- signs up/signs into a site with a linked in account? srsly?

So yeah .. please reconsider - even though it's closed and merged.

[phillip-haydon]

I can't agree with this PR. Auth has nothing to do with RavenDB. DNOA is a terrible dependency.

[mattjohnsonpint]

I'm not sure I agree that absolutely everything in the repository has to extend raven directly. Certainly that intent would apply to the Raven.Client.Contrib project, but this PR is in its own project, so the dependencies don't affect anything but itself.

There are other areas where contrib would be an essential area specifically for doing things that couldn't be done in the main project, such as Ayende's suggested User-Based Last Etag Holder.

I think it's just fine to have thing that extend other projects with a RavenDB flavor. Perhaps we just need to be more careful about over-reaching. For example, what we're really in need of with this particular project is a Raven flavored asp.net Membership provider. There's no reason that has to include DNOA or third-party authentication at all.

That said, I would be absolutely thrilled with a sample or project template that used that provider, along with DNOA, and whatever else it needed (MVC, WebApi, javascript libraries, etc.). Take a look at what you are given when you go File - New MVC4 Project - Single Page Application. That pulls in all kinds of things, but it's designed around SQL Server and Entity Framework, and it uses a membership provider that will only work on a relational DB. So if one could make it dead simple to get it working on RavenDB, that would certainly be something to contribute - separately from the provider.

Also, when it comes to storing users, roles, etc. in raven, the provider should probably use what it can from the Raven auth bundles instead of anything custom, unless it can't be avoided.

[mattjohnsonpint]

Here is exactly the reason why we need to get this done right: http://stackoverflow.com/q/13890829

BTW - the Griffin Membership Provider he talks about does a pretty good job of being a membership provider framework. He even has a Raven provider already written, but it's based on Raven 1.0.888 and it's not exactly doing things right from a Raven perspective. See code here and here. Perhaps starting with his framework and wiring it in to the Raven Authorization Bundle would be a good approach.

[PureKrome]

Answered that SO post :blush:

I guess we might just have different opinions here. Which is totally kewl :+1:

[CMircea]

The problem with the MVC membership provider is that it's overcomplicated for managing username/password combinations. It also stubbornly requires web.config settings, with few stuff to change in-code.

That's why I wrote a separate membership provider, which supports both username/password and third-party and manages storing accounts itself, to make it easy to start with. I don't remember Raven.Contrib being tied to stuff extending; it would make much more sense to add other things to jumpstart new apps. You as a developer find this new database called RavenDB, you find it has a contrib project, you see that project has a heap of goodies to help you start, what would be your impression? Instead of huting for libraries or reinveting the wheel, you have everything in one place.

I don't understand what's so wrong with DNOA. It's a very mature OAuth/OpenID library, which has worked very well in my experience. I plan to include providers written for DNOA, as well as a role provider. Later on an implementation to store accounts in the Raven auth bundle, not in custom documents.

PureKrome, with all due respect, your project only handles Facebook/Twitter/Google, perhaps the developer might want more websites to authenticate with. Perhaps they want classic password based, which is not necessarily "crazy talk". If you are building an application to be used by businesses, are you going to require them to login with Facebook? Of course not. Now the developer has to either search for a membership provider for RavenDB or implement his own, with a high chance of screwing things up. Hooray.

[jtbennett]

+1 on including things like membership in RavenDB.Contrib (repo, not assembly).

Having well-tested RavenDB implementations for common features that need to store data will help people to choose RavenDB. (And the contrib readme/wiki should link to RavenDB implementations in other projects, like https://github.com/antonsamarsky/log4net.Raven ) That can be done in such a way that you can cherry-pick the ones you want, without having to bring a lot of other code you don't need into your project. The RavenDB.Contrib.AspNetMembership assembly/pkg (as an example) would have just that and nothing else.

I agree that the core RavenDB.Contrib assembly should not have any of these "external" dependencies. It should depend only on the RavenDB.Client pkg.

A question for another thread: Should we also expect contrib server bundles? (I hope so!) In that case, would it make sense to name the assembly/pkg RavenDB.Contrib.Client, to make it clear it goes with RavenDB.Client?

Thanks to all of you for your time and passion around RavenDB contrib. I'm excited to chip in. -JB

On Fri, Dec 21, 2012 at 5:12 AM, Mircea Chirea notifications@github.comwrote:

The problem with the MVC membership provider is that it's overcomplicated for managing username/password combinations. It also stubbornly requires web.config settings, with few stuff to change in-code.

That's why I wrote a separate membership provider, which supports both username/password and third-party and manages storing accounts itself, to make it easy to start with. I don't remember Raven.Contrib being tied to stuff extending; it would make much more sense to add other things to jumpstart new apps. You as a developer find this new database called RavenDB, you find it has a contrib project, you see that project has a heap of goodies to help you start, what would be your impression? Instead of huting for libraries or reinveting the wheel, you have everything in one place.

I don't understand what's so wrong with DNOA. It's a very mature OAuth/OpenID library, which has worked very well in my experience. I plan to include providers written for DNOA, as well as a role provider. Later on an implementation to store accounts in the Raven auth bundle, not in custom documents.

PureKrome, with all due respect, your project only handles Facebook/Twitter/Google, perhaps the developer might want more websites to authenticate with. Perhaps they want classic password based, which is not necessarily "crazy talk". If you are building an application to be used by businesses, are you going to require them to login with Facebook? Of course not. Now the developer has to either search for a membership provider for RavenDB or implement his own, with a high chance of screwing things up. Hooray.

— Reply to this email directly or view it on GitHubhttps://github.com/ravendb/ravendb.contrib/pull/10#issuecomment-11608329.

[mattjohnsonpint]

@jtbennett Yes, bundles also. And analyzers, conventions, jump-start samples, and whatever else seems appropriate to share.

I've already committed one server bundle. They go under a Raven.Bundles namespace because they're server side.

[jtbennett]

@mj1856 Sorry for not looking before I wrote. :) You're way ahead of me.

[CMircea]

I'm all for splitting the current MVC project into several parts. Having compatibility with any ASP.NET app, not just MVC is also fine by me, as long as someone else maintains that; though I highly doubt anything would break if the MVC assembly is not referenced :)

[ciel]

My contribution to this project has been zero, so if you want to tell me to shut up and sit down while the 'real programmers' talk, I won't be too offended. But from the perspective of a rookie developer, I find that too many features in one project is confusing.

I'm a little against the authorization stuff being included just because I've spent two hours combing over it and I can't see how it extends Raven, but rather it extends MVC.

It looks like a good project that just deserves to be treated as it's own, and the two would be both fair and wise to reference each other so the struggling idiot (me) knows they exist. On Dec 21, 2012 11:47 AM, "Mircea Chirea" notifications@github.com wrote:

I'm all for splitting the current MVC project into several parts. Having compatibility with any ASP.NET app, not just MVC is also fine by me, as long as someone else maintains that; though I highly doubt anything would break if the MVC assembly is not referenced :)

— Reply to this email directly or view it on GitHubhttps://github.com/ravendb/ravendb.contrib/pull/10#issuecomment-11621257.

[CMircea]

Contrib isn't supposed to extend Raven. It's supposed to provide useful code for others to use with RavenDB. Whether it is bundles, extensions, helpers. I don't see what is wrong with MVC/ASP.NET stuff being in contrib, so long it helps people get started with RavenDB apps, it's fine. It's already written, not as if code rusts.

[ciel]

I'm speaking from the perspective of a person who is new to Raven AND the authentication stuff being offered, also. So realize my bias is 'confused' and 'young' and 'inexperienced' all in one. Though it seems that is the target audience. On Dec 21, 2012 12:55 PM, "Stacey Thornton" stacey.cielia.lynn@gmail.com wrote:

My contribution to this project has been zero, so if you want to tell me to shut up and sit down while the 'real programmers' talk, I won't be too offended. But from the perspective of a rookie developer, I find that too many features in one project is confusing.

I'm a little against the authorization stuff being included just because I've spent two hours combing over it and I can't see how it extends Raven, but rather it extends MVC.

It looks like a good project that just deserves to be treated as it's own, and the two would be both fair and wise to reference each other so the struggling idiot (me) knows they exist. On Dec 21, 2012 11:47 AM, "Mircea Chirea" notifications@github.com wrote:

I'm all for splitting the current MVC project into several parts. Having compatibility with any ASP.NET app, not just MVC is also fine by me, as long as someone else maintains that; though I highly doubt anything would break if the MVC assembly is not referenced :)

— Reply to this email directly or view it on GitHubhttps://github.com/ravendb/ravendb.contrib/pull/10#issuecomment-11621257.

[ciel]

I can agree to that. It's good code. It will do good things.

Some better documentation might be nice. I've just only recently discovered github and this is one of the first things I've actually begun to 'follow', so I may just not know how to read it right or it may be somewhere I am not looking. On Dec 21, 2012 12:59 PM, "Stacey Thornton" stacey.cielia.lynn@gmail.com wrote:

I'm speaking from the perspective of a person who is new to Raven AND the authentication stuff being offered, also. So realize my bias is 'confused' and 'young' and 'inexperienced' all in one. Though it seems that is the target audience. On Dec 21, 2012 12:55 PM, "Stacey Thornton" stacey.cielia.lynn@gmail.com wrote:

My contribution to this project has been zero, so if you want to tell me to shut up and sit down while the 'real programmers' talk, I won't be too offended. But from the perspective of a rookie developer, I find that too many features in one project is confusing.

I'm a little against the authorization stuff being included just because I've spent two hours combing over it and I can't see how it extends Raven, but rather it extends MVC.

It looks like a good project that just deserves to be treated as it's own, and the two would be both fair and wise to reference each other so the struggling idiot (me) knows they exist. On Dec 21, 2012 11:47 AM, "Mircea Chirea" notifications@github.com wrote:

I'm all for splitting the current MVC project into several parts. Having compatibility with any ASP.NET app, not just MVC is also fine by me, as long as someone else maintains that; though I highly doubt anything would break if the MVC assembly is not referenced :)

— Reply to this email directly or view it on GitHubhttps://github.com/ravendb/ravendb.contrib/pull/10#issuecomment-11621257.

[CMircea]

Well the idea is the auth provider will allow you to accept username/password auth AND auth via Google, Facebook, whatever, and have the provider manage storing the accounts itself, possibly using the built-in RavenDB auth bundle, or custom logic.

As for documentation, we're still in the beginning stages, so expect that to be a little lacking.

[ciel]

Honestly I guess I just have a different idea of what a 'contribute' library is then. In which case, I defer to the more experienced programmers. I was looking at this library as kind of a 'plus pack'. 'things we want in Raven but they haven't had time to do' or 'common problem solutions'.

Like that pager. Oh my heavens, that pager has changed my outlook on data in raven. Thank you, to whoever wrote it. You are a god among insects. On Dec 21, 2012 1:01 PM, "Stacey Thornton" stacey.cielia.lynn@gmail.com wrote:

I can agree to that. It's good code. It will do good things.

Some better documentation might be nice. I've just only recently discovered github and this is one of the first things I've actually begun to 'follow', so I may just not know how to read it right or it may be somewhere I am not looking. On Dec 21, 2012 12:59 PM, "Stacey Thornton" stacey.cielia.lynn@gmail.com wrote:

I'm speaking from the perspective of a person who is new to Raven AND the authentication stuff being offered, also. So realize my bias is 'confused' and 'young' and 'inexperienced' all in one. Though it seems that is the target audience. On Dec 21, 2012 12:55 PM, "Stacey Thornton" stacey.cielia.lynn@gmail.com wrote:

My contribution to this project has been zero, so if you want to tell me to shut up and sit down while the 'real programmers' talk, I won't be too offended. But from the perspective of a rookie developer, I find that too many features in one project is confusing.

I'm a little against the authorization stuff being included just because I've spent two hours combing over it and I can't see how it extends Raven, but rather it extends MVC.

It looks like a good project that just deserves to be treated as it's own, and the two would be both fair and wise to reference each other so the struggling idiot (me) knows they exist. On Dec 21, 2012 11:47 AM, "Mircea Chirea" notifications@github.com wrote:

I'm all for splitting the current MVC project into several parts. Having compatibility with any ASP.NET app, not just MVC is also fine by me, as long as someone else maintains that; though I highly doubt anything would break if the MVC assembly is not referenced :)

— Reply to this email directly or view it on GitHubhttps://github.com/ravendb/ravendb.contrib/pull/10#issuecomment-11621257.

[CMircea]

Well the commonly used stuff that directly extends Raven could be eventually integrated directly in the project.

[ciel]

Maybe I am assuming the auth stuff is more involved than it really is. I can't make heads or tails of it. But again, first real guthub experience, on a platform I am new to, with concepts I am not used to, in an already very young and rookie developer - so please only treat my assumptions to that degree of respect. On Dec 21, 2012 1:04 PM, "Stacey Thornton" stacey.cielia.lynn@gmail.com wrote:

Honestly I guess I just have a different idea of what a 'contribute' library is then. In which case, I defer to the more experienced programmers. I was looking at this library as kind of a 'plus pack'. 'things we want in Raven but they haven't had time to do' or 'common problem solutions'.

Like that pager. Oh my heavens, that pager has changed my outlook on data in raven. Thank you, to whoever wrote it. You are a god among insects. On Dec 21, 2012 1:01 PM, "Stacey Thornton" stacey.cielia.lynn@gmail.com wrote:

I can agree to that. It's good code. It will do good things.

Some better documentation might be nice. I've just only recently discovered github and this is one of the first things I've actually begun to 'follow', so I may just not know how to read it right or it may be somewhere I am not looking. On Dec 21, 2012 12:59 PM, "Stacey Thornton" stacey.cielia.lynn@gmail.com wrote:

I'm speaking from the perspective of a person who is new to Raven AND the authentication stuff being offered, also. So realize my bias is 'confused' and 'young' and 'inexperienced' all in one. Though it seems that is the target audience. On Dec 21, 2012 12:55 PM, "Stacey Thornton" < stacey.cielia.lynn@gmail.com> wrote:

My contribution to this project has been zero, so if you want to tell me to shut up and sit down while the 'real programmers' talk, I won't be too offended. But from the perspective of a rookie developer, I find that too many features in one project is confusing.

I'm a little against the authorization stuff being included just because I've spent two hours combing over it and I can't see how it extends Raven, but rather it extends MVC.

It looks like a good project that just deserves to be treated as it's own, and the two would be both fair and wise to reference each other so the struggling idiot (me) knows they exist. On Dec 21, 2012 11:47 AM, "Mircea Chirea" notifications@github.com wrote:

I'm all for splitting the current MVC project into several parts. Having compatibility with any ASP.NET app, not just MVC is also fine by me, as long as someone else maintains that; though I highly doubt anything would break if the MVC assembly is not referenced :)

— Reply to this email directly or view it on GitHubhttps://github.com/ravendb/ravendb.contrib/pull/10#issuecomment-11621257.

[PureKrome]

I noticed this thread is waaaaay closed .. but I didn't read the last few comments.

@Ciel - 3rd party auth stuff has confused me for AGES. it was only recently that I started to grok it (more than before).

Without blowing my own trumpet, I recommend you check this out: https://github.com/PureKrome/WorldDomination.Web.Authentication

in there, there's some sample websites that do auth stuff (which is why i initially suggested that any auth should -not- be part of this contrib ... but democracy rules). You can see I started that repo a few months back and have been using it in multiple proj's.

So maybe check out what I did in there, if u want to understand how to do some 3rd party (ie. facebook, etc) authentication in your mvc app.

[CMircea]

I also added a sample for my implementation. PureKrome, would you look over it please? I'd love to hear any suggestions or bug reports.