stacker.news icon indicating copy to clipboard operation
stacker.news copied to clipboard

Trim leading and trailing whitespace for the 'forward sats to' option when doing a Link post

Open cointastical opened this issue 3 years ago • 3 comments

I copied and pasted a nym and didn't realize there was a trailing space. A message user does not exist showed. In testing, I see the same occurs if there is a leading space.

And, ... while on the subject. If I paste the nym with the "@" (@nym) that will also result in "user does not exist". This one i'm not sure about since the @ is the field label. I think it would be OK to strip out any @ prefix if exists and then use that value as if that is what the user had entered.

cointastical avatar Aug 14 '22 08:08 cointastical

Maybe whitespace shouldn't even be allowed in the input? Can usernames contain white space? So just show an error message in this case so the user can correct.

I don't like intransparent solutions like trimming whitespace in the backend. I see the use case, but I think showing the error to the user would be better imo.

Same reasoning applies to "@"

ekzyis avatar Sep 20 '22 12:09 ekzyis

I don't like intransparent solutions like trimming whitespace in the backend.

There's not universal sentiment on trimming input field data.

There's some like this:

Your backend SHOULD ALWAYS assume the data coming from the frontend is GARBAGE and do its own clean-up, parsing and validation. https://www.reddit.com/r/golang/comments/oa8uqd/comment/h3k4nl5

Other examples are plentiful, and can vary (e.g., never trim passwords, which I wouldn't agree with but whatever).

Copy and paste results by those copying from html will oftentimes end up with input field data containing leading or trailing whitespace. That we aren't frustrated by "error" messages when this happens is because these are commonly trimmed regularly, on the back-end oftentimes, when the form is submitted.

As far as invalid characters within the data (e.g., username: Firstname Lastname) I would expect a response message (e.g., "username not found" or "contains invalid character"). But a leading / trailing whitespace on a username is certainly extraneous and unintentional, and thus reasonable that only the trimmed value is used.

cointastical avatar Sep 21 '22 00:09 cointastical

Your backend SHOULD ALWAYS assume the data coming from the frontend is GARBAGE and do its own clean-up, parsing and validation. https://www.reddit.com/r/golang/comments/oa8uqd/comment/h3k4nl5

Ah, good point, I forgot about that. You are right. It makes sense to also trim in the backend etc. due to this

Copy and paste results by those copying from html will oftentimes end up with input field data containing leading or trailing whitespace. That we aren't frustrated by "error" messages when this happens is because these are commonly trimmed regularly, on the back-end oftentimes, when the form is submitted.

Ah, I see. Didn't think about copy paste. In this case, I agree. Would make sense to help the user in this case. I just didn't like the idea to put something in the backend the user may not intended. That came more from a general perspective regarding UX with a focus on good error messages. So essentially trim the input (or show error message) and trim in backend (in case someone circumvents the frontend)

ekzyis avatar Sep 21 '22 01:09 ekzyis