Support sandstorm-style webkeys in server baseUrls

[abliss]

trafficstars

Hi! I'm attempting to host a Matrix Synapse server inside Sandstorm (for added convenience and security). In order to get Riot-im to talk to it, I had to make a few changes to support a "webkey" server url.

In a webkey, the Bearer Authorization Token is included in a url as the hash. This change allows Matrix to recognize such urls as valid, and to use the given Bearer Token in all requests. (Matrix's own authorization token then moves to query params).

I would be honored if you'd take a look at this change and consider merging it. If any alterations are required, or if a different approach seems better, I'd love to hear your thoughts.

Thanks for your time, and thanks for creating Matrix!

---

Here's what your changelog entry will look like:

✨ Features

• Support sandstorm-style webkeys in server baseUrls (#1334). Contributed by @abliss.

[turt2live]

@abliss When you get a chance, please sign off on your changes per the contributing guidelines so we can take a look.

[turt2live]

Hmm, though this changes the authentication scheme to be against the recommendations of the spec... Not sure if we should have this support at the project level and instead prefer to use something else.

[abliss]

Thanks for the quick response! I force-pushed to fix the lint errors and to add the sign-off-by header.

Any chance you could link me directly to the spec's recommendations for authentication/authorization ? Otherwise, I'll go searching for it. I'm totally open to exploring other ways to solve this problem.

[t3chguy]

https://matrix.org/docs/spec/client_server/r0.6.0#client-authentication

[abliss]

Thanks for the link. Are you referring to this part? "Clients are encouraged to use the Authorization header where possible to prevent the access token being leaked in access/HTTP logs. The query string should only be used in cases where the Authorization header is inaccessible for the client." There does seem to be a carve-out for cases where the client is unable to set the Authorization header (in this case, because a higher-level layer needs to use that header).

Or is there another problem in the spec?

[andybalaam]

This is stale and does not conform with the spec, so would require an MSC to proceed.

[abliss]

Hi, any chance you be more specific about how it does not conform wth the spec?

[andybalaam]

@abliss I probably expressed it wrongly: it's not that it conflicts with the spec, but that it's an extension that is not included in the spec. In order for us to support it, we'd need it to be added to the spec via creating an MSC.

I would warn you though, that the direction Matrix is taking is towards supporting OIDC for auth, so likely the best way to get support would be to understand whether it is already possible using OIDC, or whether it can be integrated into the OIDC spec, rather that the Matrix spec.

Sorry for the rather abrupt initial message: I assumed that you had abandoned this idea since there had been no updates for 3 years.