On 19. 5. 25 21:30, Branko Čibej wrote:
On 19. 5. 25 20:26, Peter Balogh wrote:
Hi,
So an OAuth based 2FA auth flow would result in a cookie in the browser
Why don't we extend SVN to handle the same flow?
No technical reason except that no-one sane wants to implement a real
HTTP browser in Subversion, with cookies and all that entails.
Can you please explain, in your view, how is a session id that we
communicate via Cookie headers different from a Bearer token?
A bearer token is just a specific HTTP request header. We can handle
those. So are cookies, really, but Subversion is (see above) not a
generic browser. It's bad enough that OAuth2 essentially _requires_
that the authentication happens in a browser. So headless tools like
svn usually offload that to whatever the users current default browser
happens to be ... it's a huge mess to make that work on multiple
platforms. I really don't think any of us has the time (or desire) to
go there.
As far as I know (I don't have any RFC past besides my google foo)
there's no standard way of authenticating with username + password + totp
I'd be surprised if there isn't. The trick with appending ";<totp
token>" to the password sure works with HTTP basic auth. I haven't
looked at the code of mod-authn-otp to see what it actually does,
other than it supports basic and digest authentication.
So it turns out that _this_ module requires *only* the one-time
password, not the "real" user's password. Which is basically fine, since
the shared secret for generating one-time PINs works just like a password.
This isn't the same as 2FA, though, it's a single factor; sorry. So, I
suppose we'd have to find another solution.
-- Brane
