Web app's CUPS setup link has hard coded IP in URL

[maehw]

See BoothApi.cpp:

                {
                    auto setting = currentBoothSettings.mutable_cups_link();
                    setting->set_name(locale.get<string>("api.booth.cupsSetup"));
                    setting->set_url("http://192.168.4.1:631");
                }

The IP is hard coded and every host with a different IP address will fail to open the CUPS setup website (or open another machine's CUPS setup website).

The link with the IP should be set dynamically in order to work on all machines.

Edit: accessing :631 also does not work from the same local network for me at the moment, only localhost:631 on the machine itself.

[ClemensElflein]

True, this should be fixed. I'm not really sure how to handle it though.

The cleanest way would probably be to proxy all requests through the self-o-mat software (on port 9080) and internally access localhost:631. This way we could use a relative URL in BoothApi.cpp (e.g. "/cups"). Additionally we don't need to change the CUPS configuration.

Another way to solve this would be to set the link to an absolute address (e.g. "http://<host_ip>:631"). This has two problems I can think of:

• If the PC has multiple IPs (think a fixed photo booth installation with ethernet + hotspot) the link would work for one interface but not for the other.
• We'd need to change the CUPS config to allow external connections

A third way would be to provide an NGINX configuration which proxys things for us. It should contain the following rules:

• 0.0.0.0:80/app proxys to localhost:9080/app - i.e. http:///app shows the app
• 0.0.0.0:80/cups prosys to localhost:631 - i.e. http:///cups shows the cups config. Since NGINX itself runs on localhost, CUPS does not know that we actually access it externally. Therefore no config change is needed there.

In this third scenario, we could also change the link to a relative location (e.g. "/cups").

I think that option 1 would be the cleanest, since we don't need to change any config on the host system, but it would be the hardest one to implement. Therefore I'd vote for option 2 and add a Wiki entry for NGINX config.

@maehw what do you think?