Page MenuHomePhabricator

Plans: 2018 Week 10 Bonus Content
Closed, ResolvedPublic

Description

See T13096. An install is experiencing a cluster synchronization issue on one node, but the immediate symptom is a held lock.

See PHI410. See PHI348. Multiple installs would like API access to the commit which closes a revision.

See PHI417. An install would like to contextualize the "landed irresponsibly" stories from feed. (I plan to just hide these, there's just a bit of a technical trick which makes it non-trivial.)

Entering MFA credentials during an OAuth server redirect workflow can currently be blocked by the CSP.

See T13100. See support@ email thread about being unable to edit a revision. This is PCRE shenanigans.

See PHI423. An install would like T11015 fixed properly. PHI254 also touches on this.

See PHI424. Another install would like T11664 and I think we have enough interest in this now to just bite the bullet.

It would be nice to fix T12590 alongside the other Owners changes.

See T13101. See https://discourse.phabricator-community.org/t/meme-remarkup-tag-no-longer-working-after-upgrading-to-2018-w09/1210. The {meme ...} Remarkup composer currently violates the Content-Security-Policy if a CDN domain is configured. The {img ...} imageproxy rule also violates the Content-Security-Policy for similar reasons. See also PHI437, sort of.

See PHI432. An install would like to query repositories by short name.

See PHI434. The "Strip MFA" workflow in the cluster doesn't properly dirty the user enrollment cache. This is a Phacility-specific issue with our instance management toolset.

Event Timeline

epriestley triaged this task as Normal priority.Mar 5 2018, 3:20 PM
epriestley created this task.

PHI410 and PHI348 are both related to Differential's TYPE_UPDATE transaction. This is essentially the only Differential transaction which has not moved to ModularTransactions.

Actually, neither cares about TYPE_UPDATE -- they both care about the "close", but I'm most of the way through the TYPE_UPDATE change anyway so uhhh I've learned an important lesson about reading?

Entering MFA credentials during an OAuth server redirect workflow can currently be blocked by the CSP.

This is kind of a mess. The flow here is:

  • You visit turtle.phacility.com while logged out.
  • This redirects you to admin.phacility.com and you get a login screen.
  • You login, then you get sent to an MFA form.
  • You submit the MFA form.
  • We try to redirect you back to turtle.phacility.com.

Firefox and Safari are fine with this. Chrome, only, is not. Chrome requires any redirect destination after form submission to adhere to the form-action policy.

Chrome's behavior doesn't immediately make sense to me, and Mozilla's documentation warns about this and points at https://github.com/w3c/webappsec-csp/issues/8.

The easiest fix here is probably to just return an interstitial. Given the way this works, the MFA form currently has no clue that you're going to be redirected by OAuth when it renders, so we can't easily guess that the CSP needs the OAuth destination. We could parse the next cookie and see if it's /oauth/server/... but that feels unbelievably fragile.

The easiest fix here is probably to just return an interstitial.

This is now live and seems to be working.

epriestley updated the task description. (Show Details)

That's probably it for promoting this week, see T13102 for next week.