I want to learn what is the best practice to check login status at client side. What I am trying to do is checking user's login status and if he is not logged in open popup box (login box) using JavaScript.
I can think of 2 options
Make an AJAX call to server and get the login status.
Have a variable in your HTML page and check this variable with
JavaScript at client side. Of course I do not trust this check, I
still have all the necessary checks in my controllers at server
side.
Option 1 is good but it can add some latency/delay so it may not be the best option in terms of user experience. Or am I wrong, with a good server (I am planning to use amazon web services) this delay will be so minimum and user will not understand it (Question may look silly but this is my first web development so please be understandable :))
I can't see any problem with option 2, please correct me if I am wrong. As I said I am trying to understand the best practice.
The best way to avoid server hit/network latency as well; You can put a client variable which has the login status (as you said in your question), but main thing to avoid server hit and network latency (AJAX), You just use the same logic which is at server side to set the login status as false. Suppose say the logic is to sety login status to false after 5 minutes of inactivity, You can do the same at client side as well.
So overall I mean to say is, Implement the same logic at client end to set the login status false. and based on that you can show your login dialog immediately with any latency. And in BEST PRACTICE you should always do double verification i.e. at server end on each and every requests for authenticated stuffs you should check that the client login status matches the server login status, since the client's login status can be tampered one.
Good Luck... Happy exploring :-)
Option 1 seems the best, how can you otherwise know if the cookie you save the user id in was not tempered with?
As far as I know the best practice is to add a hash to the cookie (you can see google doing that in their cookies), and then use that to check if the data in the cookie is valid on the server side, using a secret and or salt.
http://en.wikipedia.org/wiki/Hash_function
http://en.wikipedia.org/wiki/Salt_(cryptography)
what you could do anyway though is check if a cookie exists with userid in your client side javascript, and if not, then send the user to the login page.
https://developer.mozilla.org/en-US/docs/DOM/document.cookie
that way you don't need a server round trip for obviously logged out users.
However, can't you on the first request the user makes to your serveralready do the checking? and if the user is not logged-in respond with the login page?
Related
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 sorry, I'm having a mental block: I'm not sure what I should send to a JavaScript front end (client) after a user authentication on the server. I know that there needs to be some controls for the user (user/admin)to click but I'm not sure what to send that's secure and what not to send that's not secure. I've been told hidden controls are not secure. I know how to implement user authentication on the server. I understand a check on the server needs to be made if a control is clicked to check if the user (user/admin) has the right permissions for that control before the server executes the control function (on the server). I know I can set a variable and send it to the front end, once it's received (Ajax response) add controls (appendChild). If I do it this way, I feel it's not secure because all the code to do this is easily viewable by the browser (page source).
Permission checking is on the server side, so even if code is viewable why you afraid about this?
After success login action you can send cookie to store session on client side or JavaScript variable if this is Single Page Application.
On the other hand - after login you can redirect to secure place and present HTML with all necessary inputs / fields. Users without login won't see secured templates.
But always remember to do not trust any data from client, checking permission on back-end side is only one good thing.
When working on an Angular app, I have a single page app that communicates with a JSON web service for data.
A "login" in my Angular app is really just exchanging a username/password for a token. That token is passed as a header on all subsequent requests so the server can authorize them. This works great until the users refreshes their browser window of course (via refresh or leaving the "page" and returning).
Obviously one option would be to make the user enter their username/password again, but that seems like a good way to not have any users.
I can think of 4 options:
Store token in a secure session cookie. (What I'm doing now. I am only using so the client can read. Not used or wanted on the server.)
Store token using local storage of some kind. (Would be insecure and
require manual expiration maintenance.)
Prevent user from refreshing browser with some "onbeforeunload"
code. (I don't like when I get the "are you sure you want to leave
this page" messages and I assume others feel the same.)
Include token as part of url. (Could make url's look big and messy. Possible physical security risk. Might make for extra work with bookmarking and expired tokens.)
Is option 1 the best option for this functionality? Is there something better to do than all of these?
I think option 1 is the best one for your use case. All major web frameworks have support for this option.
In case you need to handle this manually you need to ensure these steps:
The web service will process the initial authentication request by creating and setting a secure authentication cookie. The auth cookie should be time based(only valid for a specific time interval) and its value should be a unique value if possible;
After the initial authentication request all subsequent requests will pass the authentication cookie with the request header automatically - this is handled by the browser.
The web service needs to handle cookie based authentication on subsequent requests by validating the cookie value and returning an error if the cookie has expired.
You need to ensure a client side global authentication handler captures any authentication exceptions and displays a friendly message to the user.
I have two web pages that I am trying to send information between. One is the login page that takes in the users information and calls a web-service to determine if the user is authenticated. Upon ensuring authentication I want to redirect to my other web page with some way of telling that the user has logged in and is authenticated.
I know that javascript has window.location = url but this does not forward the authentication header or anything else as far as I know. Is there a way to redirect with authentication headers or other way to tell the user is authenticated?
Thanks for any help.
There is not a standard method for doing that since javascript is a client side language but you have some alternative low-security solutions.Sessions are not necessary to function a client side language also for the better security you better stick to PHP or some other server side language.Because javascript can be easily skipped and it might put you in a trouble.
Just use your authenticated language for session and header functions also.
Hope this helped,
Regards.
I am writing an application using Sencha Touch that will require a login to the server. I need a way of keeping track of the session, but I'm not sure what the best way of doing this is. It seems that in HTML5 there is 'sessionStorage' which can be used for this.
From what I understand I need to do the following:
1. Send username/password to server
2. If combo is correct, server sends some session ID variable to phone
3. Phone saves sessionID in sessionStorage
4. Every time the phone communicates with the server it sends sessionID with message
5. Server checks a message for correct sessionID (and possibly checks IP address too)
6. When user logs out of app, sessionID is wiped from phone and server
Can you please let me know if this is the correct route to take?
I usually have handled everything on the client side stored in a JS object. Not sure if it's a best practice or not, but it has worked for me. If I'm storing a password I encrypt it and only match it with the hash to see if it is valid. For session time outs you can set up a timer and for every Ajax request check whether the "session" is still valid.