Discussion:
Http authentication
Essig Felix
2018-07-18 13:38:30 UTC
Permalink
Hi,

I have a question about the http authentication when using the subversion api 1.8.13.
For example using the 'svn_client_list3' function:
Everytime this function is called the first http request does not contain any Authorization header which leads to a '401 Authorization Required' response.
In my opinion this leads to an unnecessary delay when the function is called multiple times and the same credentials could be used.

When calling this function the svn_client_ctx_t contains an svn_auth_baton_t with set default username and default password parameters.

Now to my actual question:
Can this behaviour somehow be changed or is it just designed to work this way? I also know that the version I'm using is not the newest one so if you think an upgrade to a newer version could lead to some performance improvement please let me know.


Thanks in advance for your time :)


Regards
Felix Essig
Branko Čibej
2018-07-18 14:45:38 UTC
Permalink
Post by Essig Felix
Hi,
 
I have a question about the http authentication when using the
subversion api 1.8.13.
Everytime this function is called the first http request does not
contain any Authorization header which leads to a ‚401 Authorization
Required‘ response.
In my opinion this leads to an unnecessary delay when the function is
called multiple times and the same credentials could be used.
 
When calling this function the svn_client_ctx_t contains an
svn_auth_baton_t with set default username and default password
parameters.
 
Can this behaviour somehow be changed or is it just designed to work
this way? I also know that the version I’m using is not the newest one
so if you think an upgrade to a newer version could lead to some
performance improvement please let me know.
You can either modify the auth baton or create your own. See
svn_cmdline_create_auth_baton2 in include/svn_cmdline.h and
subversion/libsvn_subr/cmdline.c.

-- Brane
Felix E.
2018-07-19 10:15:44 UTC
Permalink
On 18.07.2018 15:38, Essig Felix wrote:>
Hi,>
I have a question about the http authentication when using the>
subversion api 1.8.13.>
For example using the ‚svn_client_list3‘ function:>
Everytime this function is called the first http request does not>
contain any Authorization header which leads to a ‚401 Authorization>
Required‘ response.>
In my opinion this leads to an unnecessary delay when the function is>
called multiple times and the same credentials could be used.>
When calling this function the svn_client_ctx_t contains an>
svn_auth_baton_t with set default username and default password>
parameters.>
Now to my actual question:>
Can this behaviour somehow be changed or is it just designed to work>
this way? I also know that the version I’m using is not the newest one>
so if you think an upgrade to a newer version could lead to some>
performance improvement please let me know.>
You can either modify the auth baton or create your own. See>
svn_cmdline_create_auth_baton2 in include/svn_cmdline.h and>
subversion/libsvn_subr/cmdline.c.>
-- Brane>
Thanks for your answer.
But what exactly do you mean?
As I said the default parameters are set.
There is also no callback to any auth provider so the default values seem
to work. But only after a auth required response.
The http client should include the auth header already in the first request.

Felix
Johan Corveleyn
2018-07-19 12:10:23 UTC
Permalink
Post by Felix E.
On 18.07.2018 15:38, Essig Felix wrote:>
Hi,>
I have a question about the http authentication when using the>
subversion api 1.8.13.>
For example using the ‚svn_client_list3‘ function:>
Everytime this function is called the first http request does not>
contain any Authorization header which leads to a ‚401 Authorization>
Required‘ response.>
In my opinion this leads to an unnecessary delay when the function is>
called multiple times and the same credentials could be used.>
When calling this function the svn_client_ctx_t contains an>
svn_auth_baton_t with set default username and default password>
parameters.>
Now to my actual question:>
Can this behaviour somehow be changed or is it just designed to work>
this way? I also know that the version I’m using is not the newest one>
so if you think an upgrade to a newer version could lead to some>
performance improvement please let me know.>
You can either modify the auth baton or create your own. See>
svn_cmdline_create_auth_baton2 in include/svn_cmdline.h and>
subversion/libsvn_subr/cmdline.c.>
-- Brane>
Thanks for your answer.
But what exactly do you mean?
As I said the default parameters are set.
There is also no callback to any auth provider so the default values seem to
work. But only after a auth required response.
The http client should include the auth header already in the first request.
I think the client can not assume (without sending a first request)
that authentication will be required. Some servers offer anonymous
access, some require authentication for "write", but allow anonymous
reads, and some require authentication for both read and write
requests. It depends on the servers-side configuration.
--
Johan
Felix E.
2018-07-19 13:01:02 UTC
Permalink
I understand that the very first request shouldn't contain any auth header.
But If a svn function is called multiple times(for the same host etc.) and
there was already a successful authentication, it should be possible to add
the auth header to the following requests instead of waiting for a auth
required response. At least I hoped so.

Felix
Post by Felix E.
Post by Felix E.
On 18.07.2018 15:38, Essig Felix wrote:>
Hi,>
I have a question about the http authentication when using the>
subversion api 1.8.13.>
For example using the ‚svn_client_list3‘ function:>
Everytime this function is called the first http request does not>
contain any Authorization header which leads to a ‚401 Authorization>
Required‘ response.>
In my opinion this leads to an unnecessary delay when the function is>
called multiple times and the same credentials could be used.>
When calling this function the svn_client_ctx_t contains an>
svn_auth_baton_t with set default username and default password>
parameters.>
Now to my actual question:>
Can this behaviour somehow be changed or is it just designed to work>
this way? I also know that the version I’m using is not the newest
one>
Post by Felix E.
so if you think an upgrade to a newer version could lead to some>
performance improvement please let me know.>
You can either modify the auth baton or create your own. See>
svn_cmdline_create_auth_baton2 in include/svn_cmdline.h and>
subversion/libsvn_subr/cmdline.c.>
-- Brane>
Thanks for your answer.
But what exactly do you mean?
As I said the default parameters are set.
There is also no callback to any auth provider so the default values
seem to
Post by Felix E.
work. But only after a auth required response.
The http client should include the auth header already in the first
request.
I think the client can not assume (without sending a first request)
that authentication will be required. Some servers offer anonymous
access, some require authentication for "write", but allow anonymous
reads, and some require authentication for both read and write
requests. It depends on the servers-side configuration.
--
Johan
Philip Martin
2018-07-19 15:29:28 UTC
Permalink
Post by Felix E.
I understand that the very first request shouldn't contain any auth header.
But If a svn function is called multiple times(for the same host etc.) and
there was already a successful authentication, it should be possible to add
the auth header to the following requests instead of waiting for a auth
required response. At least I hoped so.
It's not just the auth header -- the repeat client calls create/destroy
complete TCP connections, so for https:// that involves cert exchange
and renegotiating the encryption keys. Ivan did some work on fixing
this in the past by caching the connections, but that proves tricky
because the client API allows the caller (you) to change the user
credentials between calls and reusing the session with the wrong
credentials is bad. It's hard to fix at the higher level RA layer
because the RA layer doesn't know about the credentials.

Without connection caching the obvious place to store the auth knowledge
is missing. One way to fix this bit might be to have the lower ra_serf
layer cache the credentials, perhaps in long lived pool provided by the
caller or via a callback provided by the caller. The ra_serf layer
knows all about username, auth method, auth token, repository root,
etc. so it could decide when to reuse.
--
Philip
Felix E.
2018-07-19 16:18:56 UTC
Permalink
Post by Philip Martin
Post by Felix E.
I understand that the very first request shouldn't contain any auth header.
But If a svn function is called multiple times(for the same host etc.) and
there was already a successful authentication, it should be possible to add
the auth header to the following requests instead of waiting for a auth
required response. At least I hoped so.
It's not just the auth header -- the repeat client calls create/destroy
complete TCP connections, so for https:// that involves cert exchange
and renegotiating the encryption keys. Ivan did some work on fixing
this in the past by caching the connections, but that proves tricky
because the client API allows the caller (you) to change the user
credentials between calls and reusing the session with the wrong
credentials is bad. It's hard to fix at the higher level RA layer
because the RA layer doesn't know about the credentials.
Without connection caching the obvious place to store the auth knowledge
is missing. One way to fix this bit might be to have the lower ra_serf
layer cache the credentials, perhaps in long lived pool provided by the
caller or via a callback provided by the caller. The ra_serf layer
knows all about username, auth method, auth token, repository root,
etc. so it could decide when to reuse.
--
Philip
Ok thanks for your detailed answer.
I did some work with the serf client and cached the credentials there (
not as part of subversion).
That’s why I thought it may be possible to use the the right auth params or
config etc. to keep the credentials. I just thought there could be a way
to configure the svn client in a way that not every function call leads
to authentication required response from the server.

Felix

Loading...