LNURLp extension not enforcing domain constraints on `successAction`

As @Perlover discovered in Fittiboy/bitcoin-on-twitch#9, it is possible to set a successAction url that doesn’t match the callback url used during the payment flow. This is not allowed according to the spec:

{
   tag: 'url'
   description: 'Thank you for your purchase. Here is your order details' // Up to 144 characters
   url: 'https://www.ln-service.com/order/<orderId>' // url domain must be the same as `callback` domain at step 3
}

It is enforced by at least BLW, and potentially other wallets.

Changing success_url to success_path, and appending this to the domain used during the payment flow would solve this problem.

[akumaigorodski]

If the spec is enforced, the site owner has full control over whether or not redirects are allowed.

Following redirects apparently can be disabled on client side which BLW does not do currently, but it will.

[Fittiboy]

the redirect was undertaken by the initial side by owning the original domain.

This is correct, yes. But I do actually see the point now. When the spec is enforced, a user could not go to a service like https://lnbits.com and create a lnurl-pay link with a malicious successAction url.

Edit: In order to add a malicious url, one of two things is necessary:

1. The user owns the domain (like in my case), and is held liable either way.
2. The domain has a redirection endpoint, like fiatjaf mentioned:

Alternatively we could have a default-redirect endpoint built in LNURLp that would be used as the default success_action URL and always redirect from that to whatever success_url the user have specified.

If the spec is enforced, the site owner has full control over whether or not redirects are allowed.