I found myself implementing a cookie based authentication with Phoenix. As much as I enjoyed toying with the concept, I think a library should do this job.
What are my options in Elixir/Phoenix?
Personally i like https://github.com/elixircnx/openmaize
But you can check more at https://github.com/h4cc/awesome-elixir#authorization
As I mentioned in one of the previous questions on the sbuject, I think it's more reliable to write one yourself at this point. It's rather trivial because Phoenix and Elixir give you everything you may need. And as a bonus, you will learn how some things are done under the hood, if you don't know yet.
Related
Both recommended in the official Mobx page if one wants an opinionated way to using mobx for state management.
Based on these(1,2), keystone seems like an improvement of state-tree. Having everything that state-tree has + more. Nowhere I could find anything that state-tree has that keystone doesn't.
I see keystone is nowhere nearly as mature as state-tree. That's probably the main point stopping me from picking it instead. What are other good points for state-tree over keystone?
P.S. It's going to be used in a React app.
I'm the current maintainer of MobX-State-Tree. I think the primary benefit of MST over MobX-Keystone is that MST is used more widely and has more broad third-party support. For example, mobx-devtools supports MST but not MobX-Keystone, as does Reactotron.
With all that said, I'm very interested in exploring MobX-Keystone for our own usage at my consulting company. Even though I'm maintaining MST, I'm not opposed to MobX-Keystone, and the much better TypeScript support is very tempting. If we end up using it in a project and it goes well, we will likely build in support to Reactotron for it.
I hope this perspective helps.
(With regard to the other answer asking if you really need more than just MobX, it's my opinion that MST and MobX-Keystone bring super useful patterns and tools that help you scale across a whole application in a more cohesive way than remaking them yourself using MobX.)
First ask yourself if you really need those libraries, because you can get really far with just mobx and good ol' OOP patterns. In the official docs you have an example of a store that does auto-saving and serializing.
Having said that, I would go for the mobx-keystone. Typescript works right out of the box, and you can use classes to construct your store, which is IMHO, easier that MST stores. Plus the author is very responsive and he is also a contributor to mobx library.
mobx-keystone is super awesome. After using both of the two libraries for a while I would recommend using it over mobx-state-tree in every possible occasions. It's much more intuitive and easer to learn. It saved a lot of time for my project (switching from zustand to jotai to mobx-keystone, IMO each next one is a bit better than previous one in my use case)
After extensive testing / reading the source code / playing with test suite it feels that mobx-keystone provides a more robust developer experience with Typescript and also has enough escape hatches if you need to work with performance sensitive code. I would implementing a small problem (but complex enough) problem with both libraries to judge for yourself.
I want to create an OAuth 2 Server mainly for self education purposes. I do understand the concepts the OAuth framework is based on and I do understand the the authentication process(what is send/received and why).
I'm pretty familiar with java and the Spring framework as such my intentions are to use this technologies.
My question is, In order to implement an OAuth 2 Server:
Do I just follow the rfc6749 to the letter and write my code based on this? Handling everything by my self? from the data and how its stored in the database(if a database is used) to serving the same error/message response?
Do I use a dependency or a library maybe, which will prevent me from reinventing the wheel (as far as OAuth 2 is concerned)?
Or is there and already free service which I can install and does exactly with some minor configurations.
Thanks in regards. :)
If you're writing something new from scratch, I would recommend you would take a look at the upcoming OAuth 2.1 spec. Largely compatible with OAuth2, but there's a few features removed and some stuff added. It might be worth starting off with something that's immediately the bleeding edge.
Yes, probably. Unless you can't find a good one?
Yes, there's open source implementations and free hosted services.
I think what you want is Keycloak.
Thanks.
I am looking to wrap a bot service in order to enable business areas to create and manage them at will with minimal technical knowledge, but meeting our strict security controls. With this in mind I need to be able to create and manage them 100% programatically.
I have been working on a prototype with Microsoft's Bot Framework, Luis and QnA Maker. Sadly though joining these technologies requires a number of manual steps, specifically:
Creating a bot in Azure (Bot Framework)
Creating a Luis Account
Joining Luis bot with Azure(the subscription management part
of the API was recently deprecated)
Creating a QnA Account
Microsoft really don't feel very joined up at all...
With this in mind I am now looking for alternatives and thus looking to see what Google are up to. I am just a bit weary of heading off in a new direction to find similar issues.
Looking briefly at the API documentation it seems I should be able to import an agent in to a project and then manage it. I imagine I could use a template to create my bots from.
Thanks for your time
Mike
Thanks for your feedback.
The way I see it, Bot Framework is more modular than other options out there. First of all, creating a LUIS and QnA account are optional and not time consuming. The average use case can be solved with less than 50 lines of code with no need to throw LUIS or QnAMaker into the mix. Why should Microsoft force you to use LUIS if you might not need it? Google uses a different approach. In my opinion, they give you most of the tools from start, like the NLP agent, so you need to understand NLP concepts even if you don't really need to use them. Most developers tend to overthink their bots and make them more complex that hey need to be.
With that said. We don't provide a way to create agents programmatically. But the process of registering your bot is very straight forward and fast. Let me know if you have any problems on this regard.
Please, take a look at our samples here:
https://github.com/Microsoft/BotFramework-Samples
They can give you a very deep knowledge on what architecture to use for different scenarios. Many times there is a simpler way to achieve the same goal and Microsoft does not try to force you to use the most advanced techniques. Most of the time you can achieve your goal with very simple and easy to maintain code.
Francisco
A Quick Update, in the end we went with a solution based on this idea:
https://aws.amazon.com/blogs/machine-learning/creating-a-question-and-answer-bot-with-amazon-lex-and-amazon-alexa/
I can simply create a new bot by executing cloudformation.
I've read through https://github.com/apotonick/roar and it seems like a lot of thought has been put into ROAR. But in the context of a fairly standard Rails-powered JSON API that uses jbuilder, I'm still not able to immediately see what benefits ROAR provides.
What am I missing?
Within a Rails project, you should do as much as possible to stick with the built-in solution, but outside a choice is mandatory. Personally one aspect that I love about ROAR is the versioning for the API.
There is one good post I like that might help you:
http://devblog.reverb.com/post/47197560134/hal-siren-rabl-roar-garner-building-hypermedia
It might not be an straight answer, but it explains the problems you should be aware of when choosing a JSON API generator.
I have recently been thinking about how to get my webframework/application-stack right. I'm slowly moving over to scala and functional programming (coming from Python with CherryPy). So it was natural to look into Play as it is the most widely supported framework (now that even Typesafe adopted it). Feel free to correct me if I'm missing something here.
So play is really embracing the idea of stateless webapps and I have a hard time wrapping my head around it in terms of authentication and authorization. Now after some online digging (The definitive guide to form-based website authentication) I came to conclusion that authentication and authorizing must be done on each and every call to my backend (JSON-RPC or whatever), getting away from the old session-cookie idea.
Now whats the best approach to achieve this with todays technology?
And what about:
I thought about "simple" DigestAuth as it is proven and widespread but then it has this similar feel to the old and rusty basic auth.
Thank you!
You can easely get a work solution. But, not a good one. It seems that the advantage of stateless to stateful is no needs of sharing sessions. Easy to scale up. But, do authentication for each call is costly. Sometimes even add some extra database reads ops. This will slow down the response. If you want to cache the authentication result, then there will be no difference with a stateful session solution.
As my opinion. You can not implements a Role Based Access Control in a stateless way!
As for me I use this in my current project https://github.com/t2v/play20-auth, works fine.