Address user-supplied CodeQL issues

[bjester]

Summary

Addresses most of code-oriented CodeQL issues shown in #5300 . Changes are similar to suggestions, but some are simplified. For the most part, the changes avoid injecting user supplied input into error messages, and thus the page responses. Cloudflare already blocks a lot of malicious inputs that would target these.

References

#5300

[marcellamaki]

So rather than the "proposed change" that uses regex and is kind of hard to read, we're just doing a simple check to confirm it's a UUID (and presumably a valid channel id or at least not malicious), otherwise erroring right?

[bjester]

Yes, that's right. The regex wasn't even right anyway, because g-z aren't valid in UUIDs. Using python shell, it's easy to confirm this behavior:

>>> import uuid
>>> uuid.UUID('dasfasd')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/bjester/Projects/learningequality/pyenv/versions/3.10.13/lib/python3.10/uuid.py", line 177, in __init__
    raise ValueError('badly formed hexadecimal UUID string')

[marcellamaki]

I have read through the code to confirm I understand it, and also cross referenced with the CodeQL issues and the changes here seem to align. I have less insight into whether or not there was anything else in the code QL comments that should be addressed that isn't covered here, and mostly am just deferring to Blaine's judgement. But, a second review from @akolson and/or @rtibbles would be helpful I think :)

[akolson]

Changes look correct to me and seem to address any potential injection as pointed out by Blaine! Thanks @bjester!

[rtibbles]

Yeah - most of the other CodeQL things raised were around setting appropriate permissions on github workflows. We need to do that comprehensively across all our actions on all repositories. It's lower priority because it could break things if we get it wrong, and there's not a huge risk of anything going awry if we don't do it just yet.