Passwords created by selecting characters in larger character sets (with extended ASCII and many symbols) are accepted in the web application but not in Kobo Collect (version 2020.1.2)
Use that same password in the corresponding project setting in Kobo Collect
Try to fetch blank forms
Expected behavior
Two possibilities:
the list of available blank forms appears in Kobo Collect, or
the characters that will not be accepted in Kobo Collect should be rejected at form validation phase in the web application, when setting or modifying the password.
Actual behavior
Modal window with error message (translated from my French GUI): “The user name and/or the password is incorrect for the server: https//kc.humanitarianresponse.info”, the two fields prompting for new user name and password.
In the web application, no error message appears when setting the password “&HÈS½:«7e>(,'z” (without the initial and final quotes) and the password is recorded and used.
Additional details
With simpler passwords only made of letters and digits, everything works well with the same user name and URL.
@freedim, it seems you are using a password key (½) not visible on the keyboard. Could you try it with the keys that are present on the keyboard? Maybe that should solve your issue.
Precisely. As I mentioned in the last section of my OP, it does work with simpler passwords.
The point is that if a key will not be accepted in KoBo Collect, it shouldn’t be accepted in the web app either.
Better: there should be some documentation or error message indicating which characters are accepted or not.
Ideally: all characters should be accepted by both the web app and KoBo Collect (except maybe one or two in order to prevent code injection)
Some context
In my case, I manage 300+ passwords, so I delegate this task to a password manager, whose default settings are meant to maximise security by generating passwords using all kinds of weird characters.
It works with my 300+ accounts except maybe 2 or 3 glitches where I have to waste time figuring out what is going wrong. I wish KoBo was not one of these 2 or 3 exceptions. With the main new advertised URL not working (see my other bug report about eu.kobotoolbox.org), it actually took me a couple of hours to figure out there was a charset problem in the password present only on the Android side.
I tried using a debugging tool to paste your example password &HÈS½:«7e>(,'z into the username field, where I could see the results, and I was surprised to see that Android silently ignored some of the characters. Could you please try instructing your password manager as well to type the string into a visible field to confirm that all characters pass through? If they do, then please share the specific password manager software you use to facilitate further troubleshooting.
Whoops, I actually reproduced the issue by transferring the password another way—and remembering that one of two places where Collect prompts for a password actually does show the string in plain text.
I agree with you and would prefer the “ideally” option. We don’t rely on excluding characters to prevent code injection: there’s proper escaping for this. Still, given the practical limits of funding and developer time, the best we will likely be able to do in the foreseeable future is your “better” option to document this limitation. Here is an issue for us to track doing that: Document that Collect does not support certain password characters · Issue #347 · kobotoolbox/docs · GitHub
