Coherence for me, sadly, is entirely untenable as it only supplies an internal registration. It has no support for external directories, no support for oauth (they are talking of it, but nothing yet), and its methods of injecting its views are a little different than usual phoenix’y stuff. ^.^
I currently just use ueberauth as it handles all login types fine, but it does not have any views or back-end handling (including nothing like the features you listed), however those tend not to be hard to make, just needs a library (and I’d still not opt for automatic login/registration page handling). I had been playing with an idea to wrap uberauth in a coherence-like thing that handles all styles via protocol dispatch (and a default case the user could depend on as well for a stock coherence-like style), but I’d also like to do more traditionally phoenix style view handling in it instead of using a host of generators, or not do views at all (maybe just some callback functions for form generation or so). Maybe when I get some free time again later, but for now I am too busy. ^.^;
Login page - yes
User registration page - yes
Password recovery method - yes
Decorator that redirects to login page if not authenticated, exposes user info otherwise - yes
Decorator to protect an API endpoint - not out of the box
Permissions - No, by design. Authorization is a separate concern from Authentication IMHO
OAuth2 provider support (this is a stretch, maybe I’ll have to use Authable) - not yet.
Let me know if you have any more questions about coherence.
Just things I spoke to you about the time that you started it, you have your reasons for that style, I just find it difficult to work with comparatively.
A few things are an enforced user schema style, id/password only, the authorization aspect is very lacking (and at least in my projects those were some of the huge parts that needed to get done ‘right’), etc… Plus the fact it injects code all around instead of being used more like a library, instead of being a part of the project you use it becomes a thing that you have to work inside of. This is probably quite normal for the Ruby crowd (which I am not), but it is very much not normal for the Functional crowd.
Hum, are you working on an OAuth provider implementation for Coherence? Cool.
Another question. I want to persist my sessions outside the current beam vm, since I will have more than one application instance running and a user can hit any one of them. From the documentation it seems I have to implement Coherence.DbStore, is there a schema for the “Session” model that is referred in the documentation?
Also, even though the protocol is called DbStore I can store them anywhere, right? I was thinking of using Phoenix’s own session store which can be cookie based for example.
@OvermindDL1 I would love to get more details on your suggestions to improve Coherence if your willing too. We could do that here, or open a new issue on the project.
Here are some of things I would like to understand more:
“A few things are an enforced user schema style, id/password only”. Do you mean supporting authorizing on several fields like “Email or username”? I just had that requirement and had to customize the generated controller.
“Plus the fact it injects code all around instead of being used more like a library”. Can you give me more information here? Perhaps an example on how its done now and how you would prefer it be done.
On the authorization front, I have not yet found an Elixir solution that I’m happy with. I’ve taken a stab at this a couple of time, but have not completed anything I’m happy with.
I have a pretty strong opinion that authorization is a separate concern from authentication and that is why I have not provided anything in Coherence. With that said, I do believe that authentication is very important and would really like to have a story for people that use Coherence.
@edevil DbStore is just an empty protocol which you need to implement. So, you can do anything in it. The example here should give you enough details to implement something.
The DbStore is design so it only hits the database (uses the protocol) if a session cannot be found in the Agent. So it should perform pretty well…
Well for example, I’ve built up a little thing (very much not a library, I probably should put it in one sometime though…), I have an account schema, GUID keys, this is the base of all the users information.
From that I have an account_google as one example, it holds the information like tokens and so forth from a google OAuth request, its primary key is a foreign key to the account primary key, always a one-to-one match and the google one cannot exist without the account one. I have a variety of other ones like this for github, steam, facebook, as well as an account_local schema. The local one exists in only one of my systems so far (I do not even have any form of a local login for the other dozen little servers I have, oauth only for them) but it contains a login id, hashed password, and a bit of other data.
Needless to say, coherence is very much not usable for the majority of authentication purposes I’ve ever experienced.
Now in my thing I’ve built up, say, a password reset thing, simple plug in the ueberauth style, it just redirects to the proper place for a given login type (say google) or handles a local one (I confirm they are who they are based on some internal information to this company so I’ve not needed email yet, but that style would not be hard either).
I can go in to a lot more information at some other time, but I’m fairly busy at the moment, in a crunch period. ^.^
Lots and lots of examples, but the biggest one for me is the *very* specific view style it uses, basically logins via websocket, other sources, or even customizing and breaking up views in unique ways (I have a lot of little subviews all over that does not fit that style well), I have more about this in a lot more detail, but I am not in the mindset right now (my mind is in oh-god-too-much-sql mode right now, I’m making SQL queries that are many many pages in length, blehg…)
It should not necessarily have a way to do authorization, but it needs a way to let you populate your own authorizations, for example in my system I use a set of allow/deny permissions with arguments (stored as json in the database currently, eh), but in addition to those populated I get information from google and LDAP and other places to give them or deny them more permissions, so I have to get that information from the authentication layer as it can change on the fly from those systems.
Coherence could become something really really useful over time, but so far it does not meet even my minimal requirements, ignoring the advanced features that I need that I’m not even sure how to shoehorn into its current design. ^.^;
