1

Scenario: We have a website that is viewed both internally and externally. When an error occurs the users are displayed with a detailed error page(Stack trace etc).

Problem: The external customers do not need that much information about the error. We are looking to have the external customers see a messsage instead. Ex. Please contact Administrator. Also if possible we would like to log this message in our SQL database.

Note: I'm assuming I make a custom error page like - Implementing a Custom Error page on an ASP.Net website but how do I determine whether or not the user is internal/external? Also is this the best way to approach the problem? Additionally if anyone has suggestions on the best way to store these errors in the database that is also appreciated.

Thanks in advance.

Community
  • 1
  • 1
Gage
  • 7,365
  • 9
  • 47
  • 77

5 Answers5

4

YOu can try settings your mode to RemoteOnly in the web.config

<customErrors mode="RemoteOnly">

This way local users will see the error, and external users will see the other error pages which you have set up.

There is an article here about such things http://aspnetresources.com/articles/CustomErrorPages

Tim B James
  • 20,084
  • 4
  • 73
  • 103
  • Best way of doing it. Doing anything in your code would be a hack. – batman Jun 22 '11 at 15:58
  • 2
    Correct me if I'm wrong, but doesn't RemoteOnly simply mean "people accessing not from this machine"? If so, then this doesn't answer the question. – The Evil Greebo Jun 22 '11 at 16:01
  • Doesn't customErrors only differentiate between browsing from the server itself vs. browsing from outside the server? The OP's scenario is browsing internally from within the company (not necessarily the server itself) vs. externally from outside by customers. At least that's my reading of it. – Yohan P Jun 22 '11 at 16:03
1

The way I would do this is to have different entry points for external and internal users. I would do this through the hostname. By varying the hostname I could then create a custom error experiance for each type of user.

Jeff
  • 5,913
  • 2
  • 28
  • 30
1

If by 'internal' you mean logged in, and 'external' you mean anonymous, you could use the same custom error page but check the user's logged in state using Request.IsAuthenticated

You could then simply display the message based on the user's status.

For storage of errors you could use log4net and/or ELMAH. ELMHA is specifically for catching unhandled exceptions. Log4net is predominantly for logging from within your code, i.e. from within a try/catch statement.

It is good practice to use both.

Digbyswift
  • 10,310
  • 4
  • 38
  • 66
0

That article is on the right track of what you need to do. Also, see:

The determination about whether a user is internal or external will be handled by the web server.

FishBasketGordo
  • 22,904
  • 4
  • 58
  • 91
0

customErrors for RemoteOnly will probably not help you because RemoteOnly only refers to users not accessing the page from the same physical box. Users on the LAN will be treated as remote just like users from the WAN will.

If I had to solve your problem, I would start in Application_Error and examine Request.UserHostAddress and Request.UserHostName but even those are not going to be completely reliable because on my corporate intranet, my address of 10.4.42.219 might very well match your companies internal addresses, and UserHostName is supposed to be a human readable name but it isn't always - case in point, look at it running in debug mode and both UserHostAddress and UserHostName will be "127.0.0.1" when you'd expect the latter to be "localhost".

See the problem here is that by the time they hit your webserver, they're inside the firewall, and the server is a listener - so it doesn't matter what IP the incoming connection CLAIMS to be from (spoofing being a very real problem), your webserver isn't gonna initiate a response, it's going to send a response down the very pipeline that the client opened.

Now if your firewall can be configured to leverage spoofing and force the IP coming in to be a specific value, that would be one possible way to reliably identify external connections, and by process of elimination, the internal ones but I can't speak to the viability of that approach with any certainty.

Edit to add: I suspect your initial question may itself be flawed. The question I'm asking myself is, who on your internal side really cares about the error message? Is your corporate secretary going to want to see stack trace info? Probably not.

I suspect that what you REALLY need here is active authentication and role based security, such that only specifically identified users - members of the "Error Investigator" role perhaps - should see those detailed exceptions, and everyone else, including internal users, gets the pretty custom page.

The Evil Greebo
  • 7,013
  • 3
  • 28
  • 55