My app has a session timeout after 30 minutes. If the user has a "permanent login" feature activated, then on a subsequent HTTP request the server reads the "perm session" cookie and restores the session.
However, if the user does not reload or navigate to another page after his session expired, but rather clicks on a button that retrieves data via AJAX, the session is not resumed; in the DIV where the data was supposed to be loaded into, a login window appears instead.
This leads me to an assumption that AJAX calls do not carry cookie information with them. Am I correct, or have I missed something else?
Update:
backend: symfony 1.2 (PHP framework),
frontend: Prototype
Update2: it was a bug in the application, not an issue with cookies
Sounds like you are restoring the session, but not providing a new auth cookie. You might want to try a technique that I've written about on my blog of having a client-side timer that will prompt the user right before the session times out and, when they click OK to renew it, will make a request that will serve to keep the session and authentication cookie alive. You can find more info at http://farm-fresh-code.blogspt.com. The article is titled Client-side Session Termination.
An XMLHttpRequest call should carry cookie information like normal. You may be running into a bug. Are you ensuring the call is from the same domain origin?
Perhaps your cookies are also expiring? More info might help .. :)
Related
I have built my app, I used plain JS on NodeJS and it is a single-page app. I didn't use express.
First the user needs to log in. The login-data is sent via websocket to the server and there the credentials are checked against a MySql-DB. If they are correct, the loggedIn-content is generated and sent back to the client, where it is displayed.
Now when a user is already logged in, and then refreshes the browser, he lands on the initial state of the app, and needs to log in again.
how can I fix this?
I read a lot about session-handling in NodeJS, but most articles include express, which confuses me to understand this whole concept.
HTTP itself is stateless, so you need some sort of way to identify the user.
Traditionally, this is done via cookies. When you respond to an HTTP request, you include a cookie in your response headers. For all subsequent HTTP requests, the client will include this cookie information back to you.
This means that you can send some sort of session identifier, and for all future requests you can look up the session data. The conversation goes a bit like this.
Client: Here's my login information, and I'd like the home page.
Server: Ok, thanks. Here's the home page. Also, remember that your session ID is 12345. Next time you ask me for something, tell me that session ID. (Logs in the database that session ID 12345 is associated with someuser.)
Then later...
Client: I'd like this other page. You told me to tell you that my session ID is 12345.
Server: (Loads session information for 12345, sees that it's associated with someuser.) Ok, here's that other page.
How you actually do the storage of all that is up to you. Many folks use databases, since they're often already using them for the application and it makes it easy to share session data with multiple instances of the application server.
I am working on an app that must use session timeouts.
The problem is that users regularly miss the session timeout and lose data. I already implemented a small session keeper in javascript that will renew the session every one minute if there has been some activity in the browser, but users are still somehow losing data (assumably they are half filling out a form, walking away from their machines and coming back after the session has expired and submitting the form.)
I would like to find some way to warn them that their session has expired. The problem is that I can't figure out exactly how to do it. I can't check the expiration of the session cookie in javascript, because it's an HttpOnly cookie, and if I do some kind of AJAX request to check the status of the session, it will automatically set a new expiration for the session.
Can anyone see a way around these obstacles?
This isn't a direct answer about checking session time-outs... but I've found garlic.js to help when I'm worried about users losing their work in forms. Basically, it's a JS library that takes care of saving form data in the user's browser's local storage until the form is submitted. So that, in case the browser closes or the session expires, the data is not lost. So this may be a good backup solution for the from data getting lost part.
UPDATE:
What I typically do to avoid form submission after session timeout is to set a javascript timer that will auto redirect the user to a session expired page (with an easy log in again button) a few seconds after the typical session timeout length. (You could reset this timer with your AJAX polling when there is activity within the page.) This combined with garlic.js, combined with "deep dive" functionality (whereby you store authenticated URLs in the session when they're accessed so that after a timeout and log back in you return the user to the last page they were on) creates a pretty seamless timeout, log-in, resume where you left off scenario.
I am creating a Forms Authentication in MVC using
`FormsAuthentication.SetAuthCookie(userName, model.RememberMe);`
And in Controller we use [Authorized] attribute to make sure user session is valid and has not expired. It works well when user move from one page to another. And if Cookie is expired then Login page is shown again.
Problem is with the one Page (Dashboard) which makes Ajax calls to server (Controller) to refresh some items on the screen every minutes.
As per company policy we can’t have session more than 30 minutes. So if this page remain open for 30 minutes and session expire we would like to redirect to Login page.
Currently if session expires this page still remain as it is but stop getting refreshed and then user complains they can’t view data. Of course they can see it again once they refresh the page but is there any way using which I can find using JQuery or Java Script that FormsAuthentication cookie has expired
Of course they can see it again once they refresh the page but is
there any way using which I can find using JQuery or Java Script that
FormsAuthentication cookie has expired
Yes you can. Phil Haack wrote a very nice blog post explaining how you could prevent the Forms Authentication module from simply redirecting to the login page but instead return a 401 status code which your client AJAX call might catch and use window.location.href to manually redirect to the login page.
http://haacked.com/archive/2011/10/04/prevent-forms-authentication-login-page-redirect-when-you-donrsquot-want.aspx/
He also wrote a NuGet called AspNetHaack which you could use and if you are interested browse the source code here: https://github.com/Haacked/CodeHaacks/tree/master/src/AspNetHaack
I am creating a chrome extension, rather a chrome webapp. This application just contains the html, js, image and css files. The application connects to a server to fetch data. I chose to do this as it would reduce the amount of files downloaded by the user. Using Backbone.js I have an MVC architecture in my application. Thus the application just sends json.
Now having said this, I need a session management. I plan to use Google authentication as the organization has Google Apps. I need a method that once the user has logged in using google auth the server get the user name every time the application makes a request.
Is it a good idea to add the user name in request header, if possible. Or should I use cookies? Can any one tell me how I could go about using cookies in this case?
This might be a late response but I want to present a more elegant solution to you given that the user has cookies enabled in their browser.
First read my answer on another question.
Now that you can send cross origin xhr from your content scripts all you need to do is store all your authentication and session management at server only. That is right, you just need to display whether the user is logged in or not and a logout button at client based on server response.
Just follow these steps.
At client Whenever user accesses your chrome web app, blindly make XmlHttpRequests to your server without worrying about authentication, just keep a tab on response from server which I describe below.
At server whenever you receive a request check for valid sessions or session cookie. If session is valid send proper response, if not send error, 401 or any other response to communicate to your client that session is not valid. It is better if you send an error code like 401 since then you can put a generic script at client to inform them that they are not logged in.
At Client If response from server is proper, display it, else display login link to your website.
IMPORTANT: Display logout button if user is logged in.
Check out my implementation of this in my extension
For help using Google authentication in your app take a look at Google's OAuth tutorial which comes with all you need (took me no time to set it up using this).
As for session management. The implementation of OAuth used by Google stores the tokens in localStorage. Also, as briefly mentioned in the extensions overview we are expected to use localStorage to store data. Thus, I suggest you store the users name here as it will be accessible throughout the app's lifetime (until it is uninstalled). However, you may need to manage the name stored here and consider what should happen when users log in and out. That said; I'm not sure if sessionStorage would be a better option as I've never used it before, let alone in an extension.
Note
localStorage and its counterparts only store strings so I suggest using a wrapper which uses JSON to parse and stringify to get and set your values respectively.
Just want to get input from people who know. I was considering CSRF vulnerabilities, and the seemingly the most popular method I know to fight against it. That method is to create a token in the returned html and adding a cookie with the same value. So if a script tries to do a post they would have to guess the token thats embedded in the web page for it to be successful.
But if they're targeting a specific website why can't they just use a script that
Calls a get on the page (the cookie will be returned even though the script can't access it)
Parses the html and gets the token
Calls a post with that token in it (the cookie that came back will be sent back)
They've successfully submitted a form without the users knowledge
The script doesn't need to know the contents of the cookie, it's just using the fact that cookies get sent back and forth all the time.
What am I missing here? Is this not possible? I think this is pretty scary if you think about it.
Below this line is not required reading to answer the question :)
This vulnerability banks on the fact that authentication is done based on cookies, which I think is the main way authentication is currently occurring.
Another solution I can think of is making authentication be on the page level. So
when they log in the returned html will have that token in it. every link that they click contains that token so when the web server gets a request it has a way to identify the user/session. The problem with it is that if they use any navigation other than that they will be 'unauthenticated'(e.g. type in a url) , also it doesn't look nice in the url because it would probably look something like this:
https://www.example.com/SuperSecretPage/1/123j4123jh12pf12g3g4j2h3g4b2k3jh4h5g55j3h3
But I do understand that if safety is more important, then a pretty URL is second place.
I don't know everything about cookies but what if user agents were a little more careful with their cookies?
For example, what if the cookies sent depended on the tab? We all surf using tabs by now, right? so what if the scope of the cookie was the tab? so if i have my banking site open on tab 1 and i'm surfing on tab 2, any scripts calling gets/posts on
tab 2 will only send the cookies accrued in tab 2.
Or what if cookies were stored / domain. So while I'm on example.com any cookies that come back go into the example.com cookie collection. and then when i'm on www.mybankingsite.com all the cookies get put into the mybankingsite.com collection. So if I go to example.com and it runs a script that calls a get/post the user agent will only send example.com cookies. This is different than sending the cookies of the requested domain. E.g. if a script calls a get of mybankingsite.com within a web page of example.com the user agent will not send the mybankingsite.com cookies.
I know i have no control over what user agents do, but I'm just exploring possibilities
So I think the problem here becomes the attacker's attempt to get the page's contents. To get the authenticated user's page, the attacker needs to be able to send a request on their behalf and read the contents. AJAX won't send cross-domain requests, iframes won't let you read the response. I am struggling to think of other ways in which an attacker would get the contents first.
A more likely hack is using clickjacking to have the user just submit the form. This technique doesn't seem too likely. (caveat: it's security, we can always be wrong.)
Does anyone care to share some code on this issue as I just hacked my own site (Not in production) with CSRF. All I had to do was the following
At: www.badguy.com/ write the following html
img src="www.goodguy.com/secure/user/delete/5">
What this does
So the admin goes to to www.badguy.com/ and the the image makes a request to
www.goodguy.com/secure/user/delete/5 from the users browser so the admin unknowingly just deleted a user. If you create a loop your in some trouble. Expect I never delete data just change its status :) but still I don't like the looks of this.
The CSRF token has to be unique per session. If a malicious server requests the same page, they will get a different token. If they try to request the contents of the page via JavaScript on the client's machine, the same-origin policy will prevent them.