Watch tasks (admin/storefront) and HTTPS only domains/servers

[AndreasA]

Hi,

in the company I work for, we switched to using local development with domains/servers with HTTPS and a valid certificate as that is also what the customers will use. In our case it is a *.dev domain which means it is ONLY reachable using HTTPS as the whole TLD is HTST configured to forward to HTTPS.

The watch tasks, however, assume that the domain/server is using HTTP. The only solution for now was to create a local alias that is only HTTP but that also means I have to configure all sales channels with multiple domains which is kind of annoying. It is also not possible to somehow fake the domain in this case due to the HTST forward which means all assets are requested using HTTPS from the asset port (e.g. storefront).

[shyim]

I wouldn't see as an task for the watcher to handle that.

You should use an proxy for that like nginx / traefik.

I use nginx-proxy and it works fine https://github.com/shyim/shopware-docker/blob/master/modules/platform-local/admin-watch.sh#L20-L36

[AndreasA]

We are using a HSTS domain locally. So everything is going through HTTPS using that domain. There is no way around it and therefore a proxy will not help as the same host would still be accessed using HTTPS by the browser.

Or do you mean a completely separate watch proxy that uses nginx instead of the one started using watch-storefront.sh? Would this fix those issues? If so, shouldn't the default watch task script: watch-storefront.sh also take care of it?

Actually, it might be possible that the watcher works fine with admin (not tested). It definitely does not in HTTPS with 6.3.5.2, when using watch-storefront.sh from the production template. Event adjusting the port, it results in trying to access the server using a HTTP connection (as http and not https module is imported) instead of HTTPS.

[shyim]

An ssl termination proxy. Just an vhost with an reverse_proxy to the watcher

[AndreasA]

@shyim ah, now that you mention reverse proxy, I feel stupid for not thinking of this myself. And I now know what you meant - for some reason the initial explanation just didn't "click".

Especially, since I used reverse proxies in the past for other stuff too.

I will need to try it first though but it should work.

Maybe something to add to the documentation though?

[AndreasA]

@shyim

OK. Adding a reverse proxy is now working as expected for the PHP part.

However, I am having troubles with assets and media as those are hardcoded to ports 9999 and 9998.

Can I change the URLs for these files without changing the corresponding server ports as otherwise I cannot really setup a corresponding reverse proxy or am I missing something?

[AndreasA]

@shyim OK. the assets (most js files) I got working by setting STOREFRONT_ASSETS_PORT and adding a corresponding reverse proxy config.

But media files and some JS file use the STOREFRONT_PROXY_PORT env variable for the URLs. And I cannot adjust that one as this determines the listen port. Is there another config?

EDIT: OK. I forgot to forward the port header in the reverse proxy config. Now the media also works.

However, it requires me to add another domain to the sales channel with that port. Is there a workaround for this?

Furthermore, some requests still go to 9999 like /sockjs-node/info?

EDIT2: I think I would need an option in the watch task that separates the listen port from the URL replacement port that the hot reload proxy uses and one that specifies the port for sockjs-node/info (seems to use 9999 instead of my custom asset port). Otherwise, I think the only solution would be to use docker containers here, so e.g. the reverse proxy can forward inside the docker network and both run on the same port.

Or by adjustong the webpack.config.js to add

public: `${hostName}${isHotMode ? ':<asset-reverse-proxy-port>' : ''}'

and not just publicHost and by setting the proxyUrl port in proxy-server-hot to the main content reverse proxy port. Or did I muss some possible configuration options.

Would be nice if these two could be confgured and a documentation added on how to do this (e.g. sample nginx config), then this would work nicely.

[AndreasA]

Any news regarding how I can get this working correctly? Even if I need an additional proxy but as mentioned above that doesn't work curerntly due to port issues. Even better would be direct support in the watch task as it is simpler - though it will most likely at least require some certificate config.

another solution would be to have the watch task run on http with localhost but access https on a specific domain and forward the HTTP host and HTTPS as port. this would actually be the simplest solution, if somehow possible.

[amenk]

Once it's working you might also get CORS problems, see also https://stackoverflow.com/questions/68228241/shopware-6-bin-watch-storefront-sh-causes-cors-errors-in-chrome

[AndreasA]

It might in general be a good idea to provide the option of a watch task that just recompiles the scripts/css files and one needs to manually refresh the browser. Sure it isn't that comfortable as autorefresh but in most cases it is actually enough and way easier regarding HTTPS and CORS.

Though I also think the proxy should work correctly.

[amenk]

Yes, an option to just rebuild the styles and js on changes would be great. Do you know how to do this? The above comments are about getting the hot reloading proxy to work, right?

[AndreasA]

Sadly no. I haven't needed the watch task in some time now, so I didn't do any more digging into it. Mostly use Shopware 6 in a headless setup, except one project.

Just wanted to mention it here for the Shopware team as an alternative to the proxy solution because it is most likely easier to implement, and probably also easier to use (no proxy ports, certificates etc. necessary), than the proxy solution and should be a good solution/alternative for most.

In any case this really should be fixed, whatever the solution might be as it seriously impacts development and one should be able to do so without a lot of additional work, e.g. to setup a proxy server for HTTPS - which as mentioned didn't perfectly anyway.

[scriptibus]

It might in general be a good idea to provide the option of a watch task that just recompiles the scripts/css files and one needs to manually refresh the browser. Sure it isn't that comfortable as autorefresh but in most cases it is actually enough and way easier regarding HTTPS and CORS.

Though I also think the proxy should work correctly.

This would be awesome! Any news on this topic?

[ghost]

Not only for watches, but also on the site itself. I have mine running behind an reverse proxy with certs. Now I can't access the admin dashboard because the POST request gets blocked by my browser.

[ghost]

I fixed my issue by adding SetEnvIf X-Forwarded-Proto https HTTPS=on in the virtual-host config, but you can also add it to your .htaccess file.

[sumedia-webdesign]

No, i don't use a proxy! Nor do i forward anything! Why? I don't understand why this problem exists? For what is it? Now i have to set up a nginx on my dev system to eliminate bad ssl configuration. I think this are problems no one need.

[shopwareBot]

[public] Automated response: This issue is linked to the internal issue https://shopware.atlassian.net/browse/NEXT-37871.

[created from NEXT-37871, comment 488525]

[BrocksiNet]

Commit Reference

• NEXT-37871 - Update hot reload server logic to make it work for http and https
• NEXT-38982 - Fix watch storefront multi saleschannel with multi theme