I have an application that uses backbone.js on the front end. So I had a question of how does it handle the user session? Everytime i send a GET,PUT,POST request, the user has to be authenticated else I get a error from the server side. Hence I used the Backbone.basicauth.js plugin which enables the basic authentication before any requests are sent across the server. I just need to call Backbone.BasicAuth.set('username', 'password');
But the problem here is that I need to hardcode my username and password everytime. So I wanted to know a way where in I can dynamically do that or a way in which I can track if a user is already logged in or i need to redirect him to a login page.
What if the user enters a random url instead of the home page, how will I track if he is logged in or not and how will I save the session?
At www.TheLadders.com we use form authentication and then drop a cookie with an encrypted token which we use to authenticate subsequent requests. We like it better than a traditional server side session approach because we can run all our servers stateless.
Related
I'm currently using a NodeJS server. I verify a condition with a if statement. If the credentials are not valid, for example, how to send the user to a specific page?
if (credentials) {
// go to the main page
}
else {
// go the login page
}
You've said you're using ExpressJS. In ExpressJS, you do a redirect via res.redirect:
res.redirect([status,] path)
Redirects to the URL derived from the specified path, with specified status, a positive integer that corresponds to an HTTP status code . If not specified, status defaults to “302 “Found”.
First, you need to establish what kind of authentication you are using. There are a million ways to do this, but if you are less familiar with auth systems, I would recommend using a third-party auth system like Facebook or Google login. Those would generally give you some kind of auth token on login, and essentially you could just check to see if the stored token is there, whether that be in cache, cookies, local storage, etc., and if it has not expired. If all is good, keep going, if not, then redirect to the login page.
If you want to make this more secure, don't write any of credential validation on the client side. Have the client's browser check for the auth token and its recency, then send it to the server. The server would then respond by routing you to the proper page.
Another method that should probably be used in tandem with this would be to check for a valid login on every single page where the user would need to be logged in, as opposed to only having the one page that redirects to either a login screen or where you want to go.
I'm working on a React application. I am defining user roles and restricting access to components based on the permissions level of the role. I am looking in to using signed cookies to set the permissions from a php backend. When I determine whether the application should render a component based on the data in the cookie, how do I verify that the roles in the cookie have not been redefined by the user without sending the cookie to the backend?
That's not the right approach, in my opinion. The components should be free to load - if there's something built-in to a component that an un-authenticated user shouldn't be able to see, there's nothing stopping someone from going into the source and discovering it themselves.
You have to take a different approach for front-end applications - all the components and UI are public. When the component fetches information from the server to display to the user, the server will still do the session authentication and respond with a 4xx (401 would be a good place to start) and the component would handle that response appropriately.
If modifying the role in the cookie would allow the user to gain more rights, then the solution is not to check the validity of the cookie on the client side. The user could also modify the client side script to circumvent/skip the integrity check of the cookies, and you would have the same problem as before.
The only correct solution is, that the user won't get those informations/scripts at the first place. So you need to check on the server side what informations are allowed to be send to the client, only send the data the user is allowed to see, and verify all actions the user sends to the server on the server side before you execute them.
I'm working on a quite simple Node.js server. The users authenticate via a plain username/password form and the server - after checking a db - grants or refuses the access to the other pages.
To keep track of what each user's doing I'm going to generate a UUID to send on login. When a client asks or sends anything to the server it will include this UUID so the server will know who is the user.
The questions are about the life-cycle of these UUIDs:
when I must remove a UUID from my local array? I.e. when the user "disconnects", I guess if it explicitely logout or after a timeout of inactivity. I don't want to disconnect if he puts in standby his smartphone for a while.
if the user reloads the page when his session is still alive, I want to avoid a new login: I need a way to understand the connection is from the same user. How would you achieve this?
What I would do is use JWT. I would ask user to login using username and password and then issue them a JWT with payload containing the user's identifier (username or id) and with a set expiry which represents the max inactivity time allowed (depends on your business logic), say 5hrs. I can also contain last logout date etc.
Now user sends this JWT in his header whenever he's making requests to your services, you can decode that token and check if user logged out (tokens last logout time is less than the user's logout time).
You can keep track of various things.
There may be other ways also, using sessions.
I would like to use Apigility and Jquery as a login strategy into my application. I am struggling to understand how to do this.
My setup is as follows:
The client and the Login api are trusted as they are both part of my application.
What I am struggling to understand is the process of taking the username and password from my form, processing it in JQuery, then using the Apigility authorization strategy to ensure that the request is genuine and to pass it securely onto the required login end point.
I have a standard login form:
The user enters a username and password and clicks "login".
Jquery validates the data and now I need to send the users credentials to the Login End Point... How to do this with ApiGility, I am not sure...
I have been reading the documentation here: https://apigility.org/documentation/auth/authentication-oauth2 and I don't quite get it.
This is what I have setup with ApiGility.
I have created a Login end point in ApiGility
This end point can only accept a Post request.
The end point requires authorization to be accessed.
Now how to interact with this?
As I am using a client side script (Even though it is my own app), I cant use traditional Client id and password as there is no way to secure this information in JQuery without exposing it to the world.
In its place, I should use an implicit grant, i.e. a client identity, with no password.
To get an implicit grant, I need to re-direct the user to Apigilities: http://example.com/oauth/authorize?response_type=token&client_id=testclient2&redirect_uri=/oauth/receivecode&state=1 end point, ensuring I include the user name and password in the post request.
When a user is re-directed, they must click on a yes or a no button, if yes, a token is created and a session is generated (storing the customers username and password) and returned. This token I store on the customers machine, using a session.
Now that I have a token, I use this token to gain access to my secure Login End Point.
Once I have access to the Login Controller, I now use the token to get the username and password from the session.
Finally - check the credentials and return: true / false etc.
How close or far off am I?
1. Yes you can, as long as you use a properly configured (secure) https connection. By using a security certificate you will ensure encryption of the data being sent and received by the client and it will be unreadable when intercepted.
2. When using implicit grant you will still need to authenticate your client with a username and password. Check the workflow here in this OAuth documentation.
My idea is you are missing the fact that you need a secure connection. I would suggest setting up https on your server and then follow the Apigility OAuth documentation. It seems quite complete and I think you should be able to manage by following their instructions.
I have several web pages that should work only if certain condition is true. For example, there is a registration page, a login page. If someone is already logged in, I don't want the user to login again or register again until he is logged out. Currently the server saves the login in a SESSION variable and each web page has to called the server to get the SESSION variable and determine whether to display the page or not. This does not seem like a good solution. I am thinking may be saving in on the client side, but I don't know a good approach. Should I use cookie for this ? Is there some other services on the client side to store session data ?
Cookies are the best option for session details involving login, any other persistent storage should use localStorage.
This is because cookies will be transferred to the server on each request and therefore can be used to authenticate each call.
If your confused about this sort of stuff it can be very dangerous for your site. Try read up on it and try to use whatever the standard is for your language/framework/library.