What is the problem? Please be detailed.
ODK Central Administrator sets up my account
I receive the:An account has been provisioned for you on an ODK Central data collection server email
Click link
Taken to screen prompting me for new password
Enter a password
Error "Could not authenticate with the provided credentials"
(build.js:5 POST https://odk-survey.lshtm.ac.uk/api/v1/users/reset/verify 401 (Unauthorized))
I think to myself maybe I already have an account as we had an earlier version of ODK Central testing
Go to login page for existing users
Click reset password link
Enter the email to which my invite has been sent
Receive email saying:
A password reset has been requested for this email address, but no account exists with this address.
What ODK tool and version are you using? And on what device and operating system version?
ODK Central Beta
Attempting login Chrome, Windows 10
So essentially I don't appear to be able to set a new password from my invitation but it doesnt appear to be because I have an existing account because if it was I should be able to reset that password
My suspicion is that the email link has expired. I think it says in the email that there's a time limit but we should make the error messaging better. I've filed a ticket for that here.
Usernames are indeed case sensitive.
User deletion is indeed missing at the moment. We have plans to add that soon.
1)Link didn't work within 5 minutes of receiving it
Email addresses aren't case sensitive so that's a bit frustrating when an email is set as a username - especially as you now invite people via email - if I sent the invite to Clint@lshtm.ac.uk youll get the invite but the process won't work if your email is truly clint@lshtm.ac.uk)
Hm. I did some Googling just now and it seems like email addresses are case-sensitive, so I'm somewhat reluctant to change that behaviour. But if others feel strongly about this I can amend it.
As for the link not working, I'm not sure what would be going on. Can you try/have you tried it one more time just to see if that does it?
2.4. General Syntax Principles and Transaction Model
...
The local-part of a mailbox MUST BE treated as case sensitive.
Therefore, SMTP implementations MUST take care to preserve the case
of mailbox local-parts. In particular, for some hosts, the user
"smith" is different from the user "Smith". However, exploiting the
case sensitivity of mailbox local-parts impedes interoperability and
is discouraged. Mailbox domains follow normal DNS rules and are
hence not case sensitive.
Which is to say, the username part is case-sensitive, but the rest (ie hostname) isnt. So I would agree with @issa - it would not be prudent to treat all emails as necessarily case-insensitive.
Well all I can say as an end user is I have never experienced a case sensitive email.
For example I've emailed myself using
Michael.rest of email
michael.rest of email
mIchAel.rest of email
All the emails come through suggesting no case sensitivity
It seems to me from reading stack overflow that although in principle the local component can be made to be case sensitive no commonly used email software actually does this - i.e for the user the experience is almost universally that email addresses are not case sensitive
Putting my 'Spec' hat on, my only response can be: "The official IETF/W3C/... specification is Gospel"
But taking it off, I will happily admit that.... "I must defer all deliberate, pragmatic, spec violations to the ODK PMC/TSC (@LN in particular)"...
BTW, I just did a simple test, and neither Yahoo mail nor Gmail appear to be case-sensitive when it comes to the username. Feel free to exploit this knowledge to your advantage...
For example the admin creates at account for
Michael.rest of email
I try logging in with
michael.rest of email
It doesn't work. The average user has never experienced case sensitivity when using their email. It took me and my systems admin an hour of playing around to figure this out and in the end we had to make a new account all lower case as that is how chrome for example autopopulates fields with my email in - and also how I type it.
I certainly understand the pain-point. But in all seriousness, decisions that amount to choosing to knowingly violate documented Internet standards - because in all reality they are ostensibly meaningless now because everybody else is already violating them (ie, portions of RFC5321 are now bogus for all practical purposes), and continuing to enforce them is causing ODK users a lot of pain - probably ultimately needs to be made at the ODK TSC level.
My concern is that:
moving from case-sensitive to case-insensitive (ie more-to-less restrictive) is a bit of a one-way street. You cant decide later to change your mind without break a whole lota (now) legacy stuff...
if you do it, you need to do it right all across the board. Which means determining everything that might be affected; ie any code that deals with emails needs to be checked to make sure its case-insensitive.
Okay, I randomly sampled a few popular services and they all seem to accept case-insensitive email addresses for login. So I think I am inclined to soften this restriction.
I appreciate the argument for rigor, @Xiphware, and you'll often often see me making that argument (particular when complaining about the OpenRosa spec) but I think in this case convention already cuts the other way and it's pretty inarguably a softer experience.
I've filed a ticket here and I might even work on it right this moment. Thanks for the report and suggestion, @dr_michaelmarks!
There's a good article about 'standards' from the Journal of Electronic Publishing. I note:
A standard, of any form or type, represents a statement by its authors, who believe that their work will be understood, accepted, and implemented by the market. This belief is tempered by the understanding that the market will work in its own best interests, even if they do not coincide with the standard.
