It is not that it is complicated, just that it is generic. It assumes nothing about your web server, if you even use a web server, or anything of the sort. It is a general library to handle essentially any form of auth, such as I use Google Auth and I built an LDAP auth that is used in mine through ueberauth, I’ve not seen that being possible in any other library yet. If you need the power then it is very nice. If you are making a simple sign-up site with no external links then eh, not needed.
As for Guardian, it is an awesome JWT library, and I use it for sockets and API endpoint, I ‘barely’ use it in my app (just as a ‘holder’ for a better lookup) and I instead use my PermissionEx library with the Canada library for permission handling in pages.
Sort of. It’s kind of working but I haven’t actually move any further than “oh it’s working, let’s move on to other part of the project now”.
I didn’t use Guardian though since I would have to also used hassox/guardian_db to prevent replay attack and consequently have to migrate couple more tables. It became a giant mess of many dependencies and tables very quickly. I haven’t found any good solution suggested short of more tables and more background processes.
I sort of stuck with Coherence once Ueberauth handed the request over. That said, I also made a package, birbnest, for storing session in an Agent on server-side instead of worrying about JWT stuff. It’s not really actively maintained since it’s a pet project and it’s not hard to hand-rolled yourself tbh. In any case, JWT wasn’t worth the effort for what I needed.
this DOES feel like a mess imho, I just cracked my head on
guardiandb guardian ueberauth and now starting canary … I wish coherence
and exadmin had a bridge to later
surely one hex could combine all this in a standard way?
Too many ways to do authorization though. There can be plug authorization, fine-grained permission that changes based on what is grabbed from the DB (like mine), etc… etc…
I do agree, somewhat. Maybe not one hex to rule them all, but something like needing guardian and guardian_db seems silly. To me, this replay attack is a bug and guardian needs to be fixed. The fact that guardian_db has existed for so long and not folded into guardian yet doesn’t inspire confidence in Ueberauth.
That said, I’m not into the JWT anyway so I’m probably pretty bias against guardian already.
Guardian_db is for when you are using a JWT as a session container, which you should not really be doing. JWT’s are intended for stateless API connections, the session should be used for stateful connections like HTTP.
Guardian does not use any storage at all, it is nothing but a JWT generator and reader, designed for and works amazingly for API endpoints. Guardian_db uses storage (the database specifically) to ‘emulate’ a session storage for those who just want to use one thing for everything. But you ‘should’ be using the normal phoenix session storage to hold normal, like, HTTP web pages connections, and JWT is best for, say, websockets or stateless API endpoints or ‘passing’ information securely via the client to a different server or so.
Hello Steve. Thanks for this awesome package. I’m trying Coherence and loving it. I’m just confused with the controllers. Where are they located? What’s the difference between passing and not passing --controllers to mix coherence.install? Again, thanks.
If you don’t pass —controllers to the install task, the once located in the package are used. You can view them in your project at deps/coherence/web/controllers. If you use the —controllers option, they are generated in your project under web/controllers/coherence. Use the —controllers option if you want to customize them. Also note that if you generate the controllers, you need to name space them correctly in your router since the generated controllers are named MyProject.Coherence.SomeController.
I did not pass --controllers during installation. But now I need to do some customizations. Should I just copy the controller I want to modify from deps/coherence/web/controllers to web/controllers/coherence?
It is, but that’s not the point. The point is, that projects don’t all have the same requirements to the authentication system. One might need facebook and twitter oauth, the next does need jwt token authentication, another might just need http basic auth for an api and some other one simple cookie based session authenticatiom. Even none or all of them would be possible. Therefore it’s the better way to leave authentification to the users choice in the first place and not bother forcing a default way of handling authentication.
I feel that adoption of the framework will be sped up if there is strong core support for 2-3 widely used authentication systems. Leaving it up to the user is more flexible for power users, but is a turn off for others. One could make your point about the templating system or the router or anything else.
