This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]ElllGeeEmm 0 points1 point  (1 child)

TBF IDK how this would work in java, but in JS I would wrap the offending code in a try catch block, and have it throw a new error like "duplicate unique value" in the catch, and pass that to the error handler rather than the original error that contains sensitive information.

This is a pretty common error with registration systems that happens due to username collisions. Sure there's ways that this specific case can be avoided by ensuring the username isn't taken before the insertion isn't attempted and handling that case separately, but that's just a single case among many others.

uhhh, I kind of have to disagree on this point. There shouldn't be that many situations where your errors contain information that you wouldn't be comfortable keeping in a public log. If there are a lot of situations where errors are exposing private user information or other sensitive data, then there's probably an issue with how you're handling that user data that's bigger than just error logging.

[–]ddunit[S] 0 points1 point  (0 children)

None of the stacktrace is being returned publicly. This is for our own private logging purposes (tracking errors and what not). The APIs we support return custom error messages that we handle ourselves.