Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Authorization Header expects LSAT, conflicts with Protocol Specification #109

Open
seb-ibex opened this issue Jul 14, 2023 · 2 comments
Open

Comments

@seb-ibex
Copy link

First of all, thanks for Aperture. We have been playing around with it and its great.

Seems like the Authorization Header checker is looking for the LSAT prefix, while the protocol specification says the value should be L402.

This piece of code seems to be the cause:

var (
	authRegex  = regexp.MustCompile("LSAT (.*?):([a-f0-9]{64})")
	authFormat = "LSAT %s:%s"
)
@Roasbeef
Copy link
Member

Good eye, the bLIP spec (which'l replace the spec at that link above), has this section on backwards compat: https://github.com/lightning/blips/blob/d2a8c19ec6f49677d942d1c03f3ab0a3362e7b39/blip-0026.md#backwards-compatibility

We should make it clearer though, add test vectors, and also update Aperture to recognize both in the libs. One challenge is that many clients (eg: Lightning Labs liquidity related products) use the existing LSAT prefix, so the switch over will be somewhat tricky, eg:

  • Should the client send an X- header in the initial request to denote which version of the protocol it understands?

Only a single WWW-Authenticate K-V can be sent by the server, so either the client needs to optimistically signal which version, or perhaps something similar to: lightninglabs/L402#12

@positiveblue
Copy link
Contributor

positiveblue commented Feb 10, 2024

It's kind of weird that we changed the header to L402 if both clients and servers will have to keep the backwards compatibility for ever. Should we have left as LSAT in the header for ever then?

I think it is early enough for the protocol to deprecate the LSAT (even if aperture still supports it until all clients have been updated) while making sure "new" implementations or deployments use the L402. The idea would be to update Aperture/LL clients as:

Aperture

  • Add a config value for what value the server will use when sending the challenge.
  • L402 would be used by default, but LL overwrites it to LSAT.
  • When validating the auth headers, LSAT and L402 are accepted without any difference

LL Clients

  • Old versions of loop, pool...: Look for LSAT in the challenge, and set LSAT in the header, no change there (ofc, that's why we are doing all this!)
  • New versions: Looks for LSAT/L402 in the challenge, send L402 in the headers

In this way, new deployments of aperture will use L402 by default that looks like new client implementations support.

The LL servers will be able to serve old and new clients as long as they understand LSAT in the challenge. As long as all new clients always sent L402, we can track how many clients in the wild do not understand L402 in the challenge, and switch to L402 by default as soon as there are no old clients left.

For other libraries/servers out it can be summarize it as:

Server: send L402 if new. Keep sending LSAT challenges but accept L402/LSAT in the auth headers.
Clients: send L402 by default. If possible, accept LSAT/L402 in the challenges

and eventually kill the LSAT.

There is a branch in my fork adding the LSAT/L402 handling in the client (when receiving the challenge) and the server (when checking the credentials in the auth header.

If I get green light I can add the config for the default (LSAT or L402) when the server creates the challenge + default to L402 when the client sends the header 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants