The Sails project in this case is only going to serve as an RESTful API. We’ll be using Aurelia on the front end, so we don’t need any presentation. What we do need is authentication provided by the API.
So my local auth implementation went through a few stages and much hair pulling. I first took a look at sails-generate-auth. This seemed like a great starting place…but I ran into some issues:
- You can use tokens to protect the API, but the social auth implementation is geared towards server emitted UI by default. I want something more SPA oriented.
- It doesn’t use JWT currently although it supports bearer tokens.
So I moved on to Waterlock. Waterlock has a lot of cool features and is super-easy to set up. In addition, it appears to be more oriented towards a SPA/API implementation.
But I ran into some issues: It uses session in situations where tokens are being used. This defeats some of the advantages of using tokens and reduces horizontal scalability. Some remedies to this are being worked on, but have been stuck in pull request status for several months, although it looks as though they may be resolved soon. So I figured I could just reference the github fork instead from npm until this gets resolved…but was still concerned about it using session.
And then with local auth in Waterlock: There is no register endpoint. There is a login endpoint that auto-registers you if it can’t find you. 😦 So if you fat-finger your username it just goes ahead and makes a new user. Again there is a pull request that hasn’t yet been merged.
At this point I decided I needed to keep looking. I could try and get those pull requests across the line but I’m already leaning away because of the opacity/complexity of the library as a whole and the session requirement. I don’t need something this complex but it’s a great reference implementation.
So next I found a Yeoman generator for Sails that was specialized for API’s and implemented with JWT based auth. This is a really cool project and major kudo’s to Eugene who was also very responsive to questions. But then when I felt so close: The Yeoman generator failed because of a Windows file system issue. I think probably a path length issue due to nested npm packages. I’ll see you in hell Windows file system!!! Eugene mentioned that he hadn’t tested it on windows…so there it was.
This may have been a good thing because the generator/template also outputs a lot of functionality that is both very cool and yet unnecessary for my project. The upside being that you can blow out a complex API in almost no time, but I didn’t want to go through and attempt to clean out everything that I didn’t want/need. I also wanted to go through the process myself so I understood it better.
So I used the generator templates as a reference project and borrowed some great things from it including updated API blueprints and a basic approach for issuing and validating JWT tokens.
So hopefully if you come across this post and are in a similar boat (npi), I can save you some of my frustration (aka “earned knowledge”). I’ll be adding the implementation information in the next post, but a reference implementation is already available in GitHub. Hope that’s helpful!
Next in series:
Nozus JS 1: Intro to Sails with Passport and JWT (JSON Web Token) Auth
3 thoughts on “Nozus JS Preface: Sails with Passport and JWT – Ermahgerd!”
Geez, I’m in the same position as you. I’m looking for projects that do not have sessions involved. Thanks for the write up!
I hope that dependency-check will fix the issue with Windows FS, so my generator will be able to run on Windows too.
Thanks so much for this series as it’s been a pain point for quite some time. If you update to npm 3.x on windows the path issues should disappear. I hope to contribute with an aurelia example using fetch with this api.