Open hickford opened 8 months ago
@mminns Can you reproduce this?
FWIW the OAuth spec recommends to use https://datatracker.ietf.org/doc/html/rfc8252#section-8.3 recommends to use 127.0.0.1 instead of localhost:
While redirect URIs using localhost (i.e., "http://localhost:{port}/{path}") function similarly to loopback IP redirects described in Section 7.3, the use of localhost is NOT RECOMMENDED. Specifying a redirect URI with the loopback IP literal rather than localhost avoids inadvertently listening on network interfaces other than the loopback interface. It is also less susceptible to client-side firewalls and misconfigured host name resolution on the user's device.
And the server should allow any port to match loopback redirect URIs:
The authorization server MUST allow any port to be specified at the time of the request for loopback IP redirect URIs, to accommodate clients that obtain an available ephemeral port from the operating system at the time of the request.
You should be able to disable that check using a system property, e.g.
-Datlassian.oauth2.provider.skip.redirect.url.https.requirement=true
Looks like that is missing from the documentation
// Check if an entry already exists in the keychain int findResult = SecKeychainFindGenericPassword( IntPtr.Zero, serviceNameLength, serviceName, accountLength, account, out uint passwordDataLength, out passwordData, out itemRef);
switch (findResult) { // Update existing entry only if the password/secret is different case OK when !InteropUtils.AreEqual(secretBytes, passwordData, passwordDataLength): ThrowIfError( SecKeychainItemModifyAttributesAndData(itemRef, IntPtr.Zero, (uint) secretBytes.Length, secretBytes), "Could not update existing item" ); break;
@mminns It's expected that OAuth native apps use http scheme for 127.0.0.1 https://datatracker.ietf.org/doc/html/rfc8252
Loopback redirect URIs use the "http" scheme are constructed with the loopback IP literal and whatever port the client is listening on. That is, "http://127.0.0.1:{port}/{path}" for IPv4, and "http://[::1]:{port}/{path}" for IPv6
Bitbucket ought to support this without special configuration. Any plans to fix this?
@hickford Not that I am aware of.
I'm not involved in day to day Bitbucket/Git development at Atlassian anymore, but I can see what I can find out.
@hickford did you find a way to get this working ?
We tried setting this, but bitbucket still refuses the https entry
atlassian.oauth2.provider.skip.redirect.url.https.requirement=true
Perhaps as a workaround, make the credential plugin start up an ssl enabled callback endpoint ?
My colleague followed the Bitbucket Server instructions at https://github.com/git-ecosystem/git-credential-manager/blob/release/docs/bitbucket-development.md#oauth2-configuration setting
But got an error:
This is using Atlassian Bitbucket v7.21.18.