pnp/docker-spfx

4321 port is not available from host in Windows

shurick81 opened this issue · 2 comments

shurick81 commented

I wonder if this is just me or anyone else on Windows is having the same issue. The steps to reproduce are as follows:

  1. cd to SPFx solution files
  2. Run docker run -it --rm --name spfx-helloworld -v ${PWD}:/usr/app/spfx -p 5432:5432 -p 4321:4321 -p 35729:35729 waldekm/spfx
  3. Run gulp trust-dev-cert in the container
  4. Run gulp serve in the container
  5. Open https://localhost:5432/workbench in Chrome

Outcome: user is redirected to https://localhost:4321/temp/workbench.html, that fails:

image

image

In the server log, only /workbench requests are displayed

[12:42:16] Finished subtask 'reload' after 1.89 ms
  Request: [::ffff:172.17.0.1] '/workbench'
  Request: [::ffff:172.17.0.1] '/workbench'

When I test the URL from the container itself, it works just fine:

$ curl -k https://localhost:4321/temp/workbench.html
<!doctype html>
              <html dir="ltr">
              <head>
                <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
                <meta http-equiv="X-UA-Compatible" content="IE=edge" />
                <meta name="viewport" content="width=device-width, initial-scale=1" />

                <title>SharePoint Web Part Workbench</title>

                <link rel="shortcut icon" href="https://localhost:4321/temp/workbench-packages/@microsoft_sp-webpart-workbench/lib/api/assets/server-icon.png" />

    <script type="text/javascript" src="https://localhost:4321/temp/manifests.js"></script>
    <script type="text/javascript" src="https://localhost:4321/temp/workbench-packages/@microsoft_sp-webpart-workbench/local-workbench/sp-webpart-workbench-assembly_default.js"></script>
    <script type="text/javascript">
...

So it seems like some Linux firewall, or Docker ports mapping issue or maybe my Windows host firewall issue...

It can be also detected automatically, without using browser:

Requesting the https://localhost:5432/workbench fails with SSL:

PS C:\Users\asapozhkov> Invoke-WebRequest https://localhost:5432/workbench
Invoke-WebRequest : The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel.
At line:1 char:1
+ Invoke-WebRequest https://localhost:5432/workbench
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (System.Net.HttpWebRequest:HttpWebRequest) [Invoke-WebRequest], WebException
    + FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeWebRequestCommand

However, the https://localhost:4321/temp/workbench.html fails even with connection:

PS C:\Users\asapozhkov> Invoke-WebRequest https://localhost:4321/temp/workbench.html
Invoke-WebRequest : The underlying connection was closed: An unexpected error occurred on a send.
At line:1 char:1
+ Invoke-WebRequest https://localhost:4321/temp/workbench.html
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (System.Net.HttpWebRequest:HttpWebRequest) [Invoke-WebRequest], WebException
    + FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeWebRequestCommand
shurick81 commented

A couple of more findings:

  1. https://localhost:35729 seems exposed properly so I can access it via curl and browser from the host:
    image

  2. It is not just accessing from the host that fails. Also similar issue when I try curl from another container on the same host. It probably means that it is not restriction of my host, but something else. Can be that the web server itself is only accepting requests from local caller IPs? Or, again, local firewall on the container?

shurick81 commented

Now I see that I did not put "hostname": "0.0.0.0" as it is suggested in README.