We have deployed our solution to a closed environment, and sometimes it is hard to debug problems because we can't even collect logs fast enough.
We devised a way to download the local log files via our own web forms application, but if the problem prevents access to that page in the first place, we are in the dark for a few hours.
The question then is: is there a way to display the original YSOD only to a specific, static IP address? That way, we would configure our company's static IP address to allow full debugging by displaying the original error instead of the user friendly custom error page.
Apparently, the default customErrors mechanism doesn't seem to allow control this fine grained.
A solution that still respects the original customErrors configuration on web.config would be ideal, as we would like to keep the custom page for random users accessing from other addresses.
Look up ELMAH. It can be found here. I have just downloaded via Nuget and so far it's pretty cool. It keeps track of all exceptions that occur and you can see the YSOD. All you ahve to do is go to your url for example.. www.example.com/blog/elmah.axd and you are able to view all the errors that have occured. You are able to use SQL as well. If you go that route, I'm sure it's really easy to pull all exceptions that occurred on a certain IP. You can also have emails sent to you on the error, and an RSS feed. It's really easy and quick. You are able to set it up to authorized users only. I'm using Active Directory so any user in "SoftwareDevelopers" are able to see the ELMAH log.
Hope this helps!
Related
I have a running website (based on ASP.NET MVC) on some domain, let's say mydomain.com
Yesterday I was looking into site access logs and I noticed very weird logs: inside it, I saw different domain!
Something like anotherdomain.com/somePage
And I saw exception text in my log saying that 404 - anotherdomain.com/somePage can't be found. It looks like somehow my code running on some other domain (Request.URL show different domain).
How it is possible? Does that means that someone somehow got access to my host (I running on Azure) and steal my binaries and deployed on another host? Or maybe my website opened from iframe?
I need to understand in order to determine whether I have a breach.
If I had to guess, I would bet that someone accidentally set their domain's DNS records to point at your server. You can check where the A record for the domain is pointed with nslookup or whoisfrom the command line. If they are in fact mis-configured, you should contact the site administrator to let them know. This kind of mis-configuration, while uncommon, can happen more frequently with cloud services due to the inherently transient nature of the servers and routes used.
It's actually possible to make a GET request to access other domains, via your domain, to check if there's a badly configured proxy. Since you're not, it simply returns a 404 Not Found because you are not actually hosting those pages.
Scans like these happen all the time and is an unfortunate side effect of being connected to the internet, but does not mean that you are under attack or that someone has access to your host.
I have a diagnostic web application hosted in IIS7 that has Windows Authentication enabled and Anonymous auth disabled. This application generated some kind of a report where it includes information about what kind of authentication was used to view the site. Every time I browse to this site I get a message that I connected using Anonymous authentication which for me is unbelievable. The report works fine (tested on other machine) and the fact is that I do not get a credentials popup. How is this possible and how can I fix this?
First, i'm not knocking your diagnostic application, but it may be worth looking at the IIS logs (or indeed switching them on for your site) to see what IIS thinks is going on. If you're not familiar with IIS logs, I'd suggest writing them in Microsoft format (at least while you're sorting this problem). One of the key fields you get is the user id. If you really are hitting the pages anonymously, this id will be the id you configured to field anonymous requests. Otherwise, it will normally be the calling user's id (at least in a simple scenario).
Second, how many sites are you running? Are you sure you're going in through the expected site? Or maybe you're hitting the default site instead?
Third, bear in mind that authentication can be set at the site level but anso at the page level. Are you sure one isn't overriding the other?
As the title suggests:
What is your opinion on allowing administrators to update the SQL Server Connection string dynamically from the application versus just showing them the connection details in the application?
Because the database connection is so important and on a heavily used system the abrupt change to the connection seems like it could cause problems. However I would think displaying the server and catalog and whether the connection is using SSPI or SQL Auth could be helpful for administrators who don't like playing with .NET config files.
Thoughts?
How are you identifying administrators? Presumably not by looking at the database. Because if you do use the db and then change the database to another server, it's possible they aren't administrators or there's no database, and then bam - they can't get in to fix it.
Typically, I like to do maintenance on this out-of-band (the config file or even in Active Directory, so it's in a centrally administered resource). We also typically have application administrators (roles, maintenance, approvals, workflow-related "administrators") who really are not system administrators in a technical sense. And often, we do not allow system administrators as user, managers or administraors within the application. i.e. I might have a purchase order system administrator who can void a purchase order, but they can't change a database connection and I have a sys admin who can't even create or approve a purchase order, let alone void one, but they can change the database connection in the config or in Active Directory as part of an upgrade or migration.
I agree that a debug page, help page or about page can be useful to show information to both system administrators and application administrators. Whether they should be allowed to change things there really depends.
Sounds like two bad ideas. Allowing changes to connection strings while the app is running is sure to cause disruption (broken connections, data out of sync, and who knows what else). And even displaying connection details to anyone (even admins) seems like a dangerous security hole.
What kind of site do you have where this sort of thing would be necessary?
Requires that your application run in full trust, otherwise it's just using the System.Web.Configuration namespace:
http://www.beansoftware.com/ASP.NET-Tutorials/Modify-Web.Config-Run-Time.aspx
On any change to the web.config the app will recycle, so still isn't something you'd want to in the middle of the day if sales might be in flight.
Also, usually authentication and authorization relies on the database. So if you can't authenticate and authorize, you won't be able to get to the admin page to change the connection string! (Unless your authorization and authentication has nothing in it that touches the database, at least for the admin page your considering)
Personally I don't like letting administrators change ANYTHING on a live site. All configuration changes should go through the same version-controlled, time-stamped, user-attributed, build-system-checked process that source code goes through. Only then can you draw connections "this stopped working at time X because user Y changed configuration A at time B".
An extreme view on the topic I know, but given the huge proportion of downtime that can be traced back to operator error I believe is justified, and I honestly can't understand the fascination people have for being able to edit fragile XML files on live servers where a single extra '>' can bring the entire site down.
Here is the situation. I have a site that only allows one user to be logged in at one time. However, I need a server to scrape this site and put data into the database. However the admin need to be be able to log into this site from time to time.
So what I would like is for the server to proxy the admins login so that the server won't attempt to login while the admin is logged in.
How would I go about doing this?
Thanks
EDIT: Sorry, it totally slipped my mind, the reason I need to come up with such a complicated setup is because I do not have the source for this site, nor does the site allow any sort of extensibility. Basically I plan to add features by proxying the site through a more featured filled version of the page that will allow the user to access features not availilbe for the sites normal interface.
If this is a web application you've built yourself, you should be able to track this pretty easily. You just need code that stores the login state of your users in a global way. Possible ways of doing this would be to utilize the database (if this is database driven) or store it in an Application variable (if this is done in ASP.NET).
Then whatever process you've put in place where the server is "scraping" the site can check to see if anyone is logged in before logging in itself.
However, I must ask -- is this something you've built yourself or are you trying to add functionality to an existing product? The reason I ask is that I can't figure out why you tagged this with "proxy" and not the language it was written in. If you don't have access to the source code, for example, that would change things.
I have an asp .net webforms app that uses forms authentication. For a small number of users we have a problem where they log in, they navigate to a couple of pages and then they are asked to log in again. Once logged in for a second time they seem to be able to stay logged in as expected. They shouldn't be asked to login the second time.
This is a single server, no web farms, nothing tricky.
This only happens to a few users, but it does seem to be all users from the same building. I am unable to replicate this and at this point might even start to deny that t was happening if one of our trainers hadn't watched it happen to a couple of customers.
Has anyone else seen anything like this?
I am also seeing a lot of "Membership credential verification failed." errors in the event log. This may be related, but all the googling I've done seems to point to web farms and the like, not a single server.
UPDATE
There is no proxy server, the IIS server and the browser (IE8) are both on the same machine.
The AV software installed is Symantec Endpoint, on one machine, on the other the user didn't have any AV at all (AV Fail!).
The browser is IE 8 with no frills, not a single addin that didn't come with the default installation.
Both session and user login time-outs are set to 30 mins and the problem happens within 1 min of the user logging on.
Logging shows the user to only have one IP address.
I have tried the sessionMode in all it's variations, this doesn't seem to make any difference.
Something has to be causing ASP.NET to think these users have new sessions or their authentication cookie is getting invalidated. Here a a few things I can think to check:
Are the users accessing the site through a proxy server? One of our customers has a proxy that will sometimes close all open connections causing ASP.NET to see the session as new.
Could an overly agressive anti-virus, anti-spyware product be "eating" the session authentication cookie?
Do they have a cookie manager browser add-in that is causing the authentication cookie to disappear or change?
Sounds basic but I've seen this happen because of site timeouts being set too short. If the user sits on the page for longer than the timeout, they will be forced to logon again. And this could be specific to a page when that page presents a large amount of data that takes a while for them to go through.
One other thing I just thought of, have you allowed multiple worker processes for the ASP.NET process (aka web gardens)? If so, the same constraints as with a web farm would apply for authentication.
Crack open Fiddler from the problem user's PC and see what's getting passed in the headers. My bet is on a proxy server and or networking issue.
Are the users possibly coming from a dynamic ip address? I've seen problems where the users sessions get messed up because the IP address that they're accessing the site from changes for some reason.
Are the people this is happening using a browser that's somehow different (different browser, different version, different extensions)? That could be a clue.
In general, when the problem is somewhat reproducible or at least predictable, I use Http Fiddler. Install it on a client machine, turn it on, and start browsing (this works via a system proxy - so it'll work for firefox, IE and any other proxy-supporting browsers alike). Fiddler will record all http traffic between client and server, and you can then peruse such a session later on to find any oddities.
It's a long shot, but one thing I've seen happen occasionally that can lead to these sorts of unpredictable errors is scripting parallelization issues: sometimes buttons + links have onclick handlers which cause a post-back. If you have several such handlers that fire on the same event - in particular when the default event still fires additionally to your custom onclick or whatnot - you may be causing several postbacks when it appears to be just a single postback. That can cause all kinds of unpredictable weirdness as it's not entirely clear which request ends up "winning" - and some odd errors may cause a session to terminate. Since this behaviour is very browser + network latency sensitive, it seems quite unpredictable when it occurs.
Delete the cookie on the client PC's that are playing up
ASP.NET Forms Authentication can redirect users to the login page if they do not have the credentials to access a specific page. It does this so that users who may have more than one login are given the opportunity to login with another account which may have the appropriate access. Basic question I know, but are the users using the same credentials the second time they log in?
Its possible that you have don't have specifically specified asp.net to use cookie based session but are allowing either cookie or cookieless sessions.
In the later case the session id is embedded in the Url. The type of issues you are experiences might be explained by that. Basically depending on how you define your links, some of them would not get the session id, so the user would get a new session when using those links - or maybe during a redirect. That could explain why at specific parts of your site the users loose their session.
If you have the mixed mode enabled, try setting it to only cookieless and go through your site.
Update: Based on the extra info posted there is surely more info needed for it. Some extra things to check:
Are you using subdomains, if that's the case the cookie might not be configured to allow that and that doesn't fail in all environments.
If you are using in-process session, make sure there isn't a bug in the application causing it to restart the process
Maybe what's causing it to ask for login again is an authorization check, and you have an issue on some roles related code
Is it possible that the user is just opening a separate window? ;)
To rule out the possibility of the browser or a browser addon messing things up, have you checked their User Agent strings? If they are randomly distributed it might not cause the problem, but if they're all the same, this might be a hint too.