-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
bitbucket: remove 2FA test #743
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for jumping on this so quickly Mike! I've just got a couple questions.
@@ -156,28 +156,16 @@ private async Task<ICredential> GetRefreshedCredentials(Uri remoteUri, string us | |||
|
|||
switch (result.AuthenticationMode) | |||
{ | |||
case AuthenticationModes.Basic: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Probably a naive question, but what will happen here if the user still requires 2FA?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So what used to happen was:
The user would first be shown a Basic Auth dialog in the helper.
They would enter username/password which are returned from the dialog.
If they were using a URL that isn't bitbucket.org the username/password is not tested, simply passed back to the GCM app and then back to Git.
If they were using bitbucket.org host, then the username/password is tested by calling the REST API.
If it returns a 200 then the username/password is passed back to the GCM app and then back to Git.
If it returns a 403 it would show the OAuth dialog in the helper.
Anything else would throw an exception.
Removing this code, means the behaviour for Bitbucket.org is the same as for other URLs.
Users will now need to manually choose the OAuth option on the Basic Auth dialog, or force OAuth via credential.bitbucketAuthModes.
I was planning to provide a follow up PR to switch the default behaviour of the Helper dialog and make OAuth the first option, Users would then need to manually choose Basic Auth.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The problem here is that the user would not necessarily know the reason their username/password didn't work (because they need to auth via OAuth).
Might be worth only presenting the OAuth option for Cloud and only U/P for Server and DC.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
App Passwords will still work on Bitbucket.org with Basic Auth.
But I do think when the host is bitbucket.org the UI should be reversed to put OAuth first with the option to switch to Basic Auth and renaming "Basic Auth" to "App Password".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could also provide a link to the documentation referring to the removal of rights from the user's main u/p ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But I do think when the host is bitbucket.org the UI should be reversed to put OAuth first with the option to switch to Basic Auth and renaming "Basic Auth" to "App Password".
I think this is the right path forward - is this something you'd be able to take on?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed! This would be similar to the GitHub auth prompt then (show OAuth first - if possible, and switch to u/p/app pwd if poss)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is this something you'd be able to take on?
I can do. I can't make guarantees about deliver timescales unfortunately.
Do you want it addressed in this PR? I wouldn't really want to delay this fix too long.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, I think we can take this fix. Thank you, Mike!
} | ||
|
||
// Basic Auth 403-ed so push user through OAuth flow |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we actually want to remove this OAuth flow?
BitbucketHostProvider: fix runtime exceptions when authentication requests for Bitbucket DC would incorrectly call a Bitbucket Cloud REST API A bug was introduced in commit: 5a2cfd7. Prior to this only authentication requests for Bitbucket Cloud would try and automatically determine if 2FA was required by the current user by calling a Bitbucket Cloud REST API using user provided Basic Auth credentials Commit: 5a2cfd7 removed checking of the current host was Bitbucket Cloud vs DC. This meant the check would be run for Bitbucket Cloud and DC regardless. It would fail for Bitbucket DC The fix is more radical than simply re-instating the check on the type of Bitbucket host. From 1st March 2022 support for using a Bitbucket Cloud user's account password to access REST or Git HTTPS operations has been removed, https://atlassian.community/t5/x/x/ba-p/1948231. As such this automatic test to see if 2FA is required no longer works. Therefore the check against the Bitbucket Cloud REST API has been removed in its entirety
GitHub Actions seems to be a bit flaky at the moment? |
Yea. You hit an issue that we've increasingly been seeing with our Windows CI. I normally just kick it and it works the second time around 😬. Probably worth filing an issue against the actions team, though - I'll do that today. |
Am I right I don't have the rights to "kick" it? |
I will confess that I find the GitHub permissions model a bit confusing. However, based on this, I think you should have permissions to re-run your PR workflows: I'm wondering...if you click on the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM - I'm ready to follow this up with a change to the UI to more visibly offer OAuth/browser flows for cloud users.
I don't think I do. |
@mjcheetham Does that mean you are working on re-ordering the UI or should I still take look? |
Check out #754 |
BitbucketHostProvider: fix runtime exceptions when authentication requests for Bitbucket DC would incorrectly call a Bitbucket Cloud REST API
A bug was introduced in commit: 5a2cfd7. Prior to this only authentication requests for Bitbucket Cloud would try and automatically determine if 2FA was required by the current user by calling a Bitbucket Cloud REST API using user provided Basic Auth credentials
Commit: 5a2cfd7 removed checking of the current host was Bitbucket Cloud vs DC. This meant the check would be run for Bitbucket Cloud and DC regardless. It would fail for Bitbucket DC
The fix is more radical than simply re-instating the check on the type of Bitbucket host.From 1st March 2022 support for using a Bitbucket Cloud user's account password to access REST or Git HTTPS operations has been removed, https://atlassian.community/t5/x/x/ba-p/1948231. As such this automatic test to see if 2FA is required no longer works.
Therefore the check against the Bitbcuket Cloud REST API has been removed in its entirety