some users of my site contact me and said that they have a problem to see their information. the problem is that they see information of other users !
i developed my site by asp.net mvc 3 and asp.net membership. when i logon by that username and password everything is ok. i think something happened like ISP cash or network cash for them ! because other users hasn't any problem. i check my code and no problem find !
ISP cache or network cache can not cause this problem. you should search for this problem in your code. also authentication method is not in charge of this problem.
the problem maybe because of session or cookie expire. when a session expires, your app may look for a default data (for example form other user roles) and present it. so should look for such security holes in your application.
another problem maybe because of caching problem in your code or asp.net cache ! caching users data and show it to other users!
I once had something like this happen on an ASP.NET page. Turned out the problem was that I had caching enabled on one of the pages and so the user could see the information on a previous user.
The most likely scenario is that you are caching results server-side and not varying the cached information by the user. Either you need to vary the caching by the parameter that is related to the user or by the user themselves (using VaryByCustom).
Example:
[AuthorizeByUser( Roles = "Admin" )]
[OutputCache( Location = OutputCacheLocation.Server, VaryByParam="*", Duration = 500 )]
public ActionResult Profile( int id )
{
...
}
Varying by all parameters here means that each value of the id parameter will have a different cache entry. Here we assume that id is related (perhaps is) the user's id so each user will have a different cached entry. Note your security (the AuthorizeByUserAttribute) would also need to be set up so that it won't serve up cached results to unauthorized users. Here I'm assuming an implementation derived from AuthorizeAttribute which verifies that the user is in the "Admin" role or has a user id related to the id in the method signature. See my blog post on custom authorization for ideas on how to do this: http://farm-fresh-code.blogspot.com/2011/03/revisiting-custom-authorization-in.html.
I had this exact problem when we brought in the source code from another digital agency. We took their codebase and added more features to it. Testing went fine on both dev and staging and we went ahead to publish it.
As soon as the site went live, we had a lot of users complaining that they were seeing other users’ information as soon as they logged in. We couldn’t replicate it because it happened intermittently.
We thought it could be static method. Replaced all of them by instantiating an object and call that method, the problem was still there.
We thought it was Singleton pattern. We removed them but the problem was still there.
It took us weeks to figure out the culprit. The issue was the load balancing feature set up by the previous digital agency. It was working fine on their two load balancing servers. The problem started as we were hosting on one server. As soon as we turned it off, the problem went away. However, the damage was done. We lost a lot of customers as they didn’t trust our system anymore.
It happened eight years ago but I still have nightmares about that issue from time to time.
Related
Problem description
I have an ASP.NET app in which the users have different rights, and are logged in through Facebook. The app includes (among other things) filling out some forms. Some users have access to forms others don't. The forms can sometimes require some searching in books and/or on the internet before being able to submit them.
As such, we're having problems with session time-outs (it seemed), where users would be met with "Not authorized to see this page/form" after doing research somewhere else.
Attempted solutions
I've created a log function that logs the state of a handful of variables on strategic points in the application. I've pinpointed the problem to the fact that the Session variable "UserRole" is null when the problem occurs.
Relogging
The obvious solution is: "Have you tried relogging?" - which should reset the session and allow the user back to the form they want. On logout, I use
Session.Clear();
Session.RemoveAll();
and I create a new session with relevant variables (including UserRole) on login. This doesn't help, though.
Keeping session alive
One way to do it is just increase the standard 20-minute Session length to an arbitrary, higher number (say 2 hours). Although that could be viable during beta (there are only around 5 users right now), it is not a viable solution in the long haul as the server would have to keep the Session objects from many users for longer time, exponentially increasing server demands.
Instead, I created a 'dummy' .ashx handler "RefreshSession.ashx", that can recieve a POST request and return "200" statuscode. I then created a jQuery function in the shared part of the app (that all the pages use) that calls this handler every 10 minutes in order to refresh the session as long as the tab is open in the browser. I've checked the network traffic, and it works as intended, calling the handler even if the window is minimized or the user is viewing another tab. This did not solve the problem either.
A caveat
When one of the users encounter the problem, they call me or my programming partner up. Of course, we go and see if we get the same issue. We all have the same (admin) rights. The 'funny' thing is that we see the exact same error on the same subpage - even if we haven't had any contact with the application for days.
The problem will 'fix itself' (i.e. let users with proper role back on the subpage) after a while, but not even republishing the app to the server will reset it manually.
Therefore, it seems to not be a simpel session error as supposed from the "UserRole" session variable being null after 15-20 minutes of inactivity. It seems to be saved somewhere internally in the server state.
My problem is, that I now have no idea where to look and how to progress. I was hoping that someone here might have an idea for a solution, or at least be able to point me in the right direction? :-)
Thank you all for your time, it is much appreciated.
Based on MaCron's comment to the question, we decided to keep the information in the user's cookies instead of the session variables. Everything seemed to point to us having exactly that issue, and deadlines being deadlines and with me not being able to figure out how to disable the synchronization of worker processes, this seemed to be a feasible and comparatively easy fix.
I am using Symfony ( current version 2.6.4 ) whenever I want to check if a user is loggedin ( I am also using FOSUserBundle ) I use $user = $this->getUser(); in my controller which works out just fine but if I open 10 links in 1 second this query is repeated for all 10 pages in that second, not so ideal in my option. So my question is, is there a way to cache this query for say 60 seconds and is it even advisable, will it affect new registrations or something. I am using APC as my doctrine cache but if someone knows the answer please also tell us how to use other ways incase other people also wonder how to do this. Thanks.
To start with, sql databases do a good job of automatically caching queries. So while there is some overhead in composing and sending the query to the server, the server itself will respond very quickly. You won't save much be adding another cache.
Should you still try and optimize? In your example of 10 requests per second one assumes that the requests are actually doing something besides getting the user. It's up to you to decide if caching the query will actually speed things up. In most cases the answer will be no. Trying to save every possible microsecond is called premature optimization and is something to avoid.
Having said that, it's worthwhile to look at what the security system is doing. Selected user information is stored in the session. You can use the debug profile bar to look at it. For each request, the security system pulls the user out of the session and then calls $user = $userProvider->refreshUser($user); By default, refreshUser is what causes the database to be queried.
You can easily plug in your own user provider (http://symfony.com/doc/current/cookbook/security/custom_provider.html) which just returns $user. No database interaction at all. Of course if the user's database information does change then they will need to log out and then log back in to see the changes. Or do something else to trigger a real refresh. But for many apps, not refreshing at all will work just fine.
It would also be easy enough to put a time stamp into the session. Your refreshUser method could then use the time stamp to decide if a refresh was actually needed.
So it's easy enough to eliminate the query and actually worthwhile just as a learning experience. Security is one of the more complicated components. The more you understand it the better off you will be. Customizing a user provider is one of the easier things to do.
I just saw your comment about the OAuthBundle. I have not used the bundle in awhile. Implemented my own but I'm surprised that it's hitting the oauth server on each request. If it is then this would in fact be a good use case for overriding the user provider. But I'd be surprised if it was really doing that just for user information.
As far as I know it is not possible to invalidate or drop a specific (or multiple, say, based on a user name) Domino HTTP Session(s) (darn IMAP). Is there / what would be a proper workaround / mechanism to somehow drop / invalidate Domino HTTP Session(s)?
Some example cases could be:
Same user, two sessions, in one of those the user changes the HTTP Password (at this point all other sessions should be immediately invalidated). If he/she continues working / browsing in the other (browser)session (at some point) you get the "authentication failure using internet password" message on your console, and if you're in a bad luck the user gets locked out.
Facebook-style; have an overview of your current active sessions. One step further, if they see a suspicious session based on IP/Location, giving them control of invalidating it.
A client calls; "I got the feeling my session is hijacked".. First response; "you are a smart user, aren't ya?". Subsequently you want to drop those sessions with that user name (via console or "admin" web interface).
...
You would have to take control of the authentication process, which could be done using the DSAPI interface that is described in the Notes C API documentation. I've only done some pretty minimal DSAPI work myself, but I understand from others who have worked with it extensively that advanced work with DSAPI is definitely not for the faint-hearted. You might want to look into some 3rd party products (e.g. from PistolStar) that may provide at least some of the functionality you are looking for.
Well, I finally had to create an account here. Been using this for years and have often found my answer here, but not this time.
Well, I actually have found a lot of people with similar problems, but none of their solutions have helped me.
I have started on a new MVC3 project, so it's quite simple so far. I've made a handful before, so I kinda know what I'm doing (but not quite, obviously, why else be here ;-)
My problem is apparently a fairly common one: A request starts a new Session, even though the user already has one.
The most frustrating part of this is, it works perfectly on my hosted service, but is broken on localhost.
I have done a number of things to solve this:
There is no underscore in my computer's name.
The Session contains custom data (the error only occurs after user has logged in).
I have added the following to web.config (hmpf, guess you'll have to assume the gt / lt chars):
httpProtocol
customHeaders
clear /
add name="Access-Control-Allow-Origin" value="*" /
/customHeaders
/httpProtocol
and this too:
modules runAllManagedModulesForAllRequests="false"/
With InProc sessionstate, I have tried with 'cookieless' both true and false.
My hosts file contains nothing about localhost.
hm. Looking at this list I'm sure I've left some out. Some on purpose too, as they were hopeless (yes, even more than the above), and born from desperation.
As mentioned this is particularly unnerving as it works on my host - could there be some configuration settings I need to tweak on the dev server (VS2010)?
I've been working from the premise that the issue is due to cross-domain security (it thinks I'm coming from another domain).
The fail happens on this request:
url: 'http://localhost:50396/moody/changeBuilding/' + elem.selectedIndex,
It's part of the options array I use with the jQuery.ajax function.
I change the domain when uploading to the host, but only the part localhost:port, everything else in the application is identical.
I've been banging my head against this for 2 days now, and will miss my exam :-(
I'm determined to bury this 6 feet under, though.
I would be very grateful for any and all suggestions!
I change the domain when uploading to the host, but only the part localhost:port, everything else in the application is identical.
Reading the above, I image the session cookie isn't being sent because you're changing domains.
Let's sit back and think about how sessions work. Basically ASP.NET contains a collection of sessions and their data. When each request comes in, ASP.NET must map that request to an existing session OR create a new session for them.
So how does ASP.NET know what session belonged to each incoming request? Or know that it needs to create a new request? The only way to know this is if the request contained some information, a 'key', which told ASP.NET what session to give the request... or in the absence of this 'key', create a new session.
How does the request send this 'key'? Through cookies.
So therefore, if you change the domain, the cookies isn't going to be sent... so therefore, ASP.NET will create a new session for the request.
Have you tried using something like fiddler to make sure that the session cookie is being sent in the AJAX request. It should be sent if the domain is the same but it's work checking.
Edit: This SO post on changing ports is worth reading too.
Edit: Given the new information in Charlino's comments (and the sterling detective work carried out therein) if the problem is only on your local dev machine then the easiest way to work around your localhost/127.0.0.1 issue is by manually changing the browser url from 127.0.0.1:50396 to localhost:50396, logging in again to get the new cookie, then you are good to go.
As late, I've started noticing that my web application randomly logs out a user after a random amount of requests between pages. I've gone through all possible scenarios and have noticed that it only happens when the UserIsOnlineTimeWindow property (of the Membership provider) doesn't equal the default FormsAuthentication Timeout property.
Does the UserIsOnlineTimeWindow affect the default FormAuthentication provider?
Do they need to be the same?
If so, please explain ...
The following is pretty self-explanatory, though it doesn't describe any relation between the default Membership API and FormsAuthentication (with regards to the aforementioned properties affecting one another):
Specifies the number of minutes after the last-activity date/time stamp for a user during which the user is considered online.
http://msdn.microsoft.com/en-us/library/system.web.security.membership.userisonlinetimewindow
that does seem strange. UserIsOnLine Time does not update anything I know of. I'd suggest looking at the cookie in a browser like chrome with the dev tools and actually check what the expire time on the cookie is. Best I know, that is the only thing that will cause a logout (besides deleting the cookie)