Networking error when running new demos
Cinemacloud opened this issue · 11 comments
I've tried latest demos behind my own proxy and outside of it and either way apk on alpine or debian images gives me this
unable to connected to local proxy errors just using as-is .. should these demos work with apt-get etc as they advise to try?
Thanks looks cool and excited to learn more.
I've tried latest demos behind my own proxy
@Cinemacloud Are you running containers on browser? If so, your proxy needs to be accessible via Fetch API or WebSocket as containers on browser use these APIs for accessing to outside of the browser.
Yes browser 192.168.491.1:8080
All other web spps n sockets work in my chrome on macos.. anything to try?
All other web spps n sockets work in my chrome on macos.. anything to try?
Then the default configuration (192.168.127.253:80) should work as the actual networking is performed using HTTP(S) networking relying on the browser's Fetch API (please see also https://github.com/ktock/container2wasm/tree/d05d6977df7a0d51dbc807a893f1854db8960c75/examples/networking/fetch ).
apk
Does the repository you're trying to access supports CORS access? When you access to a server from your browser, the server needs to allow CORS access from your browser.
Not sure what you mean by repository trying to access and not to mention CORS. This is using your demos on github in Chrome on Macos pretty standard setup I think. Did I mistunderstand or did I need to customize my envrionment for demos to work out of box? I'm about to try it from cli and using custom docker images per your readme but figured the demos should work but ... not sure.
I mean your online demos on github.. not repo examples via local cli.
repository trying to access
I meant the apk repository you're trying to access from your browser using apk.
If you use the demo page, the set of accessible servers from the containers on your browser are limited by CORS, as described in the Note section on the demo page. I guess that the apk server doesn't allow CORS access from your browser. If you setup WebSocket-based proxy, you can access to anywhere accessible from the proxy.
Ah I see what you mean now thanks for clarifying and providing a solution to try.
So let me make sure I understand this all correctly, in a beta or production environment dealing with public they would all need the proxy wasm running via cli or can both be bootstrapped in browser and circumvent CORS of browser and cross origin requests that I can't control headers for?
@Cinemacloud Yes, both of the container and a proxy are needed for networking. Proxy via cli on the host can avoid the browser's CORS/Forbidden headers restriction and proxy wasm running on browser is affected by these browser's security features.
@ktock Curious about a related idea, what if we ran Neko (https://github.com/m1k1o/neko) container (a browser environment) in c2w in a browser, and requested a site via Neko, would the CORS rules apply to that local context or the c2w context as far as the non-controllable cross origin and local Neko browser are concerned?
@Cinemacloud I haven't used Neko browser, but all HTTP networking is done through the proxy wasm so I think CORS will be applied to that case as well (like set of accesible sites of curl in container on browser is restricted by CORS).
Can you find a test a standalone Puppeteer container with c2w and run a simple CORS/screenshot test?
That'll prove the use-case I'm thinking.