Opened 12 years ago

Last modified 9 years ago

#262 new enhancement

Mangle locker names that are invalid hostnames and MySQL usernames

Reported by: andersk Owned by:
Priority: major Milestone:
Component: internals Keywords:
Cc:

Description

Certain locker names don’t entirely work with scripts:

  • #106: The *.scripts.mit.edu certificate doesn’t cover lockers with . in their name (and this is a fundamental limitation imposed by the RFC).
  • #171: Lockers with _ in their name don’t always work since _ is an invalid character in hostnames. (In practice, many browsers accept internal _s but not an initial or final _.)
  • #176: MySQL limits usernames to 16 characters on both the server and the client, so lockers with longer names can’t use sql.mit.edu.

I proposed the following solution (see -c scripts -i 1621864 from 2011-06-09):

  1. Try to get a guarantee from accounts/Moira that locker names will remain unique under lambda name: re.sub('[^A-Za-z0-9]', '-', name)[:16].
  2. Use re.sub('[^A-Za-z0-9]', '-', name) as your scripts vhost name.
  3. Use re.sub('[^A-Za-z0-9]', '-', name)[:16] as your sql username.

So 2.007 gets 2-007.scripts.mit.edu, mats_a gets mats-a.scripts.mit.edu, and stupidlylonglocker gets to use sql.mit.edu as stupidlylonglock. We want a guarantee that nobody else gets lockers like 2_007 or mats.a or stupidlylonglockup. (Note that 2007 is not a conflict, unlike with the current sql.mit.edu mangling scheme which simply deletes periods.)

Change History (7)

comment:1 Changed 12 years ago by andersk

This doesn’t fix the https://www.ksplicethesoftware.jbarnold.scripts.mit.edu/ case of #106, but I don’t know of anyone using HTTPS with such URLs. (We can fix them as needed with reification or whatever replaces reification.)

I think we’ve determined that the only currently conflicting lockers under the proposed scheme are mit-whoi/mit_whoi.

comment:2 Changed 12 years ago by andersk

Hmm, what were we going to do about locker names with leading or trailing punctuation? We’re aware of some users with trailing underscores, and user-.scripts.mit.edu is just as invalid as user_.scripts.mit.edu.

comment:3 follow-up: Changed 12 years ago by andersk

I guess assuming that no current lockers match [^A-Za-z0-9][^A-Za-z0-9]x$, we could transform user- to user--x (and user-- to user---x, etc.), and ask for an additional guarantee that no future lockers match [^A-Za-z0-9][^A-Za-z0-9]x$.

comment:4 in reply to: ↑ 3 Changed 12 years ago by andersk

Replying to andersk:

I guess assuming that no current lockers match [^A-Za-z0-9][^A-Za-z0-9]x$, we could transform user- to user--x (and user-- to user---x, etc.), and ask for an additional guarantee that no future lockers match [^A-Za-z0-9][^A-Za-z0-9]x$.

I realized at some point, but forgot to comment, that appending -x to every locker name matching [^A-Za-z0-9]([^A-Za-z0-9]x)*$ (e.g. user-user--x, user--xuser--x-x, …) would make that additional guarantee unnecessary.

comment:5 Changed 11 years ago by andersk

Because #106, do we want to support say jbarnold getting https://ksplicethesoftware--jbarnold.scripts.mit.edu or https://jbarnold--ksplicethesoftware.scripts.mit.edu? We’d then need to modify the escaping scheme so that -- never shows up otherwise, perhaps by encoding -----, -------, ….

(Also, hmm, I guess we should make sure not to do something stupid to IDNs.)

comment:6 Changed 9 years ago by geofft

What's the current status of this? (It's a prereq of #17.)

I vaguely recall we'd asked about locker name restrictions, but I can't find that email now; did we?

Is #106 interesting any more now that we get free, globally-valid certificates? We can just get a cert for https://www.ksplicethesoftware.jbarnold.scripts.mit.edu/ upon request, and it's as valid the wildcard. (We could do this automatically, if we figure out #397.)

And, if that's no longer a reason to care, is name-mangling a better proposal for #171 than the one described in #171 (namely, just asking people to get *.mit.edu hostnames for themselves)? https://6.001.scripts.mit.edu/ doesn't need to be https://6-001.scripts.mit.edu/ and more, and if my username were geofft_, I'd be unlikely to want to tell anyone to visit https://geofft--x.scripts.mit.edu/.

(There's still the issue of what happens if someone registers the locker "001", which was not explicitly discussed in any of these tickets.)

comment:7 Changed 9 years ago by andersk

Certificates are not free in terms of time. Even if we manage to automate everything on our end, users will still have to wait for hours or days. (And that’s to say nothing of the hassle of managing all those renewals.)

*.mit.edu hostnames have the same problem, as well as the problem that autoinstallers can’t install directly to them.

Note: See TracTickets for help on using tickets.