I'm new with angularjs...
I read the docs, and completed the tutorial; i also tried something else by myself, and things start to make sense to me.
Now i wonder how to make a safe authentication system.
The easy part: no code, i will describe operations my code execute:
I've a classic form: username, and password text input.
The user fills the form, and press ENTER.
An ajax request starts, and the response is a JSON telling me
something like "ok i know you" or "i don't know who you are".
What i need now is to mantain the logged status of the visitor (or not logged) between the different views of my application.
I read on the internet that, to achieve this objective, someone sets a variable ($scope.isLogged = true), someone else uses cookies; but javascript variables, and cookies can be easily edited using firebug, or similiar development tools.
... and finally the question:
So, have you some suggestion to achieve a safe authentication system in an angularjs app?
You cannot authorize anything in angularjs, because the user has full controll of the execution environment (namely, the browser). Each check, case, if - anything you can think of - can be tampered with. There are javascript libraries that use asymmetric keys to perform local encryption to store local data somewhat safely, but they are not what you are looking for, really.
You can, and you should, authorize things on the server - the standard way you would do it in an ordinary application - using session; no special code is necessary, ajax calls use ordinary session cookies. Application does not need to know whether it's authenticated or not. It only needs to check what server thinks.
From the perspective of your angularjs application, being "logged in" or "logged out" is merely a gui hint for the user.
Probably you found a solution, but currently I made up an authenticaiton scheme I'm implementing in my Angular App.
On .run the app is registered with an ActiveSession set to false.
It then checks if the browser has a cookie with a token and a userId.
If YES, check token+userId on server and updates the token on both server and local (token it's a server generated key unique for each user)
If NO shows login form, check credentials and again if they are valid does a server request t get a new token and saves is locally.
The token is used to make a persistent login (remember me for 3 weeks) or when user refreshes the browser page.
Thank you
I asked this question three months ago.
I would like to share what has become my favourite approach when I've to deal with user authentication in a web app built over AngularJS.
Of course fdreger's answer is still a great answer!
You cannot authorize anything in angularjs, because the user has full
controll of the execution environment (namely, the browser).
From the perspective of your angularjs application, being "logged in"
or "logged out" is merely a gui hint for the user.
So, briefly my approach consists in:
1) Bind to each route additional information about the route itself.
$routeProvider.when('/login', {
templateUrl: 'partials/login.html', controller: 'loginCtrl', isFree: true
});
2) Use a service to mantain the data about each user, and their authentication status.
services.factory('User', [function() {
return {
isLogged: false,
username: ''
};
}]);
3) Everytime the user try to access a new route, check if they have the grant to access.
$root.$on('$routeChangeStart', function(event, currRoute, prevRoute){
// prevRoute.isFree tell me if this route is available for all the users, or only for registered user.
// User.isLogged tell me if the user is logged
})
I also wrote about this approach (more in detail) on my blog, users authentication with angularjs.
First of all: Client-side data can always be manipulated or tampered with.
As long as valid session IDs aren't easily guessable and measures like associating session tokens with the client's IP there is no big deal about it.
You could, in theory, also encrypt the cookie, as long as you do so on the server side.
For details on how to encrypt your cookies, see the docs of your server-side (e.g http://expressjs.com/api.html#res.cookie for Express.js)
You need to learn about the server side / database end of it.
User logins need to be stored somewhere - 99.9% of the time this is in a server side database.
Ideally for a really secure system you want a backend (server side) membership system that stores the session in a database table that is related to the member table that holds the encrypted password, but also provides a RESTful interface where you can build your api calls to.
One Script that I've used successfully a lot has been Amember https://www.amember.com/. It's a really cost effective way to go although there are a lot of other script out there, I've had a lot of success with this one.. It's also PHP so you can build your build out an API for your angular http calls really easily.
All of these javascript frameworks are great but the effect is that now too many are focusing too much on the front end of things - learn the database / backend as well! :-)
Related
I am doing a Website 100% in ReactJS, It's a simple/medium complex, this has a Login, Profile and other sections more. After Users Log into the site the login callback returns some important values like: "Token, UserRole". Currently I'm storing these values in Web client using localStorage .
My doubt is the next: There is a better way to store this values? Because if any person changes the value from the Browser Console this could be a BIG ISSUE because they could change the role and then execute things that they never should do.
I thought to do it with Redux, but if the users Refresh the website then they lost the values, so I am not pretty sure to choose this.
What do you think guys?
TIA!
The general rule is to never trust any data stored client-side, except for an authentication token or the equivalent. All changes that the user makes that involves the server should be verified on the server. So, rather than:
if any person changes the value from the Browser Console this could be a BIG ISSUE because they could change the role and then execute things that they never should do
Instead, the right thing to do would be, when the client wants to do something (such as edit their profile), have the client send their authentication token (or session ID) with the rest of the payload to your server. Have your server examine the token, check that the user associated with the token actually does have the required permissions for what they want to do, and only then continue to process the request.
Whether you also happen to store some information in Redux or elsewhere has no impact.
Storing login-related information client-side is relatively common and isn't inherently bad - just make sure to always verify it on the server when something that requires permissions is requested.
One approach some use is for the server to create an encrypted JWT that only the server can decode, which gets sent with requests.
This is absolutely a newbie question & I am Node.js beginner.
I am not sure, this is right place to ask this question. But I may need idea from this large community. So let me explain what I am trying to do.
Server Configurations:
Node.js - 4.0.0
Hapi.js - 10.0.0
Redis
Scenario:
I am writing a proxy server in nodejs using hapijs. My Backend is ATG based e-commerce website and my api's are going to be consumed by web browser, mobile app etc..
We planned not to send the cookies sent by ATG to both browser and mobile.
So to maintain sessions and cookies from ATG,this is how we done POC.
First We planned without considering storing the anonymous user cookies returned from ATG. So we have done two POC's.
(Many of us know, what anonymous cookie is,any way let me explain that, if I put that one word -- Guest Checkout. There are many ways to accomplish this. But my Commerce Backend is implemented like this, When we go to website, you add items to cart and checkout that items without logging in right ? This what happens on background whenever we add the items they are only stored in your browser cookie,it not stored in persistent database, in any case user wants to login/signup to the account that cookie is retrieved from the browser and stored in database (basically that anonymous cart is transferred to logged in user.))
POC-1 (Not Considering Guest Checkout):
To access my api, user must be logged-in, after the successful login, We generate a rand-token and store it in Redis db associated with the cookies sent from the ATG for logged-in user and set ttl for 1 hour and return that token to the client
Now whenever they invoke any of api methods, they should send the token in the authorization header, I will check for token validity and expand the ttl once again for 1 hour and retrieve the cookies associated with that token, set that cookies in ATG request options and make a request.
3.On logout, I will clear the cookie and delete the token.
I have successfully implemented JWT fot this scenario, by generating a JWT token with user logged-in information in jwt payload. Used hapi-jwt-auth2.
POC-2 (With Maintaining Guest Cookies),
My API Will have endpoint /auth/generatesession, which in turn will return a 64 byte random token (we are using rand-token npm module for that) which will expire in 24 hours.
All the methods needs that access token passed back to me in authorization header and I will extend that token ttl to 24 hours.
Now they can invoke any api methods, like addtocart or something, even after adding items to cart , suddenly they want to login or something I can use their guest session cookie and transfer that cart to persistent database after successful login.
Questions:
Should I use JWT for the second scenario? If so,
How can I implement JWT for the Second Scenario? (Coz, don't know about who is the user?)
Does anyone think this is good idea for writing proxy server like this?
How can streamline session expiry of this token with ATG session Expiry?
Does anyone of using Node.js like this? How does it scale ?
If anyone care to give me an idea how to write this proxy server, it will be much helpful for me.
I Apologize, if this is too long question, just my way of explaining things.
Thanks in advance.
Sure, why not?
You don't necessarily need a user. A JWT stores arbitrary data, the username can be blank or anonymous. If a user logs it, and provides a token associated with a guest cart, then it can be assumed that that user is allowed to claim the contents of that cart, and the anonymous cart can be destroyed.
Sure, this is quite common (disclaimer: I've worked on something very much the same as you).
TTL is reasonable, but I have no idea what ATG is or how it handles it.
Yes. It scales very well as long as you ensure your servers are stateless, and that you manage all your state through something like Redis.
Too broad of a question, I would just use Express + Redis/Mongo/Postgres.
I've been fumbling around with different client side technologies, like AngularJS, EmberJS, even trying to use straight JQuery and figure out how to use ReactJS with it. That aside, my goal is to build a single page app using json in between the client and a Java Jersey 2 jax-rs back end api.
I have two stumbling blocks right now. Some info though..I am deploying my app as a WAR file in Jetty. My back end is java based. I am using only jquery in the client side as of now.
My main stumbling block is how to handle login, logout and session management. With an rest API and using ajax, I have login working, including it setting a cookie. My concern however is with a single page app, there is just the one index page, and if the user closes the browser, then reopens it to the index page while the cookie/session is still good, the user should be logged in, not see the outside (not logged in) page. I am unsure how to handle this, whether it be a jsp page, index.html with some templating library, etc. With JSP I can insert some scriplet code (against my better judgment). In the old days I'd include a header that would check for request.getSession().getAttribute("user") and if it was there..the user was logged in and using scriplet if() code I'd display a logged in header, instead of the non-logged in header. But I am in the belief there has got to be a better way to do this with todays client side JS frameworks.
The other stumbling block is the navigation and dynamic aspects. For example, when I was messing around with angular js, it was easy enough to use Welcome {{name}} and within the scope replace name with a json response value for the logged in user. In my current situation, I am not exactly sure how to best go about displaying dynamic bits like this with pure jquery other than using some sort of $("#elem-id").innerHtml="..." code within the response success method of an ajax call. As well, I am not quite sure how to handle navigation to different pages. My logged in site will have some drop down menus or links that will replace the content area with different varying amounts of content.
So first, what are some ways in a SPA to handle user sessions, in the case of a page reload, or close/crash browser restart.. to ensure the user is still logged in and direct them to the right page? Second, what sort of templating and routing/navigation options exist that don't require me to put a huge ton of code in my one index.jsp page?
Thank you.
If you're having a REST API as the back end, then you must have implemented oAuth as an authentication mechanism. That is, when your user logs in, using a username and a password, you exchange that data with an authentication token. This authentication token is sent your server with each and every API call and your backend validates this token before servicing the request. Clear so far?
What you could do is, when you obtain the access token, you can also obtain the access token expiration time from the server and store that data in your client side app. In localStorage maybe? And when your user closes the browser and reopens again, you can first check whether such access token is available (and not expired) before asking the user to log in. This should solve your first problem.
Secondly, if you're looking for a lightweight routing option, I recommend director.
I am building a similar application. OAuth is not mandatory. You can have normal sessions etc by hitting the jersey login endpoint and setting a session and a cookie "keepme" with the session if user wants to be persistently logged in. You can then have a jersey AuthFilter for example check if either there is a cookie with a valid session or an active session and keep the user logged in.
Your frontend application should have no say over this, just communicate with the server and if it doesn't get unauthorized access (from the AuthFilter) then continues otherwise it displays the login page.
I'm developing a new web site that will be a single paged app with some dialog/modal windows. I want to use backbone for frontend. This will call backend using ajax/websockets
and render the resulting json using templates.
As a backend I'll use nodejs express app, that will return the json needed for client, it'll be some kind of api. This will not use server side views.
Client will use facebook, twitter, etc. for authentication and maybe custom registration form.
Client static resources, such as css, js, and html files will be handled by nginx (CDN later).
Questions that I have now:
How can I determine that a given user has the right to do some action in api(i.e. delete a building, create new building)? This is authorization question, I thought of giving user a role when they login and based on it determine their rights. Will this work?
Similar to the above question, will this role based security be enough to secure the api? Or I need to add something like tokens or request signing?
Is this architecture acceptable or I'm over engineering and complicating it?
Passport is an option for the authentication piece of the puzzle. I'm the developer, so feel free to ask me any questions if you use it.
I thought of giving user a role when they login and based on it determine their rights. Will this work?
Yes this will work. You can check for a certain role on the user after it's been fetched from the server. You can then display different UI elements depending on this role.
Will this role based security be enough to secure the api? Or I need to add something like tokens or request signing?
It wont be enough. Anyone could hop into the console and set something like user.admin = true. In your API you'll need to validate a user token from the request, making sure that the related user has the appropriate permissions.
Is this architecture acceptable or I'm over engineering and complicating it?
At the least you should have an API validation layer. That would make a decent enough start, and wouldn't be over-engineering.
For the authentication part of your question i would use everyauth which is an authentication middleware for connect/express. It supports almost every oauth-social-network-thingie.
For role management you could give node-roles a try. I didn't use it myself but it should help you out, because it checks the role on the server side. Of course that is only useful if your API is implemented in node.js. If that's not the case, you have to "proxy" the API calls over your node.js app.
I hope I could help you! :)
I create js app with Backbone and RequireJS for registred or non registred users. To retrive data from database I use simple JSON web service and of course some of methods are not avaiable for quest. Problem is that I don't know where or how I should store auth data retrive from server without reloading it in every view. Should I use cookies ?
I guess it depends on your authentication, authorization methods as well as the kind of security you need to consider for your users. If you're trying to be RESTful, you can't have sessions to save state (at least server-side). You could, but it wouldn't be RESTful due to saving of state on the server, if that matters to you. I've heard that it is okay to save state client-side but from what I've read, I'm not sure how the community feels about certain implementations that take this approach. (Like cookies, I'll revisit this later.)
Say you have someone login with username and password. You can hold that information in your Backbone app, maybe you have a model called AUTH that does this. Each time you make a request to the server you'd send that data each trip at which point the server authenticates and gives or rejects access to given resources. If you use Basic Auth this information would be in the header I think. Using SSL mitigates some of the major security concerns surrounding the sending of this information over the wire and for the rest of the discussion let's assume this is what we are using.
The other way that you could do this is to use encrypted cookie, encrypted cookie sessions. This is what I do with my current application. Honestly, I don't know if this is considered a violation of RESTful principles or not. The general chatter on the web seems to be a lot of "cookies bad, sessions bad" with some people saying, "get real." Using cookies would expose you to cookie hijacking if someone had access to the users computer, but depending on your application and the security needs it might not be an unreasonable option. It works for me and if it isn't RESTful, I like to call it RESTLike.
To close I'll just describe my setup. It would be nice to get your thoughts as well as the Stack's opinions on this also.
Basically I have a setup where when someone goes to the main page, the server checks for the encrypted cookie session. If the cookie session is invalid or non-existent, it gives the user the regular page with a chance to login. When they login, I send that information over POST so it's in the body of the request rather than the URI. (This is technically a violation of the REST HTTP verb concept since you use POST to save a resource.) When that information is processed, check the username, pass hash created by a unique salt, then the server creates an encrypted session cookie and passes it back to the user. Now, each time my user hits a route that requires authentication, the server checks the cookie to make sure it is still valid (time limit, user information, etc.) and if so - allows access. If not, it destroys the cookie information and sends back an appropriate status code. The backbone app reacts to this by resetting any view and data that shouldn't be in the hands of an unauthenticated user and shows them the login screen.
Hope this gives you an idea. This is the answer to how I do it, but if someone has criticisms or better ideas I'd be happy to upvote them instead.