Yeah -- I lean toward thinking that we probably should make bin/auth lock also lock the guidance messages too.
Aug 13 2019
Jul 24 2019
Jul 22 2019
Jul 19 2019
Are we worried about attackers changing the guidance to something like "To prove that your Phabricator account is in use, please email the following link to firstname.lastname@example.org and don't read the rest of this email"?
Jul 18 2019
Jul 17 2019
Jul 15 2019
Am I going crazy, or do those methods only handle the "blob fetching" part of this equation? I was looking for examples of the "create a File, do a chunked upload, attach said File to an existing object" flow.
For uploading binary blobs, we'd do the reverse: have the client stream the blob into Files, then call an API method with a reference to the object.
Pop a dialog instead of navigating away.
Jul 12 2019
Jul 11 2019
- Raise "editing while locked" errors in the transaction layer.
- Changed controllers to catch errors and display them reasonably.
- Warn users about locked config when editing existing provider:
- When trying to save a provider when the config gets locked during an edit, show reasonable error:
Jul 10 2019
Gate auto-login and trust emails.
I was also looking for a way to still render the form, except with all the fields grayed out, since it isn't terribly user-friendly to make someone unlock the config just to see what it already says. This seems tricky though, since there's no AphrontFormView->getChildren() method I can iterate over to call setDisable(true) on.
Jul 9 2019
Jul 5 2019
Jul 4 2019
Thanks for the report. Fixed in D20642, which may or may not land today because of the holiday.
But we could also do it later.
Jul 3 2019
Jul 2 2019
It's turtles all the way down. Computers don't work and all conventions and toolsets are fundamentally broken:
Jun 29 2019
Jun 28 2019
Jun 26 2019
cd provides "at least once" delivery guarantees.
Jun 25 2019
Oh, and this might be useful, but is probably less portable than just using ps.
- The disk can be full, or read-only. Or become full later, including while the daemon is running.
- Any of these policy/disk state problems can pass any effort we make to test them early, then fail after the process daemonizes, making it difficult to report the failure to the user.
This whole series of changes is motivated by "a PID file was out of date because of a reboot, and we tried to kill some other random process", right? Was there anything else that PID file tracking wasn't doing correctly?