Hi,
The reason I choose the 499 status code, that it was the cleanest way to
reroute the 2FA case in auth.c dispatch_auth function
Hard-coding the 401 can also accomplish this
But without that, I have two directions I can take, and I'd appreciate
some insight, what should I try next:
1.
I can provide a response with 401 status and valid WWW-Authenticate
header where I control the realm string
I can use that to intercept the 2FA request in
svn_ra_serf__credentials_callback in libsvn_ra_serf util.c, and do the
2FA input
That combined with bearer token, that we return could work without
modifying serf
2.
I can introduce a new serf__authn_scheme_t, and have a cleaner
implementation, but it means serf would have an unofficial auth scheme
implementation
I'm all for doing the right thing, working out how to extend the RFC,
but I have 0 knowledge or experience doing that
I'm happy to help any way I can, but I'd rather not wait for months,
before implementing this :)
What do you think, what route should I explore next?
Do I have a change to get the 1. version approved by the svn community?
Do I have a change to get the 2. version approved by the serf community? :)
Best regards,
Peter
On 2025. 05. 23. 17:28, Branko Čibej wrote:
On 23. 5. 25 17:05, Daniel Sahlberg wrote:
Den fre 23 maj 2025 kl 00:35 skrev Peter Balogh<pe...@svnplus.com>:
Hi,
So basically the patch becomes this
I can't say I like the actual branch condition, but I'm open to
suggestions :)
Hi,
I have not studied the patches in detail but I'm not so sure if I
like the
idea of Serf special-casing / hardcoding a custom response reason. I
feel
it would be better to offloading this to Subversion since we control
both
ends there.
I agree. Serf is a general-purpose HTTP client, what we're talking
about here is application-level behaviour. Serf already offloads
authentication to the application, I also can't see a reason why this
would be special-cased in Serf.
Also, RFC7235 [1] require a 401 response to send a WWW-Authenticate
header
- I don't know if it would be possible to use this to send the
challenge.
I have to read up on WWW-Authenticate. ISTR that aside from telling
the client /how/ to authenticate, it's there also support complex
authentication processes.
The response could then be added as a header field. Would it be possible
for the server to return a bearer token (= more or less the same as a
Set-Cookie) that we could store client-side to include on future
requests?
I'm surprised that multi-step challenge/response mechanism isn't
already standardised in HTTP. True, all the multi-factor schemes I've
used to date are for authentication flow in browsers, where the server
presents a user interface. For headless cases, things like API tokens
tend to be generated in advance through an out of band channel (again,
usually through a UI in a browser). App tokens are, again, not
multi-factor authentication.
Maybe we will have to invent an HTTP workflow for this, but let's not
go it alone. This is, after all, the ASF and there are a few people
around that are ... quite knowledgeable about HTTP. I suggest we
consult. Worst case, there may be an IETF RFC waiting to be written.
-- Brane
P.S.: I say "worst case" because it should've been written long ago
instead of people using status 499 and stuff like that.
