I'm working on setting up authentication with connect-auth on express & mongoose but there is just so much to do and it's kind of bogging me down. I could continue down this path but it seems like a lot like re-inventing the wheel.
EveryAuth (with MongooseAuth helper) looks rather appealing but the main reason I didn't go with it initially is that I have several account types with their own properties and workflows. For example, some account types require approval while others can login with oauth/openid without approval.
From looking over the examples, it looks like it is pretty opinionated over the general flow. I just don't know how difficult it would be or if it's even possible to step outside of the normal account auth approach.
Is it possible to have EveryAuth settings for each model type? If not, is there any other way to handle different workflows?
Thanks a lot!
You can customize findOrCreateUser in EveryAuth for each strategy ie: facebook, github
Related
I have an application with (nuxt js using nuxt-auth) with local authentication so far (later I want to add git and google auth).
Now I need to add authentication to invoke other services / API (like google cloud rest API, payment system, youtube API, etc...)
The question is: the user is authenticated only once (during login to the application.) but each of these 3rd party APIs has its own authentication.
How to implement multiple authentications. (I read the documentation and google for the entire day but there is no clear answer).
As of today, it looks like it is not doable (people are needed on this module): https://github.com/nuxt-community/auth-module/issues/889
So, you would need to make it manually by plugging the APIs yourself.
Answer to your latest question~comment
Nuxt is indeed nice with some of it's modules (but you can totally dislike it, no problem :D).
First thing that you need to know, is that this project (nuxt-auth) is not the biggest one, #pooya is doing his best but he is on a lot of projects, so he cannot give all of his love to it. Then, you also need to understand that it's working great but it's still in a decent beta state with a lot of missing features, needed documentation and a lot of small things to make it an all rounded solid top notch solution.
That do not mean that you should not use it, I'm just saying that this module do have some limitations. Hence, the fact that it is not supporting a whole lot of OAuth solutions in a clear + simple + flexible way. And some breaking changes may be introduced in future updates.
The module is aimed towards having an OAuth solution to block the content of your website behind it (in my opinion). It means that you will usually use a single login solution and then, being able to have access to your app. I don't think that it's a viable multi-OAuth solution (yet).
Some services don't even need to use a solution like this. Stripe for example, should not be handled on the frontend but communicate with a backend for sensitive variables and just send minimal info thanks to Stripe Elements.
That said, the most common solution is JWT or OAuth2, and you could totally have a backend service or service like Okta, Auth0 or alike, do the heavy lifting by allowing simple logins to providers (Github, Google etc...).
To sum up, you do connect to this backend/service thanks to nuxt-auth, the service itself does the provider connection and you get the best of both worlds while still connected in a secure way through your initial nuxt-auth entry point login.
Or you could try to reach the community on Discord, see if somebody knows how to do it. Or even try to read the source code to see if it is currently feasable.
And that's my 2cts.
I want to make a list of goals for my family and I that we are all going to follow.
I generally know how I'll implement the list part. Just a todo-list-esque app where you only cross or uncross things off on it. I haven't decided with what I'll implement that part, mostly because I'm not sure how the multi-user part will go.
I figured each person can log in with Facebook or Twitter, and based on your login you'd be able to see what you've checked off.
I've never built a login before, or built based off of a logged in user.
Which web frameworks would be best for this? How would you implement this?
Since you said you know Javascript well, it sounds like you're best bet is to just use Node.js and a simple web framework like Express.js.
This will allow you to write you server-side code in Javascript, which should make the process simpler for you.
For handling authentication / etc., if you're looking for a stupid-simple authentication library you can use express-stormpath -- it supports social login as well as username/password stuff.
If you're looking for a smaller solution, you can use something like passport.js and use the third-party plugins for social login.
I recently finished one of my first AgilityJS projects, which is a web-based file browser that lets you create and manage folders and files, and navigate around the folder tree. I followed the various AgilityJS recommendations regarding the design and ended up with all my HTML and Javascript in a single Javascript file.
Now, I would like to provide a "read-only" version of this app which does not have the ability to add/edit/remove files and folders. I'd like to have 2 user types on the website, one type which can only read the files and folders, and another user type who can administer.
My question is, how do I proliferate these permission differences to my AgilityJS app? I know how to secure my endpoints and operations on the server side, but I'm wonder about the best way to do this on the client side. Should I create a separate version of the app with a limited set of functionality? Should I simply hide certain buttons/features? Are there theories, frameworks, etc.? which deal with this issue? Any point in the right direction would be helpful.
LOL - probably one could write books about that topic. Some very basic ideas:
I would start with the philosophical debate according to MVC. There are people argue with the help of MVC that any piece of code and also any piece of data model should never be implemented twice. Business logic and model to the server. The opposite view is focussing on serving users at any cost - even if that means to double maintain code or the model for the sake of avoiding extra round trips. The way in between defines a master source for business code and model and makes sure to follow on other places that leading master (the master will be changed first). Take your choice. Your answer to that question results into boundaries for how the user interface can/have to look like for the user.
You need to think by hard about a permissions concept. Looking at Microsoft I would assume that they invested for all their applications a couple of dozens man years to make up the permission concepts. The ideal permission concept very much depends on your application. So it is close to impossible to work this out without knowing at least a very little of your application. However the permission concept has to come up with policies deciding on roles, groups, access rigths, access levels, context driven permissions (eg. based IP address), permissions black or white listing (permissions each user has at creation). An example from Microsoft: http://office.microsoft.com/en-us/windows-sharepoint-services-help/permission-levels-and-permissions-HA010100149.aspx
Data on the client is not secured!!! Whatever you do on the client, be it data hiding, encryption, compression... - if this is done on the client there are ways to read the data (even by disabling the data manipulation) or by reverting those. Somebody can send data to your server, where the client should not even have given an update form could be implemented by hackers. So as soon as you start to implement permissions make sure, that for all data you send to clients users are permitted to read and that you inlcude permissions checking for each time you add/update data to the database.
I've been working on a web app in Clojure as a side project, and I'm trying to figure out how to do user authentication and autherization. From the googling I've done, I heard about sandbar, but after reading the two blogposts on sandbar (Part 1, Part 2), I left with more questions than answers. I've looked at the source code for 4clojure, and from what I can tell, they roll their own, the problem is that the code's not commented very well, if at all. I'm thinking I need to roll my own system and use either sandbar or noir.session to pass user information around. Could someone please point me in the right direction? I feel like I'm missing something simple.
Chas Emerick's Friend library is now available. It's still relatively new, but looks promising and quite well documented.
I had a look at the 4clojure login code and I think it is pretty clear how the implementation works. Basically it is the traditional HTTP authentication. Post user/pwd in form to a URL, check username and password and update the session with the user info that can be used for further requests to check whether this session is for a valid logged in user.
This is how most of the web app authentication works. Now this is "what to do" part of the situation, for "how to do" you can implement it your self using "primitive" features provided by the web framework or probably use some middle-ware that does this for you along with providing some hooks to customize the implementation a bit.
For authentication, apart from the obvious "rolling your own", I found https://github.com/mattrepl/clj-oauth to work well if you want to use OAUTH (e.g. via Twitter). Once you've acquired user information, storing it in some sort of session object (via ring-middleware-session or similar abstractions) seems to be the obvious thing to do.
For authorization, the way described in the blog post you linked to - wrapping certain routes with an authorization middleware (or whatever abstraction your preferred web stack offers - e.g. pre-route in Noir) works well.
There's also an alternative to Friend called Buddy.
What is the difference with Friend?
Buddy authorization/authentication facilities are more low level and less opinionated that friend and allow build over them easy other high level abstractions. Technically, friend abstraction can be build on top of buddy
I have an app that creates a couple of WebView instances and I'd like to have them operate as independently as possible.
At the very least, I don't want them sharing cookies. A quick google search gave me results liking "you can't." I'm hoping someone has a better answer.
The basic answer is "you can't".
After looking at this for a bit, I think it's possible, but extremely complicated. It would involve implementing a resourceLoadDelegate on your WebView that implements -webView:resource:willSendRequest:redirectResponse:fromDataSource: and modifies the request to turn off HTTPShouldHandleCookies and adds any relevant cookies to the request manually. It also has to implement -webView:resource:didReceiveResponse:fromDataSource: to find out about any cookies returned from the server. You can alloc/init your own copy of NSHTTPCookieStorage per-webview and use that to store/retrieve the cookies.
This post sums up what you could do. I'm not sure if it is feasible for you and I feel it wouldn't be a straightforward task, maybe even risky, but it seems to be possible: the author claims iCab does it this way.
I was hoping for a simpler solution too, really. Of course, since Webkit is open source you could just roll out your own version of the framework with changed behavior I guess?
I would assume that cookies would be configured on a service / application level and not for particular instances or processes. Perhaps you could revise your question to find a way to resolve the problem you are having which requires that the instances do not share cookies.
What is the motivation for not sharing cookies between the instances?
If you just need 3 views into the same web resource you could setup some virtual hosts that point to the same data source.
What you can do is take a look at libcurl which can handle cookie stores that don't mix with the URL Loading system wide cookie storage for those requests you want to separate. For me that seems to be a valid and simple solution. If you really need to depend on webview/webkit it might not be.