This isn't easy to explain, but I'll try my best.
The issue has started happening in a site that was built some years ago using classic asp, the symptom is that the administrators log-in using a form and then an session variable is set, but suddendly when they request a new page they are prompted again to log-in.
This problem isn't specific to any browser, I've reproduced the problem with Firefox and IE8.
Using Fiddler I can see that suddenly the server sends a new Set-Cookie header, despite a previous session cookie being sent in the request.
From that moment, the server will switch between the two sessions randomly, none of the sessions seem expired, they preserve their own variables, but for the user it's useless because he might be asked to login and then the form data is processed in the already logged-in session.
What can I try to find out the problem?
The server is a shared hosting with IIS6, the hosting company isn't too friendly but the cost of moving everything to other place makes things stay as is.
Thanks.
Some further info:
Showing the machine name as suggested by Aaron D. always shows the same name, but I had stored the start time of the application in global.asa:
Sub Application_OnStart()
Application("Start") = now()
End Sub
And it turns out that when showing that info in a test page it does change as the detected session changes. So there are two servers (with the same name) or somehow it's running twice the application.
Is it possible?
I have a couple ideas but nothing definitive.
Are some requests over HTTPS and others over HTTP? Are the cookies set to only transfer over secure connections?
Are your requests alternating between a subdomain and the primary domain? Example, some requests go to www.foo.com and others to foo.com? The cookies may not be shared between the two unless you set the domain inside the cookie. This could also happen with multiple subdomains.
This one is a less common, but is the company hosting your site on multiple servers that are distributing the load? You could tell this by creating a page as specified here:
http://mentaljetsam.wordpress.com/2008/01/29/classic-asp-code-to-print-current-server-name/
If this turns out to be the case, the solution with be to change your session state model from "InProc" to use a shared resource such as a database.
Are you sure that it switches you between sessions and doesn't just expire your session away? It could be that your app is restarting (based on your edit) and this is killing your sessions, but the cached result makes it look like it's still valid. Can you try doing hard refreshes and/or check the results with an HTTP traffic watcher like Fiddler? That might give you a better clue about what requests are actually going across the wire.
Related
Working on a project in codeigniter.
I've got clients sending requests from an app (I have no control over) to a router app (I have no control over). The router gives me a unique identifier for each person talking to my app (in a post variable). How would you suggest tracking sessions for users without using a cookies between requests. I would use the CI sessions to track but it tracks off of IP address, and most of the requests from the router app to mine will have the same IP address.
You can try storing session to database or use apache/IIS log. Many free web apps are available to read these logs. I've used awstats for reading IIS log for getting traffic info.
You could go the old-fashioned route and put the tracking data into the URL. Append the unique ID from the routing app to every link on the page in the form of a GET parameter. Read that in on subsequent pages and regurgitate it on all subsequent URLs.
Certainly not sexy, but in the world of dealing with applications you can't control (aka the "real" world) it might not be the worth option.
I'm building a basic login script from a book that uses sessions to manage wether a user is logged in or not.
This is great, but when I close my browser, and then reopen it, I have to log back in.
Whereas, with Facebook for example, I remained logged in, even if I have closed my browser. I'm guessing this is done using cookies. Is it safe to use cookies? How long should this cookie last? Sometimes websites explicitly say, "please remember to log out at the end of your visit". Why would this be necessary?
Currently my script is kinda like this:
session_start();
if (is_set($_POST["login_button_pressed"])){
if (form_verified_successfully()){
$user_details = get_user_details_from_database();
$_SESSION['username'] = $user_details['username'];
}
}
Would it be easy to modify the above to work with cookies? And if so, how?
Thanks
A cookie is a small text file that is saved to a temporary directory on the user's harddrive. This cookie can be accessed by the browser that placed it there. It can hold data such as previously visited URLs (posts the user read vs hasn't read), the user's credentials or even the contents of the users cart or a post they didn't finish writing in a forum. You will choose how long the cookie is valid for that system, most common that I have seen are 24 hours, 7 days, 14 days and 30 days.
A session is attached to the actual piece of software interacting with the web server, ie, a browser, command prompt or other application. Once the browser is closed or the application is shutdown the session data will be lost.
Reasons you might want to have the user login again, the data you have granted access to is very private information that another user who grabs the computer 15 minutes later shouldn't have access to (banking, account settings) or the data you have given to the user is time sensitive and you want to force the user to sign in again and be given fresh data when they come back.
Most social networking sites like Facebook, LinkedIn, Google+, Twitter and several other forums and blogs will give you a cookie to let you stay logged in for up to a month or longer so you can easily come back and look through the site and post to your profile. However, if you go to change your account settings they will prompt you to login again and will only give you access to those pieces of the site during your current session. This is for security reasons.
I hope this helps out. For a quick reference, run a Google search on sessions vs cookies. You should be able to find a relevant article to whatever language/platform you are using. There are great articles out there for PHP, Java, .net and others that discuss advantages, disadvantages and best practices.
Changing to a cookie:
As for your last question, it shouldn't be very hard to change to using a cookie. Most likely it will be referenced via _COOKIE instead of _SESSION, but you will have to tell the cookie what information to hold and how long to stay active. A quick Google search for setting cookie [language] should provide plenty of tutorials. Replace [language] with either PHP, Java, Spring, .net, etc.
I was wondering if it ever would make sense to have two concurrent sessions in the same browser? There could be two types of cases with this:
1) A user opens a browser window and logs in as user A, starting session 1. Then he opens another browser window (in the same browser) where he logs in as user A, but starts a different session, session 2.
I know that this is often not possible in many browsers, as one session cookie is set for the entire browser. However, in some browsers, it is possible to have multiple sessions in that manner.
2) This is similar to 1, except that the second time the user logs in, he logs in as user B, starting session 2. So now you have a person logged in as two users in the same browser.
Finally, allowing these things doesn't seem like the best security practice and neither does it seem to be practical. What do others think?
First thing First as the your Assumption is wrong. First of all you have to understand that when Single website is accessed from browser have single session and its not possible to simultaneously run different session of same web Browser.
It seems you have wrongly understand the working of Private Browser. Private Session are not made not to share information cookies and data with other public session and vise versa also. As soon as you close the Private Session all the Cache, Cookie and other things are deleted for forever.
I have not seen any web browser supporting the Multiple session of browser.
But an alternative approach is available i.e you have to create different Web Browser Profiles which can help you as each Profile data is maintained separately and have no conflict with other sessions.
One possible scenario currently I am facing requires allowing multiple user sessions from the same browser and I have not been able to find a proper solution for it yet.
We are using Yii framework. Currently we have two kinds of users i.e customers and admins. Both login from the same login form and use same session name and variables to store session information. Only based on type column in user table(customer or admin), the user is taken to appropriate views. In one of admin views(pages), there is an option for admin to log in as any of the users and propagate through the user's view in an iframe. The problem is that when the admin open two tabs and logs in as two different users, the session information of one overwrites the other and we start getting session related issues.
Can anyone suggest me a proper way to handle these kind of issues. I have searched a lot on trying to handle this with multiple sessions, but have not been able to find a proper solution yet.
There's nothing to "provide support for" here. One browser cannot hold more than one session, since it only holds one unique cookie per site, regardless of window. If a browser actually has a mode in which it supports holding two separate identical cookies per site, then it's the same as if the user logged on from another browser or another machine. That certainly should work; i.e. you should not try to subvert that behavior. A double session inside the same browser is then just a specific instance of this multi-session behavior, nothing special.
I am using Spring Security 3.0.7 on a project at work. Our application site can be reached via redirection from different sites. We use concurrency filter and a session authentication strategy.
Situation 1:
If you reach the site from a referer in Firefox, and then you reach our site from a different referer in another browser say Chrome, your session in Firefox is destroyed, and you can work normally in Chrome.
Situation 2:
The interesting part is this: my workstation is Ubuntu and when i try to reach from a referer in a tab, then try to reach from another referer on a different tab, older session is discarded again and I have to login and etc. This behaviour is same like the above paragraph.
Situation 3:
I try again from my Ubuntu desktop, and reach the application site from same referrer in different tabs. This time my previous session id is overwritten, and the flow got mixed up because of this.
Situation 4:
On Windows systems by the way, if i access separately from different referrers to the application from different tabs of a same browser, my sessions got mixed up, sessions are just overwritten and the actions done on the application get mixed. Same behaviour as Situation 3.
My intention is to get rid of situation 4, and configure the security system to work as Situation 2. Can I do this with spring security?
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I see iframe/p3p trick is the most popular one around, but I personally don't like it because javascript + hidden fields + frame really make it look like a hack job. I've also come across a master-slave approach using web service to communicate (http://www.15seconds.com/issue/971108.htm) and it seems better because it's transparent to the user and it's robust against different browsers.
Is there any better approaches, and what are the pros and cons of each?
My approach designates one domain as the 'central' domain and any others as 'satellite' domains.
When someone clicks a 'sign in' link (or presents a persistent login cookie), the sign in form ultimately sends its data to a URL that is on the central domain, along with a hidden form element saying which domain it came from (just for convenience, so the user is redirected back afterwards).
This page at the central domain then proceeds to set a session cookie (if the login went well) and redirect back to whatever domain the user logged in from, with a specially generated token in the URL which is unique for that session.
The page at the satellite URL then checks that token to see if it does correspond to a token that was generated for a session, and if so, it redirects to itself without the token, and sets a local cookie. Now that satellite domain has a session cookie as well. This redirect clears the token from the URL, so that it is unlikely that the user or any crawler will record the URL containing that token (although if they did, it shouldn't matter, the token can be a single-use token).
Now, the user has a session cookie at both the central domain and the satellite domain. But what if they visit another satellite? Well, normally, they would appear to the satellite as unauthenticated.
However, throughout my application, whenever a user is in a valid session, all links to pages on the other satellite domains have a ?s or &s appended to them. I reserve this 's' query string to mean "check with the central server because we reckon this user has a session". That is, no token or session id is shown on any HTML page, only the letter 's' which cannot identify someone.
A URL receiving such an 's' query tag will, if there is no valid session yet, do a redirect to the central domain saying "can you tell me who this is?" by putting something in the query string.
When the user arrives at the central server, if they are authenticated there the central server will simply receive their session cookie. It will then send the user back to the satellite with another single use token, which the satellite will treat just as a satellite would after logging in (see above). Ie, the satellite will now set up a session cookie on that domain, and redirect to itself to remove the token from the query string.
My solution works without script, or iframe support. It does require '?s' to be added to any cross-domain URLs where the user may not yet have a cookie at that URL. I did think of a way of getting around this: when the user first logs in, set up a chain of redirects around every single domain, setting a session cookie at each one. The only reason I haven't implemented this is that it would be complicated in that you would need to be able to have a set order that these redirects would happen in and when to stop, and would prevent you from expanding beyond 15 domains or so (too many more and you become dangerously close to the 'redirect limit' of many browsers and proxies).
Follow up note: this was written 11 years ago when the web was very different - for example, XMLhttprequest was not regarded as something you could depend on, much less across domains.
That's a good solution if you have full-control of all the domains backend. In my situation I only have client (javascript/html) control on one, and full-control on another, therefore I need to use the iframe/p3p method, which sucks :(.
Ok I seem to have found a solution, you can create a script tag that loads the src of the domain you want to set/get cookies on... only safari so far seems not to be able to SET cookies, but Ie6 and FF work fine... still if you only want to GET cookies, this is a very good approach.
The example in that article seems suspicious to me because you basically redirect to a url which, in turn, passes variables back to your domain in a querystring.
In the example, that would mean that a malicious user could simply navigate to http://slave.com/return.asp?Return=blah&UID=123" and be logged in on slave.com as user 123.
Am I missing something, or is it well-known that this technique is insecure and shouldn't be used for, well, things like that example suggests (passing user id's around, presumably to make one's identity portable).
#thomasrutter
You could avoid having to manage all outbound links on satellites (via appending "s" to querystring) by making an ajax call to check the 'central' domain for auth status on page load. You could avoid redundant calls (on subsequent page loads) by making only one per session.
It would be arguably better to make the auth check request server-side prior to page load so that (a) you have more efficient access to session, and (b) you will know upon page render whether or not the user is logged in (and display content accordingly).
We use cookie chaining, but it's not a good solution since it breaks when one of the domains doesn't work for the user (due to filtering / firewalls etc.). The newer techniques (including yours) only break when the "master" server that hands out the cookies / manages logins breaks.
Note that your return.asp can be abused to redirect to any site (see this for example).
You also should validate active session information against domains b,c,d,... this way you can only login if the user has already logged in at domain a.
What you do is on the domain receiving the variables you check the referrer address as well so you can confirm the link was from your own domain and not someone simply typing the link into the address bar. This approach works well.