hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Karl Wright <daddy...@gmail.com>
Subject Re: HTTPCLIENT-1394: Support for Native windows Negotiate/NTLM via JNA
Date Fri, 28 Mar 2014 12:58:34 GMT
Hi Malcolm,

To create a patch:

-- install an svn client; I use one from SlikSubversion
-- check out the svn repository in question:

svn co https://svn.apache.org/repos/asf/httpcomponents/httpclient/trunk

-- make your change in that tree
-- in the httpclient/trunk directory, do the command:

svn diff >mypatch.patch

To create a ticket, go to https://issues.apache.org/jira, and register.
Anybody can register.  Create a ticket in the HTTPCLIENT queue, providing a
description.  Then attach your patch file.

Thanks,
Karl



On Fri, Mar 28, 2014 at 8:50 AM, Malcolm Smith <
malcolm_smith@standardlife.com> wrote:

> Hi Karl,
>
> I am afraid I am completely unfamiliar with this process. I assume I
> should follow the instructions here for getting hold of the SVN repo:
>
>
> http://wiki.apache.org/HttpComponents/HttpComponentsReleaseProcess?action=show&redirect=HttpComponentsCoreReleaseProcess
>
> How do I go about creating a ticket? Can you point me at some
> documentation?
>
> Thanks,
>
> Malcolm.
>
>
> -----Original Message-----
> From: Karl Wright [mailto:daddywri@gmail.com]
> Sent: 28 March 2014 11:49
> To: HttpComponents Project
> Subject: Re: HTTPCLIENT-1394: Support for Native windows Negotiate/NTLM
> via JNA
>
> Hi Malcolm,
>
> The right way to contribute a patch is to attach an svn diff to a ticket
> as a file.
>
> The original ticket has already been included in 4.4, so the proper way to
> do this is to create a new ticket, and attach the patch to it.
>
> Thanks,
> Karl
>
>
>
> On Fri, Mar 28, 2014 at 6:58 AM, Malcolm Smith <
> malcolm_smith@standardlife.com> wrote:
>
> > Hi,
> >
> > I was very interested in the "HTTPCLIENT-1394: Support for Native
> > windows Negotiate/NTLM via JNA" patch Ryan McKinley contributed to
> > HTTPCLIENT as it seemed it would perfect solve the issue many people
> > are encountering moving Kerberised Java clients to Win7. The issue
> > being that local admin users on
> > Win7 can't access the TGT via the usual GSSAPI method without running
> > the app as an Administrator (also a XP Compatibility mode flag fixes
> > it but neither are very satisfactory).
> >
> > I now have the patch up and running in our corporate environment and
> > it works perfectly, although I had to make a small change to the code.
> > Not being a participator in the HTTPCLIENT project I'm not sure what
> > the best way of contributing my patch back is. It is a very small
> modification.
> >
> > Within:
> > org.apache.http.impl.auth.win.WindowsNegotiateScheme.getToken(CtxtHand
> > le,
> > SecBufferDesc, String)
> > The third parameter must be the name of the servicePrincipal. In our
> > case this is of the form:
> >
> > HTTP/myserver.mycomp.com@REALM.MYCOMP.COM
> >
> > * "myserver.mycomp.com" is the host name of the server we want to
> > connect to
> > * "REALM.MYCOMP.COM" is the active directory realm.
> >
> > In order to provide this I have introduced the servicePrincipal in the
> > constructor to:
> >
> > public WindowsNegotiateScheme(final String scheme, String
> > servicePrincipal) {
> >         super();
> >
> >         this.scheme = (scheme == null) ? AuthSchemes.SPNEGO : scheme;
> >         this.challenge = null;
> >         this.continueNeeded = true;
> >         this.servicePrincipal = servicePrincipal;
> >     }
> >
> > And added it as a field so it can be passed into the getToken method
> calls.
> >
> >
> > And have also therefore introduced it into the factory so it can be
> > passed
> > down:
> >
> > public class WindowsNegotiateSchemeFactory implements
> > AuthSchemeProvider {
> >
> >         private String servicePrincipal;
> >
> >         public WindowsNegotiateSchemeFactory(String servicePrincipal)
> >         {
> >                 this.servicePrincipal = servicePrincipal;
> >         }
> >
> >     public AuthScheme create(final HttpContext context)
> >     {
> >         return new WindowsNegotiateScheme("Negotiate", servicePrincipal);
> >     }
> >
> > }
> >
> > I can then construct a client in the following way:
> >
> > HttpClientBuilder clientBuilder = HttpClientBuilder.create();
> > RequestConfig defaultRequestConfig = RequestConfig.custom()
> >     .setSocketTimeout(getTimeout())
> >     .setConnectTimeout(getTimeout())
> >     .setConnectionRequestTimeout(getTimeout())
> >     .build();
> > clientBuilder.setDefaultRequestConfig(defaultRequestConfig);
> >
> > BasicCredentialsProvider basicCredentialsProvider = new
> > BasicCredentialsProvider();
> > basicCredentialsProvider.setCredentials(AuthScope.ANY,
> > CurrentWindowsCredentials.get());
> >
> > Lookup<AuthSchemeProvider> authRegistry = new
> > Lookup<AuthSchemeProvider>() {
> >         @Override
> >         public AuthSchemeProvider lookup(String arg0)
> >         {
> >                 String servicePrincipal = "HTTP/" + host + "@
> > REALM.MYCOMPANY.COM";
> >                 return new
> WindowsNegotiateSchemeFactory(servicePrincipal);
> >         }
> >
> > };
> > clientBuilder.setDefaultCredentialsProvider(basicCredentialsProvider);
> > clientBuilder.setDefaultAuthSchemeRegistry(authRegistry);
> >
> > And we now have Kerberos authentication working perfectly for our
> > users with local admin rights running Java clients. Also the whole
> > Kerberos handshake seems must faster, and we can ditch all the usual
> > configuration that is required for GSSAPI. We will shortly be using this
> 'experimental'
> > patch in a production setting and I am confident that it is a robust
> > solution.
> >
> > I am happy to send Ryan the source I have modified if that helps, but
> > I thought that seeing as he had originally contributed the patch it
> > might be easier for Ryan to just update his code.
> >
> > Kind regards,
> >
> > Malcolm.
> >
> > Confidentiality - This email is confidential.
> > Not meant for you? - If you don't think this email is meant for you,
> > please let us know. Do not copy or forward the information it
> > contains, and delete this email from your system.
> > Views expressed - Any personal views or opinions expressed in this
> > email are the sender's, and do not necessarily reflect the views of
> > Standard Life group.
> > Monitoring - We filter and monitor emails to protect our systems and
> > to keep them running smoothly.
> > Emailing us - Email isn't a secure form of communication. If you want
> > to send us confidential information please send it by post. However,
> > if you do communicate with us by email on any subject, you are giving
> > us permission to email you back.
> > Phoning us - Calls may be monitored and/or recorded to protect both
> > you and us and help with our training. Call charges will vary.
> > Standard Life group - Standard Life group comprises Standard Life plc
> > and its subsidiaries. For more information on Standard Life group
> > visit our website http://www.standardlife.com/.
> > Standard Life plc (SC286832), Standard Life Assurance Limited
> > (SC286833) and Standard Life Employee Services Limited (SC271355) are
> > all registered in Scotland at Standard Life House, 30 Lothian Road,
> Edinburgh EH1 2DH.
> > Standard Life Assurance Limited is authorised by the Prudential
> > Regulation Authority and regulated by the Financial Conduct Authority
> > and the Prudential Regulation Authority.
> > For more information on Standard Life Assurance limited visit our
> > website http://www.standardlife.co.uk
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org For additional
> > commands, e-mail: dev-help@hc.apache.org
> >
> >
> Confidentiality - This email is confidential.
> Not meant for you? - If you don't think this email is meant for you,
> please let us know. Do not copy or forward the information it contains, and
> delete this email from your system.
> Views expressed - Any personal views or opinions expressed in this email
> are the sender's, and do not necessarily reflect the views of Standard Life
> group.
> Monitoring - We filter and monitor emails to protect our systems and to
> keep them running smoothly.
> Emailing us - Email isn't a secure form of communication. If you want to
> send us confidential information please send it by post. However, if you do
> communicate with us by email on any subject, you are giving us permission
> to email you back.
> Phoning us - Calls may be monitored and/or recorded to protect both you
> and us and help with our training. Call charges will vary.
> Standard Life group - Standard Life group comprises Standard Life plc and
> its subsidiaries. For more information on Standard Life group visit our
> website http://www.standardlife.com/.
> Standard Life plc (SC286832), Standard Life Assurance Limited (SC286833)
> and Standard Life Employee Services Limited (SC271355) are all registered
> in Scotland at Standard Life House, 30 Lothian Road, Edinburgh EH1 2DH.
> Standard Life Assurance Limited is authorised by the Prudential Regulation
> Authority and regulated by the Financial Conduct Authority and the
> Prudential Regulation Authority.
> For more information on Standard Life Assurance limited visit our website
> http://www.standardlife.co.uk
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message