🔊 Store token validation errors in the database and display them in the admin dashboard

[shankari]

For pre-generated tokens, one of the biggest issues is when the tokens don't work.
This can be either because the token is malformed on the phone, or when the token is properly formatted, but is not found among the valid tokens on the server.

To make it easier for admins to debug these issues themselves, I propose the following:

• we store the errors are stats/client_error messages, possibly with name = malformed_opcode or opcode_not_found
• we display the token errors in the admin dashboard so that admins can see the root cause
• extra credit: we try to match the opcode_not_found opcodes to valid opcodes and suggest some potential matches, so admins can easily help participants troubleshoot what is going on

While handling this we should also double check the client code to make sure that each malformed case is recorded properly - e.g. distinguish between the cases in if (tokenParts.length < 3 || tokenParts.some((part) => part == '')) {

@JGreenlee for visibility

[shankari]

FYI, here's the script that I used to identify opcodes with two underscores for ca-ebike

>>> all_opcodes = open("nrelop_ca-ebike_default_tokens.txt").readlines()           
>>> invalid_opcodes = [o for o in all_opcodes if "default__" in o]
>>> len(invalid_opcodes)
3124
>>> open("/tmp/invalid_opcodes.txt", "w").writelines(invalid_opcodes)

[shankari]

we store the errors are stats/client_error messages, possibly with name = malformed_opcode or opcode_not_found

As I think about this further, I don't think that the malformed_opcode option will work because even if we store it locally, it won't get pushed to the server unless the user logs in successfully. We just have to be a lot more explicit about the reason for the malformed opcode in the error message that we show to the user such that they can debug it themselves, or send a meaningful screenshot.

[shankari]

Ah actually it looks like having a __ anywhere fails because we don't just check if the important parts are blank but if any part is blank

> const token = "nrelop_study_subgroup_a__b"
< undefined
> const tokenParts = token.split('_');
< undefined
> tokenParts.length < 3
< false
> tokenParts.some((part) => part == '')
< true
> tokenParts
< ["nrelop", "study", "subgroup", "a", "", "b"] (6)

So the invalid opcode filter is actually

>>> all_opcodes = open("nrelop_ca-ebike_default_tokens.txt").readlines()           
>>> invalid_opcodes = [o for o in all_opcodes if "__" in o]
>>> len(invalid_opcodes)
5012
>>> open("/tmp/invalid_opcodes.txt", "w").writelines(invalid_opcodes)

[JGreenlee]

I have previously observed the difference in the charset between phone-generated and script-generated opcodes
The random string generation method on the phone yields only alphanumeric characters:
https://github.com/e-mission/e-mission-phone/blob/89127bca0ae3f4074ab1fc9d7be0581ad62ea24f/www/js/config/opcode.ts#L9-L16

We should unify the script to behave the same, and potentially relocate both versions to e-mission-common