[PATCH] support SSPI for Windows
David Pope
d.e.pope at gmail.com
Mon Apr 16 10:20:45 CDT 2012
On Mon, Apr 16, 2012 at 9:26 AM, <Chuck.Kirschman at bentley.com> wrote:
> Additional testing would be great. We’ve been running it here for over 3
> years (first submitted here:
> http://www.selenic.com/pipermail/mercurial-devel/2009-March/010673.html)
> and it works great in our environment and for several folks who have
> contacted us over the years, but I’m sure there are a lot of variants in the
> way that AD can be set up.
Ours is a plain-vanilla AD setup, but I think if Mercurial covered the
90% case it would be perfectly fine as a first step.
> I could give you our version of Hg to try out,
> but it has a lot of other primarily-Windows changes such as dealing with the
> case-insensitive file system, using your AD name as the default for commits,
> finding Beyond Compare in the registry, and so on. Thus it would not be a
> test of just this portion of code. If you can apply this patch (or the new
> one when I get it posted again) to a clean source tree and try it that way
> it would be a better test.
Agreed. I'll see if the existing patch applies cleanly to the current
tree and respond with results. I'm guessing single-issue patchsets
are most likely to receive positive attention.
> I'll be happy to post the patch again as time permits. I can probably
> figure out how to make an extension out of it,
I haven't worked with the hg devs, but given that 1) there are plenty
of folks who will never need the functionality, 2) isolation is good,
and 3) there's a pattern of "promoting" useful extensions to be
included in the official distribution, I think an extension would be
the way to go. Hg devs please weigh in to teach the new guy (me) how
it's done around here. :)
> although I really think it
> has to be enabled out-of-the-box on Windows which is why it was directly
> bolted in.
Enabling it out-of-the-box probably isn't the right path, although
that's certainly a policy decision to be made by the hg devs. Hackers
working at home on open-source projects have no use for it, and
they're probably the larger audience for the foreseeable future. Of
course, once SSPI is in place I could easily see hg dramatically
increasing its corporate usage and support...
> I don't know anything about the other persistent
> connection problems nor how long this patch will have to wait for them to be
> solved first.
Yes, can those who know what the issues are save us some re-learning
and explain the issues as they're currently understood?
On to implementation: This is the entire kerberos extension:
import urllib2_kerberos as u2k
import mercurial.url
def uisetup(ui):
mercurial.url.opener_ = mercurial.url.opener
def opener(*args, **kwargs):
urlopener = mercurial.url.opener_(*args, **kwargs)
urlopener.add_handler(u2k.HTTPKerberosAuthHandler())
return urlopener
mercurial.url.opener = opener
Do you think something similar would work, with your handlers in place
of urllib2_kerberos.HTTPKerberosAuthHandler? Just an idea, I haven't
looked closely to see how well they match up.
Other things to think about:
- What does the [auth] configuration look like? It should be illegal
to set a username.
- What would be involved with supporting SSPI for 'hg serve'?
----
David Pope
More information about the Mercurial-devel
mailing list