At time of writing, calls to rest/api/3/myself now return this:

At time of writing, calls to rest/auth/1/session return a result like this:

See private correspondence ("Re: Contributing / Jira Oauth Patch"), which suggests the call to rest/auth/1/session should be (and may urgently need to be) replaced with a call to rest/api/2/myself. See also https://developer.atlassian.com/cloud/jira/platform/deprecation-notice-basic-auth-and-cookie-based-auth/#which-apis-and-methods-will-be-restricted-.

Couple of notes on the state of affairs here:

As of early 2020, this change works:

JIRA did this (changed how accounts are identified) again recently (key is now accountId), see T13493.

I landed everything so far to master. The new behavior in master should be:

I stumbled across what appears to be a very mild security issue in JIRA that impacts this flow. I've reported it to Atlassian's bug bounty program here (this link may or may not be visible to anyone else):

This change sequence is almost ready to remove readers and writers to accountID, but there's still a unique <accountType, accountDomain, accountID> key on the table. Removing accountID writers completely will mean that the second user to link an account of a particular type (say, an Asana account) will run into a unique key error (since they'll write a second "Asana" account with the same empty accountID as the first "Asana" account).

These callers use accountId:

I think the patch above is a piece of the solution here, but makes behavior worse for some installs: installs with a version of JIRA which returns both key and accountId will have worse behavior under the patch than without it (since it will break all the existing account links immediately). It also doesn't smoothly migrate these installs, even though it's theoretically easy/desirable to do that.

When a user logs in to "new" JIRA, we also can't easily tell if they have an existing account link based on the presence of an accountId.

The actual replacement is Authorization: token <token>, I believe:

I think D20905 is as good as we're going to get.

These changes seem to have stuck.

On Ubuntu 14, the messages are a little less helpful:

This may also impact the Doorkeeper integration, which reads "id" fields from a few calls.

Agreed that supporting YubiKey OTP is pointless - it's impractical and basically a dead legacy feature at this point. WebAuthn has emerged as the de-facto standard for hardware tokens.

But did you check your spam folder? 😄

But did you check your spam folder? 😄

I attempted to register for a developer account and am receiving neither an email verification email nor a password reset email. 🤷

This thread suggests that some version of ssh-keygen is sensitive to trailing whitespace in private keys:

Everything has made it to master now so I suspect we're in good shape here.

Not all of this has landed yet, but once it does:

It may be useful to provide helper methods to support normalizing these actor types (e.g., email addresses should be case-insensitive).

Another general note is that we also require users go through this flow if they're setting a password for the first time on an account which does not already have a password. For example, this workflow will set up the "set your own password" flow:

Rough intentions here:

Potentially don't allow the "Send a login link to your email address" action at all if the corresponding Phab account is already only linked to external accounts for authentication and the installation does not use passwords? But I might lack technical understanding here.

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.