Using a backend with basic http authentification?

[SilvrDuck]

Hi there,
I’m trying to run the front end using a backend for which http requests need to be authorized using basic auth.

I didn’t find any env var to do that, so I just set the following env variable :
OSRM_BACKEND='https://some_user:some_password@my_osrm_url.com'

This does not work though. With Firefox, the request hangs forever, but if I copy the cURL command in a terminal, the login info is in there, and I get the result back from the server.

In Chrome, the cURL command seems to get striped down of the auth info, thus I get a 401 from the server.

Is there a way to do that without going in the front’s code to add some headers?

Thanks in advance.

[DennisOSRM]

Thanks for raising this, and apologies for the very long silence on it.

Short answer: authenticating against the backend from the frontend is out of scope today, and supporting it properly needs work we have not done yet. The request is a reasonable one, so we are keeping it open as a feature request rather than closing it.

Why the approach in the report cannot work

OSRM_BACKEND='https://user:password@host' fails for reasons outside our control:

• Browsers refuse to send credentials embedded in subresource URLs. Chrome strips them, which is the 401 you saw; Firefox handles it differently but does not produce a usable request either. Nothing in the page can override this.
• Routing requests go through @mapbox/corslite, which calls open() and send() back to back with no hook for request headers. Attaching an Authorization header would mean replacing the request layer, not setting an option.
• Credentials configured through OSRM_MODES are written into config.json and served to every visitor, so a credentials option in the frontend would not keep them secret anyway.

That last point is the main reason this is not simply a missing config flag: for a browser application, the credentials have to stay on the server.

What works today

Put a reverse proxy in front of the backend that holds the credentials and serves the routing endpoint from the same origin as the frontend. With nginx:

location /osrm/ {
    proxy_pass https://osrm.internal.example.com/;
    proxy_set_header Authorization "Basic <base64 of user:password>";
}

Then point a mode at the proxied path. Relative URLs are supported and produce same-origin requests:

docker run -p 9966:9966 \
  -e 'OSRM_MODES=[{"name":"car","url":"/osrm"}]' \
  ghcr.io/project-osrm/osrm-frontend:latest

If the proxy has to sit on a different origin than the frontend, it must answer the CORS preflight (OPTIONS) request without requiring authentication and include Access-Control-Allow-Headers: authorization. Otherwise the browser rejects the routing request before it is sent — a common stumbling block when putting basic auth in front of a routing backend.

This is now documented in the README: #497 adds a Backends behind HTTP authentication section along with a regression test covering the relative-URL configuration it depends on.

Possible future work

If there is demand, the container could do the proxying itself, for example an OSRM_PROXY_* setting that makes the bundled nginx generate the proxy location, so credentials stay in the container environment and never reach the browser. Leaving this issue open to track that.