Re: excessive data transfer with SSPI

Sergey Gotvansky wrote:

> I suppose that the problem of huge transfers is using of per-request
> authentication instead of per-connection. The widely used
> mod_auth_sspi uses per-request auth that leads to resending of
> 3-phase SSPI auth information. I tried to jump from per-request to
> per-connection by patching mod_auth_sspi module and found it working
> ok. I'm still investigation the real reason and looking for solution.
> My team is really interested in fine SSPI/NTLM authorization.

Can you provide a binary of your patched mod_auth_sspi? Or even better,
post your patch to http://www.gknw.de/phpbb/viewforum.php?f=9

But even with that issue fixed, there's still one problem left:
If e.g. the user account "guest" is enabled on the domain controller,
the SSPI will authenticate successfully, but then later the client will
fail in the authorization process. In that case, neon retries the SSPI
again (which again succeeds with user "guest"). It doesn't "fall back"
to basic authentication (or asking the user for username/password) in
that case.

We've already got a couple of reports from users using the 1.3.0RC1/2
versions of TortoiseSVN that they can't connect to their repositories
anymore because of this. Some could make it work by disabling the guest
account, but some of them simply can't disable that account because they
need it.

Do you have an idea on how to solve this? Maybe a new option for
mod_auth_sspi to not authenticate as user "guest"? Or is a change in
neon required? Or in Subversion?

Maybe the whole SSPI auth feature could be made run-time configurable in
neon and not compile-time configurable?

Stefan

-- 
        ___
   oo  // \\      "De Chelonian Mobile"
  (_,\/ \_/ \     TortoiseSVN
    \ \_/_\_/>    The coolest Interface to (Sub)Version Control
    /_/   \_\     http://tortoisesvn.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org