Avalon Doesn't Remove Zero Width Space Character

[joncameron]

Description

When adding a value to a field within Avalon, a frequent user action is to copy and paste this value (corresponding to the name of an external group, in this instance) into the text field and save. A problem occurs when this copy action picks up non-printing characters that are retained but not stripped by Avalon. This results in situations where to the user the value seems fine—exactly the characters they submitted—but since the strings aren't equal due to these hidden characters, permissions don't apply correctly. I encountered with with the zero width space character (https://unicode-table.com/en/200B/) but it may also apply to other unicode characters.

To Reproduce

Add a value to "External Groups" under the Special Access of an item's access control with a zero width space character in it. The group will be unable to access this item because the group name, "MCO LTI Test" for example, is "MCO LTI Testu+200B".

Copying and pasting from the Canvas course ID name contained in an email into a certain editors show this extra information. In Vim for example the unicode character is displayed as:
MCO LTI Test​<200b>

Example

Item 1: https://media.dlib.indiana.edu/media_objects/rb68xg57v/edit?step=access-control
Item 2: https://media.dlib.indiana.edu/media_objects/d791sk993/edit?step=access-control

Item 1 included the u/200b, and does not appear in the "MCO LTI Test" course. Item 2 doesn't contain this character and appears normally.

Done Looks Like

Avalon forms are tested to find all places where whitespace trimming is not occurring. Controllers updated to fix all of these instances.

[cjcolvar]

Places needing to be fixed:

Collection

• Collection name

Media Object

• username/group permissions

[cjcolvar]

@SumithBaddam I talked with @joncameron about this issue and he and I thought we could strip the zero-width space characters from all user input for now. If we ever find a use case for keeping it then we can do the more involved solution then.

@jlhardes does this seem okay to you or do you think there is a strong case for preserving zero-width characters in user inputted text like item descriptions?

[cjcolvar]

I talked with @joncameron and @jlhardes and I think the plan is to strip any zero-width characters from the beginning and end of any user input.
@SumithBaddam The before action I gave you is probably not sophisticated enough and we'll have to walk the tree of parameters and do the stripping if it is a string.