Also, you can achieve some pretty fast development velocity with .NET. C# is intuitive and the tools are great. I know everyone complains about Visual Studio, but even it's most vocal complainers will admit it sets the industry standard for debugging.
One sticking point is that the tools, while community and small projects, are all behind a license. But, they are free for small teams making under something like $1M/year in revenue.
JWT is just a token. It's not some panacea of client-side only authentication. There are a lot of people lamenting the difficulty in performing logout via JWT. I believe people are missing the point. The failing isn't with JWT, it's with the implementation of the session system.
Typically with sessions the client has a session key. The key gets sent to the server where it looks up the session (via. memory, cache, database, whatever). You can create a new session, validate an existing session, or end a session. All using that key. They only difference between JWT and cookies is JWTs aren't automatically sent with every request. You have to explicitly send them. I believe this is a good thing. It avoids some common attack vectors.
Is there anything wrong with saving the token in the cookie? I'm not exactly sure how to save them in the header. I'm guessing save it to localStorage and use javascript to pass it back to the server?
This article talked a bit about putting them in cookies:
The header method is preferred for security reasons - cookies would be susceptible to CSRF (Cross Site Request Forgery) unless CSRF tokens were used.
Secondly, the cookies can be sent back only to the same domain (or at most second level domain) they were issued from. If the authentication service resides on a different domain, cookies require much more wild creativeness.
As far as putting something in the header, if you're using javascript check out superagent. It's as easy as:
request(url).set('SomeHeader', 'SomeValue');
or the latest http fetch api just do:
var request = new Request('/users.json', {method: 'POST',
headers: new Headers({'Content-Type': 'text/plain'})
});
fetch(request).then(function() { /* handle response */ });
You can implement sign out everywhere by setting a reauth flag on the user in the database. You lose the "completely stateless" aspect that JWT claims to provide, but it's a small trade-off for tighter security.
But you're not storing the session there, just the key/token so you can change it. The session payload is still completely in the JSON body maintained by the client and sent with each request.
You only have to validate the token. It doesn't have to be a database-type medium because you're not writing very often in fact all you're really doing is making sure the token is not invalid. The session data could be changing on every request which would be at least one write on every request. With this system you are only writing to the central medium on a session creation or a session invalidation.
This is not entirely true. Since we talking about implementing stateful sessions, you could receive a valid token (stolen, out otherwise) after the user has logged out.
You are correct that the lookup doesn't have to be via the database. You could implement a caching system where the cache is invalidated when the user logs out and requires reauthentication. This is the notion of the session. By definition they cannot be stateless.
Stateless authentication is inherently (slightly) less secure than sessions. I think of a blind librarian who gives out keys to the library. Whoever has a key has access. You can put limitations on the timeframe someone has access to the library, but that's it. If your key gets stolen, the blind librarian can't help you as there is no way for him to tell if it's really you.
If the user reauthenticates and you unset the reauth flag, wouldn't their previous sessions (e.g. tokens held by an attacker) suddenly become valid again? How would you prevent such an attack?
You wouldn't use a boolean flag. I suggest setting a validity timestamp for the user, and reject any token that was issued-at any earlier time.
(This isn't a perfect scheme since a compromised issuer could have been induced to send post-dated tokens. If your need for global logout was to invalidate tokens issued by a compromised issuer, you'll need to blacklist keys as well)
Stores hold the state your Views use to render. This can include more than just the data backing the Views. It can include things like which item is selected in a list, if a link is active or not, and any error messages as well.
FYI, the "docker.io" repository in trusty points to an older version of docker (0.9.1). I believe the script at http://get.docker.io/ubuntu will install the latest version of docker.
yeoman seems to be involved very little, in this tutorial. It seems more like a bower/grunt tutorial. I was expecting to see yeoman used to generate models, views, and controllers. It's a shame because, I think this is where yeoman could really shine.
It's strange how so many people bag on rails and say its generators are useless but so many other techs have spent years trying to replicate that style of app development.
A friend and I get a lot of use out of a set of Backbone.js generators we created[1]. Even once you know what you're doing, I find generators a much more reliable way of producing the underlying code for projects.
Generators definitely have their place. They're good for prototyping, and creating internal tools. Tasks that are time sensitive and can really benefit from eliminating boilerplate code.
Larger LOB, or public facing apps require more thought and planning to ensure that they get the job done right.
You don't have to treat generators as CRUD only things though.
What's wrong with creating an app generator that spits out enough stuff to get you going on a certain app?
If I don't have to spend 15 minutes making a bunch of small changes and additions every time I make a new project then I will be more likely create more projects.
It's part of the reason why building a SOA is painful. If you have 25 services that means you need to start 25 new apps. It might take 20 hours of boilerplate garbage that you have to do just to start developing the business logic.
With generators you can turn that into almost no time at all, you would be bound by how fast your hard drive can write the files to disk or how fast you can pull things from github.
Btw I also use generators for public facing things. Why? Because typing 1 command which generates 6-7 files and also gets me going on what needs to be replaced is a lot faster than starting from absolutely nothing.
It doesn't matter if I end up replacing 100% of the view code or 90% of the controller code. Also if I feel like I will be doing a lot of CRUD'ish things in similar ways then I will spend 15 minutes once up front and create custom generator templates for that specific project.
It's nice to be able to type 1 command out and get a fully working scaffold with your custom theme and changes already applied complete with elastic search integration and faceted navigation, etc.. I do this all the time when applicable.
You hold Ctrl (or Shift+Ctrl) while you tab to cycle all the way through all your tabs. The first time you press the combination, it switches to the last tab you were in. This is how it is in version 2, anyway.
This is the nature of using any third party software or API. If you're not going to write it yourself, then you have to be willing to play by someone else's rules. Words I learned to live by years ago.
Coincidentally, this is how I feel about AngularJS. By using it, you're developing apps the way Google wants you (or it's own developers) to. It could be good, it could be bad. it depends on the app, but you still have to do it their way.
You don't want to be locked into Google's walled garden, but, by using Angular, you're already inside...
His views aren't the issue, his outspokenness is. How could a woman ever feel comfortable interviewing with this guy, let alone, working for him. What if said woman was a great fit for the company and had a lot to contribute? His ability to hire and fire effectively is compromised. Not because of his views, but because he couldn't keep his mouth shut about them.
Sometimes knowing when to shut the hell up is a far greater asset than being outspoken and opinionated. Especially about things related to your job...
One sticking point is that the tools, while community and small projects, are all behind a license. But, they are free for small teams making under something like $1M/year in revenue.