hasgeek / funnel / 6970
58%

DEFAULT BRANCH: master
Ran
Jobs 1
Files 93
Run time 8s
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst
6970

push

travis-ci

web-flow 
Don't allow case change in `EmailAddress.add` (only in `add_for`) (#801)

This patch exposes a vulnerability in the design of the `EmailAddress` model. Since the email address is only stored here and not in any of the other linked models (`UserEmail`, etc), there can only be one case-preserving representation of it. This is normally not a problem when email addresses are limited to a specific user account. It breaks down when an email can be used in two separate user accounts. Examples of how this can happen:

1. `UserEmailClaim`
2. Future mailing list functionality

Take the first:

1. Rogue User claims an email address, giving it an unusual case (say, randomly capitalized letters)
2. Real User claims the same email address. The existing case representation in the db will not be amended, so the will get the weird casing as well.
3. Real User happened to be the real owner and confirmed ownership, so it gets added to their account as a UserEmail object, but preserves the weird casing acquired from Rogue User.
4. Real User can't change the case in the UI. If they remove and re-add the email, they can use use any casing they like, but if it was their only contact detail, the UI won't allow removing.

In the second case, a mailing list entry will affect the casing of a future user's email address, and does not even require a rogue user, just someone using the functionality as intended. It also works in reverse: if the owner changes casing, it will reflect in mailing lists owned by others.

Should we ever implement a mailing list (there's a half-baked version in the [listman](/hasgeek/listman) project, which was was meant to add mailing list functionality to [hasmail](/hasgeek/hasmail)), we have to ensure the list entry's `email` column is a case-preserving dupe of the `EmailAddress.email` column. This will be a setback from the goal of having a single point of storage for email addresses, and will require coordination between models for thin... (continued)

5029 of 9267 relevant lines covered (54.27%)

0.54 hits per line

Jobs
ID Job ID Ran Files Coverage
1 6970.1 (PGVER=12 PGPORT=5433) 0
54.27
 Travis Job 6970.1
Source Files on build 6970
Detailed source file information is not available for this build.