Replacing the Error 500 ASP Page - E-Mailing Errors (Page 5 of 7 )
Another very simple feature that can be added to the error page is the ability to notify the developers that an error has occurred on a live site. This can be achieved by adding a single function to the ASP page - SendEMailNotification.
This function has only to instance the CDONTS.NewMail class, set values for the recipient, subject, and body, and then send the e-mail. Whether or not this function is called will be based upon the IsLiveServer setting previously implemented.
The information that is sent can not only include the error that occurred, and when, but also the data that was posted to cause the error and the current server settings, which may help diagnose the error more readily.
The only real logic performed in this function is a check to ensure that the NewMail class has been instanced properly (so that errors aren't generated on this page), and ensuring that the email is formatted properly to omit properties (such as Column) that may not have values.
It should be noted that the From property of the NewMail class should have a valid e-mail address in it, otherwise the virtual SMTP server may fail to send the message. Such functionality could be implemented as below:
Set objASPError = Server.GetLastError On Error Resume Next Set objMail = Server.CreateObject("CDONTS.NewMail") On Error GoTo 0
If Not objMail Is Nothing Then strDomain = Request.ServerVariables.Item("HTTP_HOST") objMail.From = "error@" & strDomain objMail.To = "firstname.lastname@example.org" objMail.Subject = "Error in http://" & strDomain & _ objASPError.File
objMail.Body = objASPError.Description & vbCrLf & _ "Any other information can go here"
On Error Resume Next objMail.Send On Error GoTo 0 End If
In environments with more elaborate bug-tracking systems, this feature could be altered to create an entry in a bug-log to ensure that it is dealt with properly. If the file that caused the error contained the developer's name, then this bug could also be allocated to the correct person.
In stricter situations still, such information could be used to determine the percentage of errors introduced by each developer in a team.
When simple errors are detected when coding and testing on a local machine, it is often an annoying process to find the offending ASP file, check it out of any source-control system (such as Source Safe) that is being used, make the change, and check it back in; especially when the error is regularly something as trivial as a mistyped statement such as the infamous Resposne.Write. This is made even more annoying when the error is on a development server that has a file-system that may be remotely inaccessible, making updates using Interdev, Notepad or any other local editor impossible.
In such cases, remote management tools such as Terminal Services, PC Anywhere, or VNC are regularly the main way of accessing these files. Worse still, an FTP connection may be the only method of accessing the files. Updating files in this manner may in itself introduce errors from uploading to the wrong location. This is especially true if there are multiple versions of the site on the machine.
To solve this problem, the error page is to be extended to allow the editing of the page in-situ. In theory, if such editing is to be common-place, then usage of a Java applet, an Active-X control, or client-side script instancing an editor of choice are all reasonable options. For this article, we'll settle for the relatively simple task of adding a <textarea> element and a button to demonstrate the theory.
There are still special cases and best-practices to be considered though. Firstly, the editing pane is not to be displayed all the time - only on the request of the user. This is to remove the possibility of accidentally editing code.
The text-area and submit button are placed in an invisible layer that is only shown when the Edit Code >> button is clicked. Similarly, the code can be hidden by clicking on the same button again.
More seriously, when the form is submitted for processing, we must be very careful about what action is taken. The usual case of checking a form variable such as "Action" to see if the user is trying to edit a page cannot be trusted as this action may be taken prematurely - when the original error occurs, if such a field exists on that page.
A check to the HTTP_REFERER would be the ideal solution, but is unfortunately out of the question. As the 500-100.asp page is executed using a Server.Transfer call, as far as the browser is concerned, when the error page is displayed it is still at the original location, not that of the error script. Instead, the form fields must be constructed in such a way as to remove the possibility of accidental editing. In the sample code, the field that is checked is called "Err500Action".
To complete the editor, only two things remain to be done. Firstly, a hidden field must be added to the form specifying the URL that is to be edited (technically this could be retrieved from the HTTP_REFERER variable, but that would then rely on the browser sending that information; alternatives to IE may not. Secondly, the server side processing to edit the file needs implementing.
This simply involves the instancing of the FileSystemObject class, and the contents from the page writing out to the relevant text-stream. The result of this (success/failure) is then reported to the user via the message box at the top of the screen.
It should be noted that there is potential for end-users to edit the source code of a site if they can convince the IsLiveServer function that they have developer privileges. If this code is to be used on a live server (which if a rigorous development and porting process is being adhered to, it shouldn't), then it should be ensured that there is no reasonable method by which any unauthorized person can forge the credentials required to allow the display of the debugging page/editing of the source code.
For the editor to actually function, it must be ensured that the user's context that IIS is running under has the relevant permissions to edit the file. If this isn't the case, the error that will be displayed on the Error 500 page will be "Object required" as an attempt to edit a file that could not be retrieved will have been made. If the On Error Resume Next code is removed from the line above the OpenTextFile() call, then the true error of "Permission denied" will be seen. To allow editing, any users that are to have access to this online code-editor must have read and write (modify) permissions to the files that exist in IIS's virtual folder-structure.
If NTFS is being used, then this can be done from within Explorer by right-clicking on the relevant files/folders, then selecting the "Security" tab, and enabling rights to the relevant users (probably IUSR_ Machine name amongst others).