I have a very peculiar problem at the moment.
We have a MVC system with 10 users working simultaniously. Everything is working fine to a point, and then for no apparent reason, the system change one user's session id (the Chrome Browser session id) to another users' session id.
As a result the system then starts behaving very badly (which I think is obvious).
What could possibly cause this to happen ?
Any help would be much appreciated.
Regards
Related
[Disclaimer: I'm not sure if this kind of question is accepted here as it is about a piece of software deployed already. Rest assured I didn't drop any confidential information. Also do tell me if I violated any rules in SO by posting this so I can take it down immediately]
I have a working Learning Management System web application and I recently received a bug report about a button not showing. After investigating, I have proved that the user was not using the web app as intended. When taking an exam, he was opening multiple tabs to exploit the feature that informs him whether the answer was correct or not. He then will use this information to eliminate the wrong answers and submit all the right answers in another tab/window.
I'm using Rails 4.2. Is there a way to prevent multi-tab browsing? I'm thinking like if a user is signed in and he attempted to open a new tab of the webapp, he should see something like "Please use one tab" and all the features/hyperlinks/buttons are disabled.
Here's a screenshot of how I proved he was using multiple tabs. Notice that there are multiple logs of the same attempt # because the current implementation allows saving a study session and resuming later (this is the part that's exploited). The opening of multiple tabs searches for the most recent attempt session and continues from there. This is also the reason why most of the sessions don't have a duration value -- the user only finishes a study session for one tab (by clicking a button that ends the study session). The system cannot compute for the duration because the other sessions don't have an end timestamp.
-
This is what a single-tab user looks like:
This is more of an application misuse issue more than a bug.
You should add protection not only from multi tab, but for multi browsers aw well, so it can't be purely FrontEnd check.
One of the solutions could be using ActionCable to check if a user has an active connection already and then act accordingly.
Another, for example, generate a GUID in JS and pass it with every answer. If its different from previous answer, it means user opened a new window.
But of course the solution would depend on your current architecture, without knowing how do you currently organise client-server communication it's hard to give exact and optimal solution.
I found an answer here. I just placed this js in the application view to prevent any extra instance of the website.
Thanks for everyone who pitched in.
I restarted my production webserver tonight because it was seeming slow. Since it has come back up, no users are able to get to any views with the [Authorize] attribute on them.
There has been absolutely no code changes since November. Not a single tweak or modification of any kind. I'm using the SqlMembership provider and I originally thought the issue was there with the login, but I can see that the call to MembershipProvider.ValidateUser() passes successfully (looked at a SQL trace as well as some logging). After login, I redirect the user to a view decorated with [Authorize] and get denied.
One thing to note that even makes this more strange is that if I register a new user (who gets logged in as part of the user creation process), they are able to get to [Authorize] pages just fine. But if they log out, they are unable to access the [Authorize] pages once they log back in.
I'm pulling my hair out on this one. My production site is down and literally the only thing I did was a simple server restart. I've searched around for hours and at this point have no clue what to even look into next.
If anybody has a some ideas I'd greatly appreciate them - I'm at a complete loss and have a ton of users impacted.
Well, a few windows updates later the issue fixed itself. My guess is there was an update applied but pending reboot that hosed everything up when I restarted. Then when it came back the system found a bunch more windows updates to apply. I ran through these and it fixed the problem upon the next reboot after these were applied.
I've got an application where a customer can only have one session at any one time. I've got it sorted so this is the case except in one scenario where when a tab or a browser is closed the session cookie is not destroyed. This then lets them log in elsewhere, and then reopen the browser and lets them have multiple sessions running.
If I properly close the browser down then the cookie is removed, but is is possible to remove them without a full closedown of the browser?
The application is already live on a customers site, so I'm hopefully looking for a way to just destroy the cookie rather than re-writing how the whole session storage currently works, though any suggestion is welcome.
I know this post is really old, but someone could find this useful, here there is a gem that lets manage a new level of sessions per tab -> https://github.com/santiagodoldan/micro_sessions, I forked from another repo and added support for rails 4.x
I have a requirement to inform every user to save their work and logout so that admin can reset iis or do some changes in the asp.net MVC application server.
looping through session object collection is not thread safe that is what i have learned.
any other ideas?
and even if i can get hold of active sessions how do i send a message to those clients ?
thanks in advance.
Save the message in a database and query the database for every request to see if a message exist.
This seems like a poorly-defined requirement.
Serious maintenance should be done at a specific time, and users should be alerted to that time window well in advance.
Simply restarting IIS is a pretty quick procedure... is there any reason users would lose their work when simply restarting IIS? While I've been filling out this StackOverflow answer, for instance, they could have restarted the server a dozen times. Once I hit Post, if the server is down, it'll either timeout and leave my work in the textarea, or else it will connect successfully if the server is back in time.
If I'm not submitting data, but just clicking a link, the same applies: either the browser times out, in which case a simple refresh is enough once the server is back up, or it eventually takes the user where they want to go.
If you're doing pure AJAX requests you will need to handle a missing server yourself, rather than relying on the browser to do it, but you'd need to work that out anyway because of the Eight Fallacies of Distributed Computing #1: "The network is reliable." (see http://en.wikipedia.org/wiki/Fallacies_of_Distributed_Computing)
So, I'd actually push back on that requirement. They're asking you to do something that won't really meet the need (users don't lose data, have a reasonably good experience), that will become complicated, and that will be a brittle solution in the end.
Sounds like a case for SignalR!
https://github.com/SignalR/SignalR
Occasionally when we go from the "Export Grades to SIS" link in D2L back to our SIS, using the REST API in our SIS to get the grades from D2L, somewhere in the going back and forth between systems, the browser gets lost and simply goes blank. I think the problem is happening in the final hand-off from D2L to our SIS--that seems to be the point where the browser loses track of where it is. When this happens, our SIS continues to act as if it thinks everything is still working correctly--it does pull grades through the REST API, and does everything it is supposed to do. But the browser session has gone blank, and never shows anything from either D2L or our SIS after that, so the user will not know what is going on.
This happens roughly one out of every 6-8 times we test the link between D2L and our SIS. I don't see a definite pattern, at least not yet.
Any ideas what we are doing wrong? What sorts of things should we be looking at to try to determine where the browser is getting lost?
If it is an operational issue with a server it is probably best to open a support ticket with Desire2Learn.