fix: accept standard base64 in WWW-Authenticate request field#149
Merged
fix: accept standard base64 in WWW-Authenticate request field#149
Conversation
base64url_decode now normalizes standard base64 ('+', '/', '=' padding)
to URL-safe alphabet before decoding. Encoding remains strict base64url
no-pad per spec.
This aligns with the mppx TypeScript SDK, whose ox-powered decoder
accepts both alphabets. Without this fix, servers that emit standard
base64 in the WWW-Authenticate request field (e.g. OpenVPS) cause
tempo-request to fail with 'Unsupported payment method: ' because the
challenge parse error cascades before the method field is read.
gakonst
requested review from
Slokh,
brendanjryan,
mattsse and
onbjerg
as code owners
Contributor
Tempo Lint ResultsSummaryFound 674 issue(s) across 40 file(s)
Issues by Rule Type
|
gakonst
added a commit
to tempoxyz/wallet
that referenced
this pull request
Mar 24, 2026
Updates mpp dependency to include tempoxyz/mpp-rs#149, which makes base64url_decode lenient — accepting both standard base64 ('+', '/', '=' padding) and URL-safe base64 (no padding). This fixes tempo-request failing against servers like OpenVPS that encode the request field using standard base64 instead of base64url.
gakonst
added a commit
to tempoxyz/wallet
that referenced
this pull request
Mar 24, 2026
Updates mpp dependency to include tempoxyz/mpp-rs#149, which makes base64url_decode lenient — accepting both standard base64 ('+', '/', '=' padding) and URL-safe base64 (no padding). This fixes tempo-request failing against servers like OpenVPS that encode the request field using standard base64 instead of base64url.
gakonst
added a commit
to tempoxyz/wallet
that referenced
this pull request
Mar 24, 2026
Updates mpp dependency to include tempoxyz/mpp-rs#149, which makes base64url_decode lenient — accepting both standard base64 ('+', '/', '=' padding) and URL-safe base64 (no padding). This fixes tempo-request failing against servers like OpenVPS that encode the request field using standard base64 instead of base64url.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
tempo requestfails against servers that encode therequestfield in theWWW-Authenticateheader using standard base64 (RFC 4648 §4, with+,/, and=padding) instead of base64url (RFC 4648 §5, with-,_, no padding).Repro:
The server returns a valid
WWW-Authenticateheader withmethod="tempo", but therequestfield uses standard base64 with=padding:base64url_decodeusesURL_SAFE_NO_PADwhich rejects the=padding, causingparse_www_authenticateto fail. The error cascades before themethodfield is evaluated, producing the misleading "Unsupported payment method: " error with an empty string.Solution
Normalize input in
base64url_decodebefore decoding: strip=padding and map+→-,/→_. This follows Postel's law — strict output, lenient input — and aligns with the mppx TypeScript SDK, whoseoxdecoder already accepts both base64 variants.base64url_encode): unchanged, still produces spec-compliant base64url no-padbase64url_decode): now accepts both standard and URL-safe base64, with or without paddingTests
test_base64url_decode_accepts_standard_base64_with_padding— standard base64 with=test_base64url_decode_accepts_url_safe_without_padding— existing behavior preservedtest_base64url_decode_accepts_standard_alphabet_no_padding— standard alphabet, padding strippedtest_parse_www_authenticate_accepts_standard_base64_request— end-to-end: full header parse with standard base64requestfield (reproduces the OpenVPS failure)