I have an MVC 4 app and am using the default authentication provider. I'm not using persistent cookies.
I don't have any problems in development but when hosted at HostGator, I SOMETIMES get logged off when I try to create a new item (HTTP POST). When this happens, I end up at the log on page like I wasn't authenticated.
HostGator does NOT have the app on multiple web servers so I'm thinking I shouldn't have to worry about machinekey stuff. Am I wrong?
When this happens, I just log in again and create the item again and it will succeed. Once this happens, I can't recreate the issue. I try reopening the browser and even different browsers but creating items will always work. It only seems to happen again if I try much later.
Some additional info, the timeout is set to 2880 (the default for an MVC project), which I know is long but I can't see how it would be related. Still, thought I'd mention it.
So I can't look at IIS logs or event viewer to get any idea what could be happening but I can add more logging to the app. Can anyone provide ideas for what to check or what logging to add to diagnose?
Thanks
EDIT
I realized that I could get to the IIS logs so I compared the POST that succeeded and the one that failed and immediately noticed something.
When I first did the GET to load the Item/Create page/view, the cs-username was populated but when I did the POST to create the item, it was gone. I can see that when I logged in again and was able to successfully create the item, that POST did have the cs-username populated.
Why would it disappear between the GET and the POST? There was a 7 minute delay from the GET to the POST but I can see I logged on 1 minute before the GET so the session was only 8 minutes old when the post happened. I've double checked that I don't have sessionstate explicitly configured so the default should be 20 minutes. I feel like I'm onto something but not sure exactly what.
Might be worth adding Glimpse, although running that on deployed code is kinda risky. It would have the benefit, though, of letting you see what's actually happening on the server. I've never used HostGator, so I can't say for certain, but if they recycle app pools aggressively, that would invalid your login, and explain why the logoff seems to happen randomly.
Related
I support a Rails 4 app used for remote project reporting. One of the team insists that she used the tool on several occasions to report her data, double-checked it to ensure it had been entered properly, then later discovered it was all gone. I found evidence of her authentication (Devise gem) in the production logs, but no trace of her reporting activity--not even the GET requests that would be necessary to begin her work.
Is it even possible for Rails to suppress logging events in this manner, when they are working for every other user?
If it is not possible, does it suggest that the claim is unreliable? (trust me, I'm not pre-assuming this)
Unfortunately, the user is no longer involved in the project and is not responding to requests. Also, the absence of necessary POST events is borne out by a client-facing logging feature as well.
Rails logs all requests the moment a GET hits the server, before authentication happens. It is most improbable that logged requests by a single user can be suppressed, unless the default middleware stack is modified.
I'd go with Occam's Razor.
The scenario is as follows. I start an instance of MVC app to debug it. The app uses simple membership and I log in during this run. Then I go back to VS change something and start the instance again. It doesn't happen really often but sometimes at this moment membership starts acting odd. As the app starts, some action, that is behind [Authorize] attribute (to be exact the attribute is on the controller), is called. However the action fails because WebSecurity.CurrentUserId is equal -1 (the action in question just loads some user information based on WebSecurity.CurrentUserId).
If I clear cookies in browser, everything is fine, but I can't expect users to do the same when they encounter the problem.
My colleague explaind to me that it's (probably) happening because my local IIS decided to restart and some of session cookies became invalid, but if this can happen on local instance of IIS, wouldn't it be possible to also happen on the remote server?
Other important fact, the action that fails is called (more like redirected to) by a custom filter that we wrote. This filter is applied to all actions (but doesn't affect the one mentioned). Can this filter somehow make MVC ignore [Authorize] attribute?
I have a dirty workaround for this problem that should work (with this specific app), but I would prefer to prevent the problem from appearing int the first place.
I think this is related to this. Basically when the server gets reset authentication cookies die. They get recreated right away, except my app doesn't really have access to them till the page is reloaded (just like with logging in).
I partially solved the problem described above (a redirect is preformed somewhere on the way) so the application no longer gets stuck. However, if someone was logged in during the time the server restarted and he tries to preform a post after that, his post will not work and he will be redirected to a get action with the same name as the post action (our custom filter is to blame for that). Unfortunately I cannot fix the filter, because I would need user id for that and at the point at which the filter is called, it's still -1.
I guess my question is not too well written and kind of very localized (I should probably rewrite it or reask it), but the underlaying problem is more general than it seems, so let me salvage all the useful information into this answer.
Question 1: There is nothing preventing IIS from having a hiccup on a remote server and restarting the app, so yes this can (and happens) on the remote server (frequency will depend on the app itself and IIS configuration). The problem of disappearing session data seems to be related to the restarts of the app pool rather than the app itself.
Question 2: The custom filter has little to do with the situation. As pointed by Larry, in simple membership authorization is kind of unrelated to session data. If your session data is lost, the user does not stop being authorized, however user data is stored in the session. Without session you don't know who the user is. This information becomes available one action after session data was lost. So loosing session data can lead to a crash of the application or like in my case (where a custom filter depends on user data) to even weirder results.
So if you encounter unexpected disappearance of user data in your app (such as WebSecurity.CurrentUserId becoming -1), it might be worth investigating if your app pool is getting restarted (and why). Setting memory limits for an app pool seems to increase the likelihood of those restarts.
I have an website build in MVC4 .NET. Now I want to tracking the time user had online in my website. Example: User open browser and then login to my website and active on my website about 30 minutes then close the browser. I want to store 30 minutes to database but I don;t know how to implement it. Please help me because I very need to do it now. Thank you so much
Here is a script that track user login/logout times on a website. It's a simple script that It has used on some of the sites. Also with this script you can see how many users are online at your site.
But the problem is when the user close the browser he do not log out. his session goes to expire
one of the other ways is global action filter that intercepts requests to all actions on all controllers, then you can get the time of each action in the database for the current user and page. To save hitting the database too hard, you could cache these values and invalidate them every few minutes, depending on how much traffic you're dealing with.
UPDATE
about Closing the Browser This is not something that's provided for in the normal web http protocol. There's no real way to know for sure when the browser closes; you can only sort of know. You have to throw together an ugly hack to get any level of certainty and even then it's bound to fail in plenty of edge cases or cause nasty side effects.
The normal work-around is to send ajax requests at intervals from the browser to your server to set up a sort of heartbeat. When the heartbeat stops, the browser closed and so you kill the session. But again: this is a horrible hack. In this case, the main problems are that it's easy to get false positives for a failed heartbeat if the server and client to get out of sync or there's a javascript error, and there's a side effect that your session will never expire on it's own.
I've got a site that's currently in beta and thus password-protected (sorry, can't show yet). Most of my users access the site no problem and able to interact with it, upload files, ..etc. There's one guy, however, who seems to have a persisten issue with access. Whenever he accesses the site, the connection times out and Heroku sends back an app-not-available response. Better yet, that screws access to everyone else at that time and I have to wait for the service to restart. Heroku logs show no sign of any issues. New Relic logs are also fine.
Do you have any suggestions on how I could troubleshoot , what tools I could use to monitor?
I have also had issues like this with heroku from time to time, and they have blamed in on EC2 when I contacted them. However, this has only happened to me twice and hasn't happened in months.
I tweeted #heroku and #salesforce with the problem when I got a snarky remark, and it got me in touch with someone who was actually able to help me. Sometimes they can be quite standoffish :)
I'm having a problem with a MVC (1.0) app that I can't figure out at all. There's two versions of the site (live and UAT) hosted on the same server. For each version of the site, the same code is shared by multiple organisations who each have their own database (MSSQL2005) and a separate web site in IIS (7.5) (pointed to the same code).
The UAT site has an update to the code and the database that is waiting to be deployed to the live site.
One of the customers ("customer A") is getting an error "104: Connection reset by peer" when they try to log in to the UAT site. They can see the login page but when they submit their login details the connection seems to be timing out (the requests seem to take ~130s to complete).
Customer A can log in fine to the live site. The other customers don't have a problem logging into the UAT site or the live site. If I try to log in as customer A, using their login details, it all works fine from within our network, and also from outside our network.
Customer A seems to be using squid as a proxy.
I can't think what the problem could be, and I've run out of ideas of things to test. The fact that I can log in as the customer fine and other customers don't have any issues seems to eliminate the code and database as problems.
What other things could I do to try and isolate the problem?
By dumping out the request data I was able to work out that something (I'm guessing the proxy) was removing the form values from the request. This obviously meant the app didn't work properly.
However, it seems whatever was removing the form data was leaving content-length unchanged, which would explain why the client was timing out waiting for more data and the server thought it was finished.
By using https instead of http (which we were going to do anyway), the request tampering seem to have stopped.