8000 Case-Insensitivity for casebook collaboration invitations · Issue #1363 · harvard-lil/h2o · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Case-Insensitivity for casebook collaboration invitations #1363

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
holtchesley opened this issue May 27, 2021 · 2 comments
Closed

Case-Insensitivity for casebook collaboration invitations #1363

holtchesley opened this issue May 27, 2021 · 2 comments
Labels
collaboration

Comments

@holtchesley
Copy link
Contributor

There's some roughness around case sensitive usernames in collaborator invites. Smooth this out, possibly by making it easy to merge accounts.
@lizadaly
Copy link
Contributor
lizadaly commented Jul 5, 2022

Though email addresses today are almost universally case-insensitive throughout, according to the RFC the username portion of the address is case-sensitive, and Django enforces this.

However, in all practical cases, email addresses are treated as case-insensitive these days and for an app of our scope, I think it's safe to follow common practice rather the original RFC.

There is a complicated "correct" solution involving switching the email address field type to the Postgres-only CIText type, which does case-insensitive retrieval, but that involves enabling extensions on the Postgres side and I think is just not worth the risk and complexity.

Depending on the most common actual use case we can mitigate this a few ways:

  • If we think the primary problem is people creating invites in mixed case but the invitee attempting to log in with lower case, we can force lower case all new collaborator invitations. This will make all invitations going forward lowercase-only.

  • We could do a case insensitive search for existing accounts in the Invite form to avoid creating duplicate accounts with different cases. This should be safe to do.

  • Newly-invited collaborators hit the reset-password flow first, to set their password. They aren't actually shown which email address was used because normally in this flow the user has already entered their own email. If they're the kind of person who forwards send multiple addresses to the same mailbox, they won't know which address was used without carefully inspecting the invite. This is the same problem as differing case, but probably harder to handle via support. I don't know how common this is.

  • If we think it's safe to ignore the spec and assume all email addresses should be case-insensitive, we could do a mass data migration to downcase all addresses, then make all login forms case-insensitive. I think this is probably also overly aggressive.

My recommendation is to do the first two items, which should do little harm, and also generate a small report on how many mixed-case email addresses we have. It may also help to give users following the reset password flow the opportunity to update their email address.

lizadaly added a commit to lizadaly/h2o that referenced this issue Jul 5, 2022
@lizadaly
[harvard-lil#1363] Check case-insensitively for existing collaborator…
3ef37bc 
…s before creating new accounts
lizadaly added a commit to lizadaly/h2o that referenced this issue Jul 5, 2022
@lizadaly
[harvard-lil#1363] Check case-insensitively for existing collaborator…
de0e8a0 
…s before creating new accounts
@lizadaly lizadaly mentioned this issue Jul 5, 2022
Merged
lizadaly added a commit that referenced this issue Jul 13, 2022
@lizadaly
Merge pull request #1592 from lizadaly/downcase-collaboration-emails
2e09ec9 
[#1363] Check case-insensitively for existing collaborators before creating new accounts
@lizadaly
Copy link
Contributor
lizadaly commented Jul 13, 2022 •
edited
Loading

We're doing a case-insensitive check at invitation time now, but @cath9 and I agree we should just go ahead and force-lower all new incoming email addresses at account creation. If someone tries to log in with mixed case that'll fail unless we also lower-cased all existing legacy addresses first. Given the number of accounts I think it's probably fine to just handle those as needed.

@lizadaly lizadaly mentioned this issue Jul 13, 2022
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
collaboration
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@lizadaly @holtchesley
0