This could very well include complete SQL statements, "secret" parameter names, file paths, and lots of other potentially harmful things.
Could you explain to me how SQL statements can help a cracker if your program is well written? After all, you do use quote methods or placeholders, and you check data before using it -- or don't you?
The same goes for file paths. I see no problem in telling that my home page is located at /vhost/juerd/juerd.nl/index.plp. Does knowing the path enable you to use files that can't be read by my apache daemon? If my code was written badly, you could guess the number of times you need "../" to get to the root directory, but my code doesn't use paths without checking (or even parsing) them first, so that information is completely useless.
Secret parameter names in your code are often a sign of bad programming too. Do you put your SQL passwords in your code, or somewhere safe, with nice 403 error messages if anyone tries to get it through http?
To avoid being cracked, it's better to conceal version numbers than source code. After all, Apache's entire source code is open, MySQL's source is completely disclosed, and so is Perl's. Why hide parts of your own source if those parts can help debug?
Not to the user - the user should get a friendly "Sorry" screen, with instructions to try again
Yes, the user should get a "try again" and a "sorry". But some users, like me, hate to not know what's going on. If I'm going to report a bug, I'm going to report it in great detail. If there's no information, I never report it - I assume some automatic e-mail is being sent, because if the author wanted me to report the bug and does not send error e-mails automatically, he'd have included the information he needs to fix it.
I don't like using Microsoft Windows. Why? Because since the very first General Protection Fault I ever saw, to the recent blue screens and Fatal Exceptions, I have absolutely no idea about what goes wrong when something goes wrong.
Not all users are Teletubbies saying "uh oh" and "again" when something goes wrong. There should be a friendly message for those who are, but there should be detailed information for those who like to know more.
This site uses error IDs, which apparently are mapped to some place in a log. I have seen quite a few after the server move, and it was annoying. The only thing I could do was paste the message, while I would have liked to be able to suggest a fix, or at least have a clue about what error I had triggered.
When I get an e-mail message with a bug report from one of the sites I maintain, and the user was smart enough to supply all information, I can often fix it within a few minutes. If I get an error-ID (I tried several methods of reporting bugs), I have no idea if the bug is going to be huge or tiny, and I'm not motivated at all to fix it.
Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
Read Where should I post X? if you're not absolutely sure you're posting in the right place.
Please read these before you post! —
Posts may use any of the Perl Monks Approved HTML tags:
Outside of code tags, you may need to use entities for some characters:
- a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
Link using PerlMonks shortcuts! What shortcuts can I use for linking?
See Writeup Formatting Tips and other pages linked from there for more info.
| & || & |
| < || < |
| > || > |
| [ || [ |
| ] || ] ||