I'm developing a webapp, purely on JS and Rest WS. Deployed on Weblogic.
Using FORM Auth for Login and Session Invalidate for Logout.
For session timeout I've two logics
1) web.xml session timeout configuration
2) JS timer, that checks for click or keypress event else calls Logout servlet with param as sessiontimeout
Now the problem is, Say the user is Active at client side by accessing JS files but hasn't made any REST WS calls, I cannot show any notification to USER as the SESSION is timed out. This is because of Logic 1, that does not allow me to configure any way to specify which page to redirect or pass any request parameters.
Logic 2 works fine, the moment the client is inactive for 30 mins it calls Logout?sessionTimeout=true servlet with request params from Client, which solves my problem. BUT this happens very rare like 10 in 100 cases and 90 times its Logic 1.
The only solution I can think of is remove web.xml session config and just have JS session timer check and invalidate if TRUE. BUT is this a correct approach/design ?
Experts please share your thoughts.
You want to maintain most of the timeout logic on the server (where it's less-likely to be modified/hacked) and create a service which can be called from the client that periodically asks the server if the session it has, is still valid.
A best practice would be to generate a token for the user at the start of the session and pass that with the first response; potentially saving it in a cookie. The token's identity and expiration time is maintained by the server.
The client would check, say every 30 seconds if the session is expired by reading the token id from the cookie and passing it to the server in an AJAX call. The server then responds if that token is valid or not. When the client receives a not-valid response from the server it then navigates the user to a login page.
On the server side, if you get a request for a page and the cookie passed includes a token that is either not recognized OR expired, then just redirect the user to the login page.
Another advantage of maintaining the majority of the timeout logic on the server is that if a client is browsing with javascript turned off -- your session timeout logic still works perfectly.
Related
Okay, let's say I have a login page where when the user logs in he or she gets a JWT token from the server which is then saved in local storage (I know cookies is better but I want to do it with local storage). After that, imagine I quit my browser (token is still in local storage and in this example has no expiration date). Now what I want is the following: After quitting the browser (but I got successfully logged in and have token in local storage) how do I make it so that upon initial request to the same server I don't get the login page up again but instead have the user already signed in? Taje into an account that I am able to authenticate the user after the first request and I am aware how but How do I send the token in the initial request?
There may not be a direct solution to your requirement.
But, One hack can be added by adding Script in Head tag.
And withing this script you check if localStorage.getItem('key') is present or not.
If value is present send the request to Home Page directly along with Token or else Login Page.
But, this script download is extra server round-trip.
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 have an angular.js single page app that authenticates against a RESTful API (Servicestack). This all works fine. When the response from the authentication api is returned the username is stored on an Angular service and an isAuthenticated flag is set to true.
Any requests against an [Authenticate] attributed web service then returns data.
My issue is that when I refresh the browser my javascript angular objects are flushed and the fact the user authenticated is forgotten. Yet when I call the [Authenticate] attributed service they work correctly because the session is still live...
Apologies for the rather noob question but how does the browser pass the session to the web service when the javascript objects have been destroyed and recreated? How do I grab the same session on refresh and set my Angular service up with the username etc.?
ServiceStack Authentication uses cookies to store the session token by default. Which means your Angular application will receive the cookie when you first sign in. It will pass this for subsequent requests, and they will succeed while the session is still valid on the server.
The problem will be that Angular will lose the object state, when you refresh the page, that is telling it you have an active session. So you must restore this knowledge to Angular. There are two ways to tackle this:
Check for the ss-id cookie when you application starts and assume you have a valid session. In other words, so restore to a signed in state, until you get a 401 error from the server. This is the quickest approach, and doesn't require additional overhead to check the session if somebody refreshes the page.
Check for the ss-id cookie and make a test authenticated request to check the session is still valid.
If you need to restore other information such as the current logged in user's name etc, then you would need to store that in a cookie/local storage to restore it on refresh, or go with method 2, and retrieve it back from the server.
You can use $cookies provider to manage the session cookie.
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 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.