We currently have fairly robust error handling functionality in our ASP.Net application.
We log all errors in the database, a text file on the server
and also send automated emails containing the error details back to our support people.
This all happens on the server of course.
We would like to capture (and retrieve) an image of the client browser at the time the error occurred to provide additional info for troubleshooting?
Is this at all possible?
If so what would be an elegant approach to this problem?
This is not technically impossible, but it is so impractical for nearly all purposes that it might as well be impossible. You would need a plugin running on the client's machine which can receive instructions from your error page to take the screenshot, connect to the server and upload it.
If your client screens have complex data which affects the state surrounding the exception, you should revisit your design to ensure all of that is recorded before it's sent to the client, so you can keep all relevant state tracked with a given exception.
Saying something is "impractical" is usually easier than actually trying to solve something that is difficult, but not technically impossible.
I have done some more research and have come across
an approach that allows one to get hold of the rendered html server side.
Further more, there are ways to also convert html to images
I will implement the solution using a combination of the two.
Capturing a client browser screenshot is not possible due to security and privacy reasons. What you can (and imho you should) do is capture the url and the browser version and try to reproduce it in the same environment.
Related
I tried to look it up but there is no real comparison, just mentioning that both of these make better performance, maybe anyone knows which of those approaches are better for client and server performance?
It seems like ssr gives all the hard work to server giving plain html to client. Also, it attaches data to whole template, so every time it changes, template is resend to client?
One thing I think would be nice but I'm not sure about it, if data is sent from server are publishes still needed?
I was searching for information about one of my doubts, but I couldn't find any. I'm working in an ASP.NET site and using AJAX to require data, since I'm currently working on my own, I don't know web programming's best practices.
I usually get all the information I need from the server and use Javascript to display / Modify it and AJAX to send it back to the server. A friend of mine uses PHP for most part of the programming, He rarelly uses any javascript and he told me it's way faster this way, since it does not consume the client's resources.
The basic question actually is:
According to the best practices, is it better for the server just to provide the data needed for the
application or is better you use the server for more than this?
That is going to depend on the expected amount of traffic for the site, the amount of content being generated, and the expectations of the end-user.
In a high-traffic site, it is actually "faster" for the end-user if you let javascript generate a portion of the content on the client side. Also, you can deliver a better user experience with long load times through client side scripting than you can if the content is loaded completely on the server.
In most cases you would need at least some backend code. E.g. when validating user input or when retrieving information from a real persistent database. Or what about when somebody has javascript disabled in his user-agent or somebody with a screenreader or searchengine crawlers?
IMHO you should at least (again in most cases) have the backend code which is able to do all the work and spit out a full webpage to the client. In addition to this you can add javascript functionality to make the user interface "smoother" by for example validating user data before submitting it to the server (remember to ALWAYS also check on the serverside) or by loading partial html (AJAX).
The point about being faster or using less resources when doing it serverside doesn't make much sense. Even if it does that it doesn't matter (but again I highly doubt this statement). If you use clientside scripting to only load parts that are needed it would rather use less resources on both the client- and the serverside.
I recently received a feedback from a colleague about my source code of a website. He says that it is a bad practice to not handle gracefully what visual interface does not allow to do.
Since it's not very clear, here's an example.
Let's say a visitor can comment something.
A comment is saved into a database, in a nvarchar(500) column.
The <input /> field length is limited to 500.
But, of course, nothing forbids to a more advanced user to disable the length limit and to type 501 character.
(Other examples: submitting an option which does not even exist in a <select />. But there is a graceful error when the user is asked to enter a number, and she enters a non-number instead, since keypress events are controlled through JavaScript, and JavaScript may be disabled)
If the visitor does so, there would be a failure on code contracts level. The AJAX request would fail with an unexpected error (or, on page submit, there will be an unexpected error). In all cases, the visitor will see that something wrong happened, but will have no graceful message indicating that the length of the submitted comment is too long.
Why is it bad practice? Why would I bother to design clear and explicit error messages for the cases where the visitor who uses correctly the website will never have?
Note: I understand that it sucks to display a .NET Framework detailed error and a stack trace when something like this happens. If I do so, it's a serious security issue. But in my case, there is just an AJAX response with something very generic or a redirect to a generic page with the apologizes about an error.
Since everyone appears to be missing your actual question, I'll put in my 2c (though I'll no doubt be downvoted in retaliation)
As long as your inputs are validated server side (your client-side maxlength is probably ok, though some obscure browsers may not support it), you can return a generic error message as long as it contains no exception information (which you have stated it doesn't).
If, however, it's possible to fail validation via lack of javascript or incorrect entry, then a custom error message should be provided for the sake of the user's sanity.
In short, what you are doing is fine.
First an most importantly
You should validate everything the user supplies on the server! This means not letting 501 letters through
Other than that if an unhandled exception occurs you should show the user a message which gives nothing away. If you were to return exception information this is gold dust to an attacker.
The best method is to display a general error such as "We're sorry, we're working on the problem straight away" and e-mail the exception information to the developers in order for them to fix it.
Why would I bother to design clear and explicit error messages for the cases where the visitor who uses correctly the website will never have?
If everyone used the web correctly, we'd never need to have validation.
As Ronald Reagan once said, "Trust, but verify".
Put in server-side validation for the length of fields. Put in validation to make sure there aren't any XSS or SQL Injection attacks. It's not the people who use your site correctly that you have to worry about, it's the ones that use it maliciously.
I think that the largest part of the problem is that you are assuming that validation should only be happening in the UI. It really is best to validate in the UI and the backend. There is no need to return a stack trace or detailed exception information. On Page_Load(), you should always be validating all user input again and displaying the information statically, as if the user has disabled JavaScript.
What you're describing isn't just bad practice, it's bad design. If you can anticipate an error or exception, then you should anticipate methods of handling it, mitigating it or alleviating it. This goes for any interface design whether it's for a website or a refrigerator. If a visitor gets a generic error and is given no insight as to how to fix it, then why should that person bother using your website? If they're forced to (for work reasons maybe), then all you've done is alienate your customer and give yourself a bad name.
I would suggest you ask yourself why you're not handling these very easy to control situations. Is it laziness or do you just lack experience as a user?
Server side validation is for two main purposes:
as a graceful degradation if the client validation doesn't work for some reason
in this case, you want a nice user-friendly message
as a security measure to ensure malicious clients can't damage your system.
in this case, you want no internal details displayed
If you want to take the route of true graceful degradation, it would be NICE if the server still gave back the user a friendly message for each validation.
In the case of maxLength, this is not very likely to be needed. But many kinds of validation use Javascript, and there are still those people or platforms that don't support Javascript. Older mobile platforms would be the main suspects here.
However, these days, most of us assume that Javascript can be relied on, so a generic error message if server validation fails is fine.
I'm looking to create a webpage that will reflect the status of one of my company's servers automatically. Frequently there will be a minor error that only lasts 2-3 minutes, and it would be great to have this reflected on a self-generated page, which might prevent 50-60 unhappy clients from calling in simultaneously and asking what's wrong.
I'm not quite sure where to begin - would anyone have a suggestions for good resources to study? Programming examples? I'm not referring to the basics of writing an ASP.NET page, of course, but rather process interaction in Windows.
Thanks.
To pull this off, you'd need a separate page that essentially runs server diagnostics, otherwise the page wouldn't know if it was up or down. Also, the page would need to be isolated from the sort of problems that are kill other people's requests, such as cache hit problems, memory starvation, high CPU usage, insufficient bandwidth. So ideally the diagnostics would run in a separate app-pool, separate virtual directory, separate machine.
Many of the interesting diagnostics would require a WMI call, but some you can get from the My.Computer namespace.
Also, are you going to do this on every server, or do you want one web server to display the status of several different servers?
It also depends on the type of errors your servers are encountering.
If they are going down completely, or are losing internet connection, then pinging them after an interval of time will let you know if they are up or not.
If you have a specific process running on a server that becomes unavailable, that can be a little more tricky.
Your best bet is to find a way to do a simple request from the services/applications that are important and see if you get a response, if you do, the server is likely up, if not, then it is likely not.
Anything you can do to reduce the number of support calls you get is a good idea, but I'd also focus some time and try to figure out why your servers are going down so often.
Also, telling your users that the server is down, but not giving a reason why may not give the effect you are looking for. Users will still be confused and frustrated when they can't get their work done.
I know you were looking to build a webpage to display the server diagnostics, but there are plenty of server monitoring tools that produce webpages for an easy dashboard view of the history.
A quick google returned the following link:
http://www.webdesignbooth.com/10-really-useful-server-monitoring-tools/
I know that using non-GET methods (POST, PUT, DELETE) to modify server data is The Right Way to do things. I can find multiple resources claiming that GET requests should not change resources on the server.
However, if a client were to come up to me today and say "I don't care what The Right Way to do things is, it's easier for us to use your API if we can just use call URLs and get some XML back - we don't want to have to build HTTP requests and POST/PUT XML," what business-conducive reasons could I give to convince them otherwise?
Are there caching implications? Security issues? I'm kind of looking for more than just "it doesn't make sense semantically" or "it makes things ambiguous."
Edit:
Thanks for the answers so far regarding prefetching. I'm not as concerned with prefetching since is mostly surrounding internal network API use and not visitable HTML pages that would have links that could be prefetched by a browser.
Prefetch: A lot of web browsers will use prefetching. Which means that it will load a page before you click on the link. Anticipating that you will click on that link later.
Bots: There are several bots that scan and index the internet for information. They will only issue GET requests. You don't want to delete something from a GET request for this reason.
Caching: GET HTTP requests should not change state and they should be idempotent. Idempotent means that issuing a request once, or issuing it multiple times gives the same result. I.e. there are no side effects. For this reason GET HTTP requests are tightly tied to caching.
HTTP standard says so: The HTTP standard says what each HTTP method is for. Several programs are built to use the HTTP standard, and they assume that you will use it the way you are supposed to. So you will have undefined behavior from a slew of random programs if you don't follow.
How about Google finding a link to that page with all the GET parameters in the URL and revisiting it every now and then? That could lead to a disaster.
There's a funny article about this on The Daily WTF.
GETs can be forced on a user and result in Cross-site Request Forgery (CSRF). For instance, if you have a logout function at http://example.com/logout.php, which changes the server state of the user, a malicious person could place an image tag on any site that uses the above URL as its source: http://example.com/logout.php. Loading this code would cause the user to get logged out. Not a big deal in the example given, but if that was a command to transfer funds out of an account, it would be a big deal.
Good reasons to do it the right way...
They are industry standard, well documented, and easy to secure. While you fully support making life as easy as possible for the client you don't want to implement something that's easier in the short term, in preference to something that's not quite so easy for them but offers long term benefits.
One of my favourite quotes
Quick and Dirty... long after the
Quick has departed the Dirty remains.
For you this one is a "A stitch in time saves nine" ;)
Security:
CSRF is so much easier in GET requests.
Using POST won't protect you anyway but GET can lead easier exploitation and mass exploitation by using forums and places which accepts image tags.
Depending on what you do in server-side using GET can help attacker to launch DoS (Denial of Service). An attacker can spam thousands of websites with your expensive GET request in an image tag and every single visitor of those websites will carry out this expensive GET request against your web server. Which will cause lots of CPU cycle to you.
I'm aware that some pages are heavy anyway and this is always a risk, but it's bigger risk if you add 10 big records in every single GET request.
Security for one. What happens if a web crawler comes across a delete link, or a user is tricked into clicking a hyperlink? A user should know what they're doing before they actually do it.
I'm kind of looking for more than just "it doesn't make sense semantically" or "it makes things ambiguous."
...
I don't care what The Right Way to do things is, it's easier for us
Tell them to think of the worst API they've ever used. Can they not imagine how that was caused by a quick hack that got extended?
It will be easier (and cheaper) in 2 months if you start with something that makes sense semantically. We call it the "Right Way" because it makes things easier, not because we want to torture you.