May 26 2016

The only thing that makes me sad about this is that it would mean that wikitech remains an LDAPAuth wiki indefinitely blocking my desire to convert it to part of the normal SUL wiki family when we have all of the OpenStack features migrated to Horizon or other related systems. (And yes I know that LDAP is used for more than OpenStack.) I would personally be more excited about consolidating the validation in https://www.linotp.org or something similar.

May 24 2016

If you decide to go with the crypto cookie, I'd recommend using a JWT, with either an HS256 or ES256 signature. It's url-safe encoded so unlikely to get corrupted, and there are plenty of libraries out there so you don't have to try and get it right yourself.

May 18 2016

OATH has been rolled out to testwiki and test2wiki. Everything seems to be working as expected. Assuming no issues come up, I'll make it available on all wikis (to Staff global group only) tomorrow in SWAT.

May 17 2016

@Tobi_WMDE_SW, we'll try to work it in, but since we didn't schedule it at the beginning of the quarter, we have a lot of other reviews already scheduled-- we're fully booked between now and the end of the quarter. So unless an anticipated project isn't ready for review, it will likely be at the beginning of July.

The css in article.createImgThumbnail is constructed as 'url(' + url + ')', but article.createThumbnail prevents \, ', and " in the url. So either createThumbnail should filter )'s, or createImgThumbnail should put the url into a quoted string.

Wouldn't the settings cookies kill caching anyway? Or is that rigged up to cache-vary on the specific cookie values without forcing things through to the backend? (Eg, if I'm an anon user with images disabled, beta on, and font size bumped up, are my pages still cached?) Or are we thinking of optimizing the case where someone clicks on settings and then never does anything with it?

We can potentially avoid session inflation by creating the session separately from creating the edit html (which would indeed allow session inflation if an attacker requests edit urls repeatedly without cookies enabled). For example, we could start the session from JavaScript on the edit page in a background request (AJAX).

@dpatrick / @Bawolff / @MaxSem - All those patches are deployed now. Can you all make sure you have 'SECURITY: ' at the start of the commit summary? Makes it easier to see on the cluster what's been added on top of master when deploying, and probably good to be consistent when we push these into master.