At time of writing, calls to rest/api/3/myself now return this:
Sep 4 2020
May 13 2020
Apr 25 2020
At time of writing, calls to rest/auth/1/session return a result like this:
Apr 24 2020
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-.
Feb 24 2020
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.
Feb 23 2020
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):
Feb 22 2020
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).
Feb 21 2020
Feb 20 2020
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.
Feb 19 2020
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.
Feb 4 2020
The actual replacement is Authorization: token <token>, I believe:
Jan 30 2020
I think D20905 is as good as we're going to get.
Jan 15 2020
These changes seem to have stuck.
Nov 13 2019
On Ubuntu 14, the messages are a little less helpful:
Nov 11 2019
Nov 8 2019
This may also impact the Doorkeeper integration, which reads "id" fields from a few calls.
Oct 28 2019
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.
Oct 25 2019
Sep 24 2019
Sep 19 2019
Sep 18 2019
Sep 5 2019
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. 🤷
Aug 29 2019
Aug 7 2019
This thread suggests that some version of ssh-keygen is sensitive to trailing whitespace in private keys:
Jul 24 2019
Everything has made it to master now so I suspect we're in good shape here.
Jul 19 2019
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:
Jul 18 2019
Rough intentions here:
Jul 17 2019
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.
Jul 15 2019
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.