-
Notifications
You must be signed in to change notification settings - Fork 8.1k
Allow Basic Auth over HTTPS #6890
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
Allow Basic Auth over HTTPS #6890
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.
I think you can get rid of the isHttps variable and just use:
connectionUri.Scheme != Uri.UriSchemeHttpsThere 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.
@SteveL-MSFT: does connectionUri guarantee that it normalizes the case of the Scheme property?
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.
I believe @SteveL-MSFT means:
if (connectionInfo.AuthenticationMechanism == AuthenticationMechanism.Basic && !isSSLSpecified && StringComparer.OrdinalIgnoreCase.Compare("https", connectionUri.Scheme) != 0) 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.
@SteveL-MSFT is correct. Uri.Scheme is always normalized to lowercase (see the notes on the property value here https://docs.microsoft.com/en-us/dotnet/api/system.uri.scheme?view=netcore-2.1)
Line 1531 is unneeded and on line 1533 && !isHttps can be changed to && connectionUri.Scheme != Uri.UriSchemeHttps
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.
Fixed
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.
In the HelpersRemoting.psm1 module, I believe you can get real creds to validate it works.
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.
I actually don't want to establish a connection; I'm verifying that Basic Auth verification doesn't reject the request.
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 there a separate test that validates it works?
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.
@SteveL-MSFT: No, we don't have any automated remoting tests for PSRP at this point.
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.
I believe @SteveL-MSFT means:
if (connectionInfo.AuthenticationMechanism == AuthenticationMechanism.Basic && !isSSLSpecified && StringComparer.OrdinalIgnoreCase.Compare("https", connectionUri.Scheme) != 0) 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.
Comment in Line 32 says "not with a PSSessionOpenFailed". Seems the comment should be corrected (or the test is wrong?).
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.
Fixed
|
The test failure appears to be a variation of microsoft/omi#502 that is not covered by the fix. This PR cannot be merged until the libmi issue is fixed since the new test hits this path. It appears to hit sporadically in release builds and consistently in debug builds. |
|
Can we at least merge it without tests, since the "Blocker" status is applicable to the tests flakiness as far as I understand? As @kai-h pointed out in #7054
Inability of connecting to office 365 remoting endpoints out of the box is a pretty concerning regression and impact the number of useful scenarios for pwsh. |
|
What's the status on this? I need to connect to Office 365 from my Mac, but it fails: "New-PSSession : Basic authentication is not supported over HTTP on Unix." Is there a workaround? |
Use PS version before 6.1.0-Preview3, i.e. 6.1.0-Preview2 |
|
I will see if I can get the PR through today with the failing test marked as pending. |
Update comment in test to refer to the right exception type.
|
@dantraMSFT Can you have a look, the PR is pulling 91 commits with 498 files. |
|
I removed the blocking label and disabled the test that hits the libmi issue (microsoft/omi#502 ) |
|
@adityapatwardhan Fixed |
| $err.Exception.ErrorCode | Should -Be 801 | ||
| } | ||
|
|
||
| # Marked as pending due tohttps://github.com/Microsoft/omi/issues/502 |
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.
nitpick: space between to and https
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.
fixed
| # use a Uri that specifies HTTPS to test Basic Auth logic. | ||
| # NOTE: The connection is expected to fail but not with a ConnectFailed exception | ||
| $uri = "https://localhost" | ||
| New-PSSession -Uri $uri -Credential $credential -Authentication Basic -ErrorVariable err |
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.
Can you use the pattern below?
{ New-PSSession -Uri $uri -Credential $credential -Authentication Basic -ErrorVariable err } | Should -Throw -ErrorId '1,PSSessionOpenFailed' -ExceptionType 'System.Management.Automation.Remoting.PSRemotingTransportException'
$err.Exception.HResult | Should -Be -2146233087There 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, when -ErrorVariable is used, pester doesn't have an exception to catch.
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.
This cannot be done as when err is set no exception is thrown.
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.
If this is a negative test case where you need to do more validation of the exception, you should use the pattern in our test guidance doc with -PassThru: https://github.com/PowerShell/PowerShell/blob/master/docs/testing-guidelines/WritingPesterTests.md#writing-pester-tests
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.
@SteveL-MSFT: new-pssession doesn't throw, it writes to the error stream.
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.
@SteveL-MSFT: do you have any additional feedback?
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.
I think you should follow the convention for now to use -ErrorAction Stop and then use Pester's Should -ThrowErrorId -PassThru to do additional validation for consistency until we have capability to validate non-terminating errors
| # use a Uri that specifies HTTPS to test Basic Auth logic. | ||
| # NOTE: The connection is expected to fail but not with a ConnectFailed exception | ||
| $uri = "https://localhost" | ||
| New-PSSession -Uri $uri -Credential $credential -Authentication Basic -ErrorVariable err |
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.
If this is a negative test case where you need to do more validation of the exception, you should use the pattern in our test guidance doc with -PassThru: https://github.com/PowerShell/PowerShell/blob/master/docs/testing-guidelines/WritingPesterTests.md#writing-pester-tests
|
Can we please explicitly have a test to connect to Office 365, or even Azure. -ConnectionUri https://outlook.office365.com/powershell-liveid/or, for your code snippet: $uri = "https://outlook.office365.com/powershell-liveid/" |
All tests using external resources is unstable. 😕 and daily/night builds frequently failed. Perhaps for the cases we could have optional test set in separate job. |
|
I suppose that the main thing is that PowerShell actually attempts to connect to a remote session, be it locally or on an actual remote system. |
|
@kai-h I will be creating tests that verify we can successfully connect to o365 but it won't be in the nightly build. One reason is mentioned above but the primary one, for now, is I don't want to expose o365 account information; even if only for testing purposes. The tests will be checked in but will likely be conditioned on a custom JSON file that is not present in the public CI builds. That's my working plan for now. If I come up with a cleaner solution, I'll post to this thread. |
|
@dantraMSFT - Thanks, I understand given the reasons above. |
| New-PSSession -Uri $uri -Credential $credential -Authentication Basic -ErrorVariable err | ||
| $err.Exception | Should -BeOfType [System.Management.Automation.Remoting.PSRemotingTransportException] | ||
| $err.FullyQualifiedErrorId | Should -Be '1,PSSessionOpenFailed' | ||
| $err.Exception.HResult | Should -Be -2146233087 |
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.
Nit: prefer the hex version particularly with a HResult: 0x80131501
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.
Fixed
|
@dantraMSFT Can you respond to @SteveL-MSFT comment. |
|
@adityapatwardhan Addressed Steve's comment. |
| # use a Uri that specifies HTTPS to test Basic Auth logic. | ||
| # NOTE: The connection is expected to fail but not with a ConnectFailed exception | ||
| $uri = "https://localhost" | ||
| New-PSSession -Uri $uri -Credential $credential -Authentication Basic -ErrorVariable err |
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.
I think you should follow the convention for now to use -ErrorAction Stop and then use Pester's Should -ThrowErrorId -PassThru to do additional validation for consistency until we have capability to validate non-terminating errors
|
@SteveL-MSFT Hmm, that's not how I interpreted the guidelines. |
|
@dantraMSFT let's defer this to the other discussion on validating terminating vs non-terminating. I'll approve this PR as this isn't blocking. |
PR Summary
Fix #6779 regression.
The change to disallow Basic Auth over HTTP was not checking the scheme for the -Uri parameter. The result is Basic Auth connections over HTTPS via the -Uri parameter were disallowed.
The change adds the check for the scheme as well as useSSL.
PR Checklist
.h,.cpp,.cs,.ps1and.psm1files have the correct copyright headerWIP:to the beginning of the title and remove the prefix when the PR is ready.[feature]if the change is significant or affects feature tests