Everyauth and Passport.js seem to have very similar feature sets. What are some of the positive and negative comparisons between the two that would make me want to use one over the other?
Chiming in with my two cents, as the developer of Passport.
Before developing Passport, I evaluated everyauth and determined that it didn't meet my requirements. So, I set about implementing a different solution which would. The major points I wanted to address are:
Idiomatic Node.js
everyauth makes extensive use of promises, instead of Node's approach of using callbacks and closures. Promises are an alternative approach to async programming. While useful in some high-level situations, I wasn't comfortable with an authentication library forcing this choice upon my application.
Furthermore, I find that proper use of callbacks and closures yields concise, well architected (almost functional style) code. Much of the power of Node itself comes from this fact, and Passport follows suit.
Modular
Passport employs a strategy design pattern to define a clear separation of concerns between the core module and various authentication mechanisms. This has a number of benefits, including smaller overall code size and well defined and testable interfaces.
For a basic illustration, compare the difference between running $ npm install passport and $ npm install everyauth. Passport lets you craft your application using only the dependencies you actually need.
This modular architecture has proven itself adaptable, facilitating a community that has implemented support for a wide variety of authentication mechanisms, including OpenID, OAuth, BrowserID, SAML, etc.
Flexible
Passport is just middleware, using the fn(req, res, next) convention established by Connect and Express.
This means that there are no surprises, as you define where you want your routes and when you want to use authentication. There are also no dependencies on a specific framework. People are successfully using Passport with other frameworks such as Flatiron
In contrast, any module in everyauth can insert routes into your application. This can make debugging difficult, as it is non-obvious how a route will be dispatched and leads to tight coupling with a specific framework.
Passport also errors in a way that is entirely conventional, next-ing to error-handling middleware as defined by Express.
In contrast, everyauth has its own conventions, which don't fit the problem space well, causing long-standing open issues such as #36
API Authentication
The crowning achievement of any authentication library is its ability to handle API authentication as elegantly as web-based sign on.
I won't elaborate much on this point. However, I encourage people to look into Passport's sibling projects, OAuthorize and OAuth2orize. Using these projects, you can implement "full-stack" authentication, for both HTML/session-based web apps and API clients.
Reliable
Finally, authentication is a critical component of an application, and one you want to be fully comfortable relying on. everyauth has a long list of issues many of which remain open and resurface over time. In my opinion, this is due to low unit test coverage, which itself suggests that the internal interfaces in everyauth are not suitably defined.
In contrast, Passport's interfaces and its strategies are well-defined and extensively covered by unit tests. Issues filed against Passport tend to mostly be minor feature requests, rather than bugs relating to authentication.
Despite being a younger project, this level of quality suggests a more mature solution that is easier to maintain and trust going forward.
Passport
modular and transparent
good docs
community contributions (owing to it's modularity)
works with everyone and their dog (again, owing to it's modularity)
Everyauth
long development history, mature.
no longer maintained
great docs
works with a wide range of services
Just finished changing from everyauth to passport. The reasons were the following.
Everyauth is not stable enough. The final straw was last week I got bitten by a mysterious issue where facebook authentication would work on local.host and on the production environment, but not in my test environment on heroku, even with identical code and databases and a new heroku app instance. At that point I ran out of theories as to how to isolate the issue, so removing everyauth was the logical next step.
The way it provides support for standard authentication using username/password credentials is not easily integrated with a single page web app approach.
I was unable to get everyauth to work with Google accounts.
Active development of everyauth seems on the decline.
The port was surprisingly painless, only taking a few hours, including manual testing.
So obviously, I recommend going for passport.
I tried out Everyauth first and have since gone to Passport. It struck me as somewhat more flexible, esp. if (for example) I need different logic for different providers. It also makes it easier (imo) to configure custom auth strategies. On the other hand, it doesn't have the view helpers, if those are important to you.
This answers a bit late, but I found this thread and (after hearing all of the negative feedback about Everyauth) decided to use Passport ... and then hated it. It was opaque, only worked as middleware (you couldn't authenticate from a GraphQL endpoint, for instance), and I hit more than one hard to debug bug (eg. How do I have two Express sessions?).
So I went looking and found https://github.com/jed/authom. For my needs this is a much better library! It's a bit lower-level than the other two libraries, so you have to do things like putting the user into the session yourself ... but that's only one line so it's really no big deal.
More importantly its design gives you a lot more control, making it easy to implement your authorization the way you want and not the way Passport intended. Plus, compared to Passport it's a lot simpler and easier to learn.
I used to use Everyauth more specifically mongoose-auth. I found it hard to split up my files properly without dismantling the everyauth module. Passport in my opinion is a cleaner method for creating logins. There is a write up that I found very helpful http://rckbt.me/2012/03/transitioning-from-mongoose-auth-to-passport/
Note the date of this post, it will indicate how relevant this post is.
In my experience, Everyauth didn't work out of the box with it's password login style. I am using express3 and I declare my middleware like so app.use(everyauth.middleware(app)); and it still wasn't passing in the everyauth local to my template. The last git commit was a year ago and I figure new packages have broken everyauth. Now I'm going to try passport.
Related
I've implemented my code base using #hapi/joi, but I've recently come across express-validator, which appears to do all the same stuff, but is a lot simpler to use. I've reviewed some of the questions here on this topic, but they're mostly dated.
I realize this may be subjective, but when would you recommend I use express-validator over #hapi/joi? Maybe express-validator just works better b/c I'm using Express, which is what this module was built for.
I'm asking b/c all the tutorials I've used make use of #hapi/joi and I can't understand why. Maybe I'm missing something obvious.
What I really like about express-validator is how easy it is to use sanitation in Express routes and barring anyone having problems w/it, I may switch permanently. #hapi/joi has this ability too, but it's harder to implement IMO.
#Gary.
hapi/joi allows you to create a blueprint for your validation, while express-validator uses the validator.js.
Obviously while working with express projects, you'll find express-validator can be used out of the box, without much configuration, and that is exactly where I will use express-validator.
When I need to set up validation for my requests, and I'm not much bothered about the level of customization and readability in my Validating params.
If you want to see a critical approach and comparison between the two, there's a great blog by 101node.io: https://101node.io/blog/javascript-validators-comparison-using-joi-vs-express-validator/#:~:text=express%2Dvalidator%20is%20a%20set,js%20middlewares%20that%20wraps%20validator.&text=Joi%20can%20be%20used%20for,library%20and%20easy%20to%20use
Happy Coding !
Alright, so I'm currently coding a Web Application with Node.js, and I'm a bit stuck on how I should handle user logins/authentication.
Lots of tutorials seem to recommend using Passport for your authentication, but from all the documentation I've read, it seems to take a bit of setting up and it complicates the simple login I was expecting.
Whether or not I use Passport, I still plan on hashing my user passwords that are stored in the Mongo database.
So the question is, do I need to use Passport for security reasons, or can I just code an authentication system my self?
It's really up to you, if you don't need Facebook, Google, or Twitter logins or are fine coding your own, I would just build it from scratch.
I built an application that didn't need all the bells and whistles that Passport came with, but needed it's own security built in, and found it much easier to just make my own. It's so easy to include your security as middleware in node!
I think it depends your use.Generally set a password is necessary, and use passport is not complicated in Nodejs .Of course ,if your application is used in internal，password can be ignored.But I think security is provided.
I'm designing my user authentication system using Node.js/Express, and as I've been searching the web for authentication strategies, I noticed that a lot of developers recommend passport.js for helping with authentication.
My authentication will only ever use a username/password strategy with JSON web tokens. Under that assumption, it seems like I have to manage the entire authentication myself: I check the username and password against the database, and I check and attach JWTs. It seems like Passport only wraps my work inside it's own functions.
With only a username/password strategy, what use is Passport? What does Passport provide in this scenario that is of any real benefit over me just performing the authentication without it?
Passport give you more flexibility and scalability. Now, you need one specific strategy, but in future you can add additional or remove old one. Using modules like passport you cause that your application code is independent of some processes. It is almost like dependency injection, you inject strategy in opposite to hardcode this.
I thing, that good application should have as much as possible functions/modules, that allow to inject polices/strategies. Separate modules is also nodejs/express style.
If you code your authentication in same style, then it is super (but why reinventing the wheel).
Using passport you can inherit from base Strategy and create new one strictly for your needs and use it with other strategies.
Never. Ever. Implement. Your. Own. Security. Framework
Unless you actually want to implement a framework and you have all the resources in the world to do that, all the required knowledge and the key people ( like OWASP ) & etc etc.
Use existing lib for your project
Use a library, or a framework, that's open source and battle tested. Yes it will not be perfect and will have limitations. Yes it may not be the most secure code ever. BUT it will be much better than your own, especially if you're starting from scratch.
Then follow best practices for CSRF, XSS, DDoS & other kind of attack prevention.
I'm trying to secure my play application but I have no idea where to start. In play tutorial I have not found any chapter about that topic. As far as I see security topic is changing between play versions. So what are You guys using to secure Yours applications.
I'm new in Play so please forgive me if I'm asking obvious questions.
Edit:
Ok, maby question was't clear enough(I'm really sorry about that). When talking about security I mean that I need something to deal with users credentials and tool which allows me to restrict access to some pages and eventually to some rest actions in my application.
Edit2:
I'll try deadbolt2 now and we'll see how does it works. But I still encurage You guys to share Your knowledge about Play security with others:)
The documentation seems to still be a bit lacklustre on this topic, but essentially, authentication/authorisation functionality is usually performed using Action composition, which is the basis of reusable controller code in Play. There an example here (also linked from the docs that should help give you the general idea.)
Action composition in Play 2.2.x is done using ActionBuilders. These take a block which accepts a request and returns a Future[SimpleResult]. This allows the action builder to either execute the given block, or return a different Future[SimpleResult] (say, an Unauthorized in the case that a user's credentials did not check out.)
In our app we use the Play2-auth module for handling authentication with session cookies. This has (just) been updated to work with Play 2.2.x but uses a slightly different mechanism for action composition (stackable controllers.) You might be best off working out how the precise functionality you need can be accomplished just using the native framework tools before adding a dependency to it.
I agree with the other answers but just add that I use securesocial to integrate with other auth providers (google, FB, etc...), so I don't have to do auth myself. It's quite easy to get up and running.
https://github.com/jaliss/securesocial
Access control, security, etc. is a very wide topic, because it means very different things depending on context. This may be one of the reasons why Play has little documentation for it, which puzzled me at the beginning as well.
Play2 has some security helpers, namely it's the Authenticated method, for some insights on how to use it, check the comments in the source code. Its a simple method that you could implement yourself, and most do. It, essentially, just proposes a structure for where to place your methods that would check if request is authenticated and what to do if it's not.
Play2 also has some cryptography logic, which is used for signing cookies.
That's about it, you don't have any more pre-built security structures, but that's a good thing, because you don't want the framework making decisions like that for you, if it doesn't know in what context it will be used.
What is essential is to go and research how attacks relevant to your application are carried out, best practices and so on. I recommend going to OWASP, particularly the OWASP Cheat Sheets. If the list of Cheat Sheets seems intimidating start with the OWASP Top Ten Cheat Sheet. Don't mind the large volume of information, it's very useful knowledge.
Akin to this question, "I'm looking for the pros and cons of each framework and why one is particularly useful over the other" (but mostly what Flatiron has to offer, due to the fact that Express is already detailed pretty well in that question).
From my slight experience with Express, it seems to cover just about what you need and no more. Flatiron seems to do that, but much more minimalistically. If you check their website, you see that they offer around 5-7 main functionalities, compared to the many others included in Express.
Finally, which seems the most promising for a highly-scalable web app(s), and why should I use this or that framework over not using a framework at all?
Some update after a year and a half after this question was asked:
The first difference that comes to mind when comparing Express to Flatiron is that Express is a server-side framework while Flatiron is advertised as being isomorphic, covering both the server side and the client side and as such should be suitable to develop traditional server-side applications, client-side single-page application and everything in between (much like eg. Derby or Meteor). However, I have failed to find any examples of client-side usage of Flatiron, and not for the lack of trying.
There is an issue on GitHub to provide a simple TODO app example that's been open for over two years and (from what I understand reading the comments there) you cannot build a client-side app using Flatiron alone, without adding things like jQuery, Backbone etc. because the client-side aspect of Flatiron doesn't seem to be ready yet ("We are working on it. We still have a few more steps to go to make it completely isomorphic.") which seems like a real problem for a framework that tried to be isomorphic from the start. (See also a related TodoMVC issue: Add FlatIron example).
The conclusion is that Flatiron is not ready yet. When it is ready it may cover much more areas of Web development than Express does, but it's really hard to tell when it might be, if a simple TODO app example couldn't have been provided for years.
Meanwhile there are tons of Node frameworks and it's really hard to keep track of them so what I'd recommend doing now and in the future would be to see the list of Web frameworks on the Joyent/Node wiki on GitHub and compare them to the client-side frameworks on the TodoMVC project - where those both lists intersect would be frameworks that cover both the server and the client and are capable of writing a simple TODO app in them - which hopefully will include Flatiron one day.
my perception is, that express is minimal, while flatiron seems to be more complete/complex.
The best for scaling is a hard question, because both don't do anything to increase scale-ability of your app. They make developing an app easier by providing easy ways as exmpl to add routes (instead of yourself going insane with own faulty regexp).
Personally, I've come to love all the little connect and express middleware, as well as dynamicHelpers(for templating), which doesn't seem to be supported by flatiron (yes, they have middleware, but it doesnt seem as if you could use the ones from connect. EDIT; as it turns out, Union, which is flatirons middleware handler is compatible to connect, so you can use connect's middleware).
I'd recommend someone to use express over flatiron, but then again; I'd like to be proven better.
It looks to me that the battle Express vs. Flatiron is clearly won by Express.
There is no active development for Flatiron framework ATM.
See GitHub repository: https://github.com/flatiron/flatiron.
The last release is 0.4.2 from Sep 16, 2014.
The official flatiron website http://flatironjs.org/ is down.