search

lichess-org / external-engine

Using engines running outside of the browser on https://lichess.org/analysis
GNU General Public License v3.0
76 stars 22 forks source link

Facilitate specifying a custom External URL #8

Closed RickyGrassmuck closed 2 years ago

RickyGrassmuck commented 2 years ago

When navigating to http://<external-engine>:<port>, the url query parameter generated and used in the redirect relies on the value supplied by the --bind <BIND> option to the remote-uci command.

In order to facilitate binding the service to Localhost and utilizing a reverse-proxy for handling incoming connections, an option to specify a custom address to be used in the generated ws:// address would be a welcome addition.

Example Scenario

I have deployed the external-engine docker image on a server using the equivalent to the command below. This command essentially provides access to the remote-uci api through a pre-configured Traefik reverse-proxy using the host name stockfish.example.com.

docker run -it --rm \
    --label "traefik.enable=true" \
    --label "traefik.http.routers.stockfish.rule=Host(`stockfish.example.com`)"
    --label "traefik.http.services.stockfish.loadbalancer.server.port=9670" \
    --label "traefik.http.routers.stockfish.tls.certresolver=pdns" \
    -p 127.0.0.1:9670:9670 \
    external-engine \
        /usr/bin/remote-uci --bind 0.0.0.0:9670 --engine stockfish

When navigating to https://stockfish.example.com using the above deployment, the redirect generated contains a url query parameter value that does not work (url=ws://0.0.0.0:9670/socket) 

https://lichess.org/analysis/external?url=ws%3A%2F%2F127.0.0.1%3A9670%2Fsocket&secret=<SHHHiTSaSecret>&name=Stockfish+15&maxThreads=8&maxHash=32768

Proposed Solution

Simply adding an optional --external-address command line option that is used to populate the URL template is likely sufficient for 99% of use-cases. An argument could be made for allowing more granular control by having the option to separately set the host and port separately.

I haven't used Rust much in the past but I may take a stab at implementing this feature as an excuse to poke the language a bit.

niklasf commented 2 years ago

Makes sense.

I am currently considering to rework the communication protocol and introduce some kind of broker server, so that providers would be clients rather than servers.

That would make this feature obsolete. It might be a while, so I would still merge this in the meantime.

RickyGrassmuck commented 2 years ago

Makes sense.

I am currently considering to rework the communication protocol and introduce some kind of broker server, so that providers would be clients rather than servers.

I was actually thinking while poking around on this that it would be pretty nifty if a user was able to manage this in their user preferences on Lichess. Basically, pre-configure external engine providers you would like to be able to use in the users preferences and then on the analysis board settings, you could pick the engine you want to use from a list. Something like this:

image