<div dir="ltr">Hi,<div><br></div><div>As more snaps are published, the more I want to install on my PC, device,... Many of them expose some cool services in localhost:[randomport], and I find it that it is getting hard to remember them all. </div><div><br></div><div>Building on an existing tinyproxy snap, I have published (amd64 only at the mo) a local reverse-proxy snap called: local-proxy</div><div><br></div><div>sudo snap install local-proxy</div><div><br></div><div>This allows you to map a path to your app: <a href="http://localhost/yourapp/">http://localhost/yourapp/</a> --> http://localhost:[highport]</div><div><br></div><div>It comes with a default fwd for snapweb from /snapweb/ to localhost:4200</div><div>It also comes with some utility commands like add,delete and print.</div><div><br></div><div>The local-proxy defaults to 8080, but you can change it by running:</div><div>local-proxy.port [your port]</div><div><br></div><div>and then restarting the service:</div><div>sudo systemctl restart snap.local-proxy.tinyproxy</div><div> </div><div>However, there is still a problem that some of snaps assume that they can take control of a popular port (such as 80) without facilities to change it. </div><div>Also some do not take kindly to be proxy-ed (like snapweb) - although tinyproxy has a great "magic cookie" feature that I have enabled by default to work around this.  </div><div><br></div><div>Overall, seems like it would be good practice that if a snap publishes a service to a port, that:</div><div><ul><li>the port can be easily changed</li><li>the snap can be updated told that it will be proxy-ed, and work well</li></ul></div><div>A local reverse proxy feels like this is just a quick fix to a bigger problem... any long term fix suggestions?</div><div><br></div><div>Thanks</div><div><br></div><div>Victor</div><div><br></div></div>