Capitalization errors in images and links pointing out to internal SUMO resources

[emilghittasv]

Describe the bug Initially filled in https://bugzilla.mozilla.org/show_bug.cgi?id=1867499

Preconditions Sign in to SUMO

Steps to reproduce Steps to reproduce the behavior:

1. Access a kb article thread (this issue is also reproducible in other SUMO parts where content can be added or edited)
2. Post a reply containing the [[Install Firefox lockwise on Android]] link (notice the lowercase "lockwise". The correct version should be [[Install Firefox Lockwise on Android]])
3. Click on the link.
4. Post a reply containing the [[Firefox Subprocessor List |Test]] (notice the space after the "List".
5. Click on the link.
6. Post a reply containing the [[Image:timetable]] (it should be Timetable).

Expected behavior Step 3: The user is redirected to the Install Firefox Lockwise on Android kb article. Step 5: The user is redirected to the Firefox Subprocessor article. Step 6: The image is successfully displayed

Actual behavior Step 3: The user is redirected to the create a new kb article page (https://support.allizom.org/en-US/kb/new?title=Install+Firefox+lockwise+on+Android) Step 5: The user is redirected to the "Create a New KB Article" page and the firefox-subprocessor-list is automatically added to the slug. This should also red-highlight the slug field since the slug already exists (the red-highlight will be displayed only after trying to submit the KB article while leaving the slug in place.) Step 6: "The image "timetable" does not exist" message is displayed.

Desktop:

• OS: Windows 10
• Browser: Firefox

Additional context

• Reproducible in both stage and prod
• Seems to be caused by our Postgres migration.

[emilghittasv]

@escattone I suspect that the fix in https://github.com/mozilla/kitsune/pull/5887 has caused https://github.com/mozilla/sumo/issues/1672 to occur.

Also, I've noticed that the case mentioned in step 4 is still reproducible in stage. I'm moving this ticket back inside the "in progress" column due to https://github.com/mozilla/sumo/issues/1672

[escattone]

Thanks as always for the thorough QA work @emilghittasv!

[escattone]

If we allow case-insensitive matching at all, it sets up the following possible problems:

Set-Up -- Create a wiki link whose title is not an exact match to an existing image.

• An image with the title Test Image exists.
• Someone creates the wiki link [[Image:Test image]]
• When rendering the article, we can't find an image with the exact title Test image, but doing a case-insensitive search by title yields the image with the title Test Image
• The link is created.

  Possible Problems:

  1. A "malicious" user could upload any image with the exact title Test image, and when the article containing the wiki link is next rendered, it'll link to that "malicious" image because it has the exact title requested in the wiki link.
  2. A "malicious" user could upload any image with any title that is a case-insensitive variation, but doesn't conflict with existing image, for example an image with the title test image or test Image or TEST IMAGE, and now because two case-insensitive variations exist, we don't know which one is intended, so the link will be broken when rendered.

Conclusions

So we can't allow case-insensitive fall-backs for images and articles. it just opens a Pandora's box of problems.

The case-insensitivity worked when we were using MySQL because it was baked into the database collation. If someone tried to upload an image Test Image when an image titled test image already existed, you'd get a database conflict. Since we're now using Postgres with its default case-sensitive collation, someone can upload images titled Test Image and Test image without a problem, because they differ in case, and because of that, I think we have to remain consistent and insist on exact titles in wiki links.

So, I'm thinking the best way forward might be to keep things the way they are -- exact title matches are required -- and then provide one or all of the following:

• If when rendering a wiki link, we don't find an exact match, but find one or more case-insensitive matches, instead of providing a link to create a new article or showing a message that the image doesn't exist, for both articles and images we show a message saying that the requested title doesn't exist, but did they instead intend one of the case-insensitive title matches we found.
• Perhaps create a new tool or dashboard, that finds and reports broken links in all articles, and notes the ones with case-insensitive matches.