[HOLD for payment 2023-02-08] [$250] Strip workspace name of html or handle validation php side reported by @kerupuksambel

[kavimuru]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Action Performed:

1. Open staging.new.expensify.com
2. Create new workspace
3. Change the name of the workspace with <b> </b> and save it

Expected Result:

Either the workspace name changed to after HTML-escaping (something like <b> </b> ), or returned error after the HTML tag got stripped and only the space remained

Actual Result:

The workspace name changed to no name

Workaround:

unknown

Platform:

Where is this issue occurring?

• Web

Version Number: 1.2.21-4 Reproducible in staging?: y Reproducible in production?: y Email or phone of affected tester (no customers): Logs: https://stackoverflow.com/c/expensify/questions/4856 Notes/Photos/Videos:

https://user-images.githubusercontent.com/43996225/198730117-135e716c-ada7-4069-b153-df931cee5fc1.mp4

https://user-images.githubusercontent.com/43996225/198730150-69afdab6-b896-461c-945c-97c8914b4e39.mp4

Expensify/Expensify Issue URL: Issue reported by: @kerupuksambel Slack conversation: https://expensify.slack.com/archives/C01GTK53T8Q/p1666949886613589

View all open jobs on GitHub

[trjExpensify]

@ctkochan22 how you getting on here?

[ctkochan22]

"Please enter a valid workspace name"

Just need to fix the copy I think?

[trjExpensify]

What's the validation exactly? We don't allow HTML tags, or we do, but it's because this is effectively blank?

[ctkochan22]

We strip html tags out when it goes to the php. I wonder if we want to allow that however?

[trjExpensify]

Our Forms pattern would dictate that we validate onBlur. If HTML tags aren't allowed, then I think the error message should mention that and appear onBlur:

HTML tags are not allowed in workspace names.

[ctkochan22]

Sorry, trying to get another WAQ issue out too and was distracted. Fully focused now, my bad.

If we want to set html tags as invalid, we may need to change our approach. Because right now,

1. Set <b> </b> as workspace
2. WAF input rules filters all html out. So when it hits html, its just a space.
3. On the php side, we now prevent adding an empty space as a workspace name.

To validate and prevent submitting html tags onBlur, instead of using .replace here. We could use name.search(/<(.|\n)*?>/g) to check if it has html tags in it (anything with <string>. And if true, we can return the error message, onBlur, "HTML tags are not allowed in workspace names." Does that sound good?

I'd also like to float out there that we allow policies in oldDot to be named with html tags in it. Are we sure we don't want to allow them to save workspace names with html tags in them?

[trjExpensify]

I prefer not to allow HTML tags and use the established Forms pattern to validate onBlur. Reasons being:

• I can't really see a case for where you need to use HTML tags in a workspace name
• They're not doing anything i.e <b> Tom's Workspace <b> isn't being displayed as "Tom's Workspace" everywhere the workspaceName features throughout the App

[JmillsExpensify]

Happened to come across this one scanning through the repo. I think I'm in a similar spot. I don't see why we'd allow tags, though I bet it stems from either inconsistent or a different OldDot philosophy on inputs/form validation, and I don't think that should necessarily apply to NewDot. Given that they do nothing, I'd just as well say we shouldn't allow HTML tags.

[ctkochan22]

Screenshot

[ctkochan22]

If the error message and screenshot looks fine, you can hop over to the PR to check out the video. https://github.com/Expensify/App/pull/13978

[ctkochan22]

During code review @flodnv asked whether we should add this validation to other form/fields as well?

https://github.com/Expensify/App/pull/13978#discussion_r1084123725

I would rather just get this out now as is, and people can add this validation to other fields in need be. However, to @flodnv 's argument, there are probably a lot of other fields, where if you put in html tags. We strip it out on the PHP side with no pre-validation on the App side.

[ctkochan22]

Like in display name. If you put in a <b> </b> as the first name, it fails silently. This is probably because the tags, items wrapped in < > are stripped out before reaching PHP. So then we try to save the first name with an empty space. Which is probably not allowed in PHP.

[flodnv]

I think we should fix this holistically. There is no point in fixing this 42 times now, and 42 times in 3 years from now after we've added hundreds of inputs that don't allow HTML.

[JmillsExpensify]

I agree with that, though I also think we can create a separate issue to do that too, listing out every place where we need to address the inputs/HTML. Like given that this started and as a bug report, I think it's fair to fix this bug and not close this issue until another more holistic one is created.

[flodnv]

I'm ok with that, but I also don't see the reason to do it this way 😄

[ctkochan22]

Lets create two GH's. One to address this one case, that required a Web-Expensify PR and this App PR. Then we can close this out completely.

The other GH (that I can create and assign to myself) will list all the other cases we want this validation. Also checks whether we need PHP changes. And will hopefully be easier to list out all the QA we need to do on each of those forms?

[flodnv]

Sure, if you want.

list all the other cases we want this validation.

What I am saying is that all fields should disallow HTML. I don't know of any field that should allow it.

[trjExpensify]

Yeah, I'm fine going that route @ctkochan22 if you can take it 👍

[ctkochan22]

What I am saying is that all fields should disallow HTML. I don't know of any field that should allow it.

I understand. My issue is we will need to compile all the cases, add php checks, and QA appropriately. I think it'll be cleaner in another issue.

Created the other github: https://github.com/Expensify/App/issues/14610

[flodnv]

Thanks @ctkochan22

[melvin-bot[bot]]

Reviewing label has been removed, please complete the "BugZero Checklist".

[melvin-bot[bot]]

The solution for this issue has been :rocket: deployed to production :rocket: in version 1.2.63-0 and is now subject to a 7-day regression period :calendar:. Here is the list of pull requests that resolve this issue:

• https://github.com/Expensify/App/pull/13978

If no regressions arise, payment will be issued on 2023-02-08. :confetti_ball:

After the hold period is over and BZ checklist items are completed, please complete any of the applicable payments for this issue, and check them off once done.

• [x] External issue reporter
• [x] Contributor that fixed the issue - N/A
• [x] Contributor+ that helped on the issue and/or PR - N/A

As a reminder, here are the bonuses/penalties that should be applied for any External issue:

• Merged PR within 3 business days of assignment - 50% bonus
• Merged PR more than 9 business days after assignment - 50% penalty

[melvin-bot[bot]]

BugZero Checklist: The PR fixing this issue has been merged! The following checklist (instructions) will need to be completed before the issue can be closed:

• [ ] [@youssef-lr / @ctkochan22] The PR that introduced the bug has been identified. Link to the PR:
• [ ] [@youssef-lr / @ctkochan22] The offending PR has been commented on, pointing out the bug it caused and why, so the author and reviewers can learn from the mistake. Link to comment:
• [ ] [@youssef-lr / @ctkochan22] A discussion in #expensify-bugs has been started about whether any other steps should be taken (e.g. updating the PR review checklist) in order to catch this type of bug sooner. Link to discussion:
• [x] [@youssef-lr / @ctkochan22] Propose regression test steps to ensure the same bug will not reach production again.
• [x] [@trjExpensify] Link the GH issue for creating/updating the regression test once above steps have been agreed upon:

[trjExpensify]

I've sort of lost sight of the spider web with this issue. Am I correct that the only payment necessary is to @kerupuksambel for reporting it? Everything else was handled internally in web/auth PRs?

As for the checklist. @youssef-lr @ctkochan22 - do you have any thoughts on the first three?

Re: the regression test, given that adding HTML tags to a workspace name is very unlikely in real-life use, I don't think we add a test case for it to execute on every regression run.

[ctkochan22]

Am I correct that the only payment necessary is to @kerupuksambel for reporting it?

Yes I think so!

the regression test, given that adding HTML tags to a workspace name is very unlikely in real-life use, I don't think we add a test case for it to execute on every regression run.

I agree.

[trjExpensify]

Awesome, thanks for confirming. @kerupuksambel I've sent you an offer in Upwork.

[kerupuksambel]

Awesome, thanks for confirming. @kerupuksambel I've sent you an offer in Upwork.

Thank you. Offer has been accepted.

[trjExpensify]

Thanks, settled up!