Codestin Search App

dantraMSFT · 2018-05-17T19:51:46Z

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

SteveL-MSFT · 2018-05-17T23:00:42Z

src/System.Management.Automation/engine/remoting/fanin/WSManTransportManager.cs

I think you can get rid of the isHttps variable and just use:

connectionUri.Scheme != Uri.UriSchemeHttps

@SteveL-MSFT: does connectionUri guarantee that it normalizes the case of the Scheme property?

I believe @SteveL-MSFT means:

if (connectionInfo.AuthenticationMechanism == AuthenticationMechanism.Basic && !isSSLSpecified && StringComparer.OrdinalIgnoreCase.Compare("https", connectionUri.Scheme) != 0)

@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

SteveL-MSFT · 2018-05-17T23:02:02Z

test/powershell/engine/Remoting/RemoteSession.Basic.Tests.ps1

In the HelpersRemoting.psm1 module, I believe you can get real creds to validate it works.

I actually don't want to establish a connection; I'm verifying that Basic Auth verification doesn't reject the request.

Is there a separate test that validates it works?

@SteveL-MSFT: No, we don't have any automated remoting tests for PSRP at this point.

iSazonov · 2018-05-18T04:07:32Z

src/System.Management.Automation/engine/remoting/fanin/WSManTransportManager.cs

I believe @SteveL-MSFT means:

if (connectionInfo.AuthenticationMechanism == AuthenticationMechanism.Basic && !isSSLSpecified && StringComparer.OrdinalIgnoreCase.Compare("https", connectionUri.Scheme) != 0)

iSazonov · 2018-05-18T04:09:54Z

test/powershell/engine/Remoting/RemoteSession.Basic.Tests.ps1

Comment in Line 32 says "not with a PSSessionOpenFailed". Seems the comment should be corrected (or the test is wrong?).

dantraMSFT · 2018-05-18T22:11:04Z

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.

vors · 2018-06-17T05:25:39Z

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

As I see it (which may or may not be correct), one of the primary use cases for PowerShell on non-Windows systems is for administering remote Windows systems, including Azure and Office 365.

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.

echobb8 · 2018-06-20T15:38:04Z

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?

vors · 2018-06-20T16:43:56Z

Is there a workaround?

Use PS version before 6.1.0-Preview3, i.e. 6.1.0-Preview2
https://github.com/PowerShell/PowerShell/releases

dantraMSFT · 2018-06-20T16:57:28Z

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.

…ixed

adityapatwardhan · 2018-06-20T19:26:43Z

@dantraMSFT Can you have a look, the PR is pulling 91 commits with 498 files.

dantraMSFT · 2018-06-20T19:42:24Z

I removed the blocking label and disabled the test that hits the libmi issue (microsoft/omi#502 )

dantraMSFT · 2018-06-20T20:10:24Z

@adityapatwardhan Fixed

adityapatwardhan · 2018-06-20T21:10:33Z

test/powershell/engine/Remoting/RemoteSession.Basic.Tests.ps1

        $err.Exception.ErrorCode | Should -Be 801
    }

+   # Marked as pending due tohttps://github.com/Microsoft/omi/issues/502


nitpick: space between to and https

adityapatwardhan · 2018-06-20T21:16:24Z

test/powershell/engine/Remoting/RemoteSession.Basic.Tests.ps1

+        # 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


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 -2146233087

No, when -ErrorVariable is used, pester doesn't have an exception to catch.

This cannot be done as when err is set no exception is thrown.

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

@SteveL-MSFT: new-pssession doesn't throw, it writes to the error stream.

@SteveL-MSFT: do you have any additional feedback?

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 · 2018-06-22T16:38:17Z

test/powershell/engine/Remoting/RemoteSession.Basic.Tests.ps1

+        # 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


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

kai-h · 2018-06-25T21:31:42Z

Can we please explicitly have a test to connect to Office 365, or even Azure.
We just need to test that the connection attempt succeeds, it doesn't need to be given valid credentials as long as it doesn't throw a ConnectFailed error.
The remote session can be accessed via the following Connection URI for Office 365:

-ConnectionUri https://outlook.office365.com/powershell-liveid/

or, for your code snippet:

$uri = "https://outlook.office365.com/powershell-liveid/"

iSazonov · 2018-06-26T04:13:54Z

Can we please explicitly have a test to connect to Office 365

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.

kai-h · 2018-06-26T06:02:17Z

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.
It would be wonderful however if the testing was able to qualify that it will connect successfully to Office 365, Azure or some other Microsoft endpoint that customers will be using PowerShell to manage.

dantraMSFT · 2018-06-26T17:57:39Z

@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.

kai-h · 2018-06-26T22:01:24Z

@dantraMSFT - Thanks, I understand given the reasons above.
In my testing, I've found that it's not necessary to supply valid credentials in testing if PowerShell can connect to Office 365. Even if you're supplying invalid credentials (e.g. [email protected] with password Password123), if PowerShell can at least initiate the connection attempt to Office 365, even if Office365 says invalid username or password, this shows that PowerShell can connect, however it can't test if any remote commands can be executed.

SteveL-MSFT · 2018-06-26T23:35:17Z

test/powershell/engine/Remoting/RemoteSession.Basic.Tests.ps1

+        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


Nit: prefer the hex version particularly with a HResult: 0x80131501

adityapatwardhan · 2018-06-27T17:55:32Z

@dantraMSFT Can you respond to @SteveL-MSFT comment.

dantraMSFT · 2018-06-27T19:47:42Z

@adityapatwardhan Addressed Steve's comment.

SteveL-MSFT · 2018-06-27T20:00:03Z

test/powershell/engine/Remoting/RemoteSession.Basic.Tests.ps1

+        # 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


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

dantraMSFT · 2018-06-27T20:29:28Z

@SteveL-MSFT Hmm, that's not how I interpreted the guidelines.
That said, forcing a throw isn't testing the cmdlet the way it's normally used. Additionally, using the guideline prevents testing non-terminating errors.

SteveL-MSFT · 2018-06-27T20:53:06Z

@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.

dantraMSFT requested review from PaulHigin and mirichmo as code owners May 17, 2018 19:51

dantraMSFT requested review from SteveL-MSFT, iSazonov and markekraus and removed request for PaulHigin and mirichmo May 17, 2018 19:52

SteveL-MSFT requested changes May 17, 2018

View reviewed changes

iSazonov reviewed May 18, 2018

View reviewed changes

markekraus approved these changes May 18, 2018

View reviewed changes

dantraMSFT added the Blocked blocked on something external to this repo label May 18, 2018

SteveL-MSFT approved these changes May 19, 2018

View reviewed changes

iSazonov mentioned this pull request Jun 14, 2018

Can not connect to Office 365 with PowerShell on macOS - Client did not get proper response from server. #7054

Closed

SteveL-MSFT assigned adityapatwardhan Jun 20, 2018

dantraMSFT requested review from TravisEz13, adityapatwardhan, anmenaga, daxian-dbw and joeyaiello as code owners June 20, 2018 17:54

dantraMSFT added 3 commits June 20, 2018 11:00

[FEATURE] Allow Basic Auth over HTTPS

95c76d3

WSManTransportManager.cs: Simplify HTTPS check

40744b9

Update comment in test to refer to the right exception type.

Disable test until limi crash fo selected connection error paths is f…

9bd40f6

…ixed

dantraMSFT requested review from BrucePay, Francisco-Gamino and charub as code owners June 20, 2018 19:14

dantraMSFT requested review from HemantMahawar and JamesWTruher as code owners June 20, 2018 19:14

dantraMSFT removed the Blocked blocked on something external to this repo label Jun 20, 2018

adityapatwardhan requested changes Jun 20, 2018

View reviewed changes

Fix typo in comment about pending test.

a6ccd69

adityapatwardhan approved these changes Jun 20, 2018

View reviewed changes

SteveL-MSFT requested changes Jun 22, 2018

View reviewed changes

SteveL-MSFT requested changes Jun 26, 2018

View reviewed changes

BrucePay approved these changes Jun 27, 2018

View reviewed changes

Use Hex format for defining the expected HRESULT

7857d27

SteveL-MSFT requested changes Jun 27, 2018

View reviewed changes

SteveL-MSFT approved these changes Jun 27, 2018

View reviewed changes

adityapatwardhan merged commit 5e8b23e into PowerShell:master Jun 27, 2018

dantraMSFT deleted the dantra/issue6779 branch August 22, 2018 16:32

Conversation

dantraMSFT commented May 17, 2018

PR Summary

PR Checklist

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dantraMSFT commented May 18, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

vors commented Jun 17, 2018

Uh oh!

echobb8 commented Jun 20, 2018

Uh oh!

vors commented Jun 20, 2018

Uh oh!

dantraMSFT commented Jun 20, 2018

Uh oh!

adityapatwardhan commented Jun 20, 2018

Uh oh!

dantraMSFT commented Jun 20, 2018

Uh oh!

dantraMSFT commented Jun 20, 2018

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kai-h commented Jun 25, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

iSazonov commented Jun 26, 2018

Uh oh!

kai-h commented Jun 26, 2018

Uh oh!

dantraMSFT commented Jun 26, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

kai-h commented Jun 26, 2018

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dantraMSFT commented May 18, 2018 •

edited

Loading

kai-h commented Jun 25, 2018 •

edited

Loading

dantraMSFT commented Jun 26, 2018 •

edited

Loading