Oh, sorry, I misread which half you were asking about.

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.

Yeah, diffusion.rawdiffquery and diffusion.filecontentquery both do this.

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.

Deprecate conduit sessions and conduit.connect.
Support direct token-based auth (?token=abdef123) and make this the standard.

Support multiple request encodings (likely BSON, protobuf, or messagepack). Leave JSON as the default, but in cases where messages can not be represented in JSON this gives us a plausible way forward.

This could be made slightly cleaner with a setSummary() to set a shorter summary:

hmmmmmm

I'll update the documentation/setup guidance in the upstream.

Great! Thanks for the report, and for your help tracking this down by going through the diagnostic steps.

https://phabricator.example.com/debug/?a=b returns:

I can't immediately reproduce this: I can log into my local development install and into secure.phabricator.com using Google OAuth without any issues right now.

I thought rPHU4d21f105b17f250aaaeb8937142ae4cbc978389f was meant to fix this, but apparently not.

For Phacility impact on the ExternalAccount changes so far, these callsites don't seem impacted yet (but might be worth keeping in mind in the future):

I think there's not much actionable here and this has all more or less resolved:

I'm going to dump everything I've got into master now that T13250 is mostly stabilized so it at least gets a couple of days of testing. I don't think I'm breaking anything in rP, but instances/ may require changes to instance initialization before this stuff can deploy.

Legalpad uses ExternalAccount to store arbitrary email addresses as an identity.

(Misfire in the plain text of D20105.)

This task is kind of all over the place, but I expect it to be functionally resolved by changes attached to T13244 in service of (internal) PHI774.

I've marked D20106 as resolving this. Although all possible permutations of this situation aren't completely fixed, I believe we've added enough tools that this situation can be resolved by clicking a couple of things, and usually resolved by users without administrator intervention:

Here are some general technical blockers here:

@epriestley Sorry bringing up this ancient task. I am also interested in this Azure OAuth feature. Would you kindly point me to some third-party extension coding guideline/documents? I've dug around for the docs, but not found any.

After T13222, this is more relevant:

For now, I'm continuing to allow users to "Remove" the last active factor on their account when security.require-multi-factor-auth is enabled. This will kick them to the MFA enrollment screen.

I think I have this working fairly reasonably, now. There are four major cases:

In T13231#243710, @epriestley wrote:

Another issue here is that Duo doesn't seem to have a way to prevent new user creation. YIf you /preauth a user, they get an enroll link whether they already have an account in Duo or not, and there's no apparent way to distinguish between "this creates a new user" and "this encourages an existing user, who has already been created but has not enrolled a device yet, to enroll".

Another issue is that we apparently (???) only get one shot at learning the user's (internal-to-Duo) User ID, and only if we're allowed to enroll them. The first call to /enroll gives us a user ID, subsequent calls do not and there's no other way to do the lookup. This isn't really a problem, it just means we're forced to use usernames everywhere (which are mutable/aliasable/etc/etc) when we could otherwise use nice stable user IDs.

Another issue here is that Duo doesn't seem to have a way to prevent new user creation. If you /preauth a user, they get an enroll link whether they already have an account in Duo or not, and there's no apparent way to distinguish between "this creates a new user" and "this encourages an existing user, who has already been created but has not enrolled a device yet, to enroll".

Thanks, that's quite helpful!

If we want to synchronize to existing accounts, I think it's not good enough for us to pick the user's email address unless that's also the username the organization already uses -- in your case, is it?

I'm imaging that one use case is that you just want everyone to use MFA, and Duo is a more attractive approach than TOTP (since it's easier to use) or SMS (since it's more secure). In this case, you might just be using Duo as "Better TOTP", and the enrollment/management side isn't as important. For example, if we deployed Duo on secure or in the Phacility cluster as a default option, we'd use it in this mode.

FWIW - most users of this feature (especially after T13229) will be organizations that already have DUO in their environment, and likely already have users defined in DUO. Creating random usernames, or PHID's is probably not going to work for most of those organizations. Phabricator does require email's to be unique (no reuse) so that might be a better choice for initial userid setting?

When you delete a Duo factor from your phone app, you still get prompted to "auth", Duo just reports that you have no enrolled devices which support push.