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?
Can you please explain, in your view, how is a session id that we
communicate via Cookie headers different from a Bearer token?
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
So why not follow the next best thing, a public easy to edit website
https://en.wikipedia.org/wiki/List_of_HTTP_status_codes that lists 499
as Token Required? :)
My goal was to have a system, that requires no server binary
modification, and adds security on top of the current solutions, while
not sacrificing usability or loosing svn cli, tvsn or browser based access
I don't see how a Bearer token based solution would be better, and how a
Cookie based system with HTTP 499 would be worse
I'm happy to change course, and implement what makes most sense for the
project on the client side, but I'd rather not get into trying to drive
an apache change through the linux deployment pipelines, I have no
experience with that, but I expect that to take years
If we go down the OAuth pass, do you envision the cli client to allow
login without a browser? Is there a protocol, example system that can do
that?
What server response would trigger an oauth flow in the svn client?
Best regards,
Peter
On 2025. 05. 19. 19:33, Greg Stein wrote:
[clarifying]
On Mon, May 19, 2025 at 12:28 PM Greg Stein <gst...@gmail.com> wrote:
Using an OAuth-based workflow that incorporates 2FA. That is
already possible.
I've already seen this done.
What is *really* hard is to incorporate 2FA into the svn
client/libraries. The most straightforward is to use bearer/PAT
tokens, as it requires client changes.
Mixed this up. Hard to incorporate since 2FA requires client changes.
... Given current APIs within svn, I believe the most straightforward
is bearer/PAT tokens.
And some (likely) minimal changes to the Serf API. Per above message,
ignore svn+ssh.
>...
Cheers,
-g
