[
https://issues.apache.org/jira/browse/HTTPCLIENT-1582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17319165#comment-17319165
]
Michael Osipov edited comment on HTTPCLIENT-1582 at 4/12/21, 9:09 AM:
----------------------------------------------------------------------
We have a customer who reported the following related issue : The Integrated
Windows Authentication in RTC clients (both Eclipse and Visual Studio) doesn't
work when the user's token size is higher than 12288 bytes, because the Apache
HTTP library used by RTC uses this hardcoded constant that is too small.
Customer would like to submit a pull request for your team.
Indeed they found a solution , but it first needs to be fixed in Apachen and
then , the RTC development team would deliver a final solution with that fix.
h5. The patch does not modify the Sspi.MAX_TOKEN_SIZE constant in JNA.
h5. It adds a change to
org.apache.http.impl.auth.win.WindowsNegotiateScheme#getToken in order to
either use the existing Sspi.MAX_TOKEN_SIZE constant or, when present use
instead the org.apache.http.maxKerberosTokenSize property.
h5. This allows specifying for example
"-Dorg.apache.http.maxKerberosTokenSize=32767" on the Java command line (or in
eclipse.ini, scm.ini, etc.) in order to allocate a bigger buffer to fit the
Kerberos token.
Could you please let us know how to proceed to request this fix, or if updating
the bug description is enough.
Thank you very much in advance.
was (Author: [email protected]):
h5. Hello,
h5. {color:#080707}We have a customer who reported the following related issue
: The Integrated Windows Authentication in RTC clients (both Eclipse and Visual
Studio) doesn't work when the user's token size is higher than 12288 bytes,
because the Apache HTTP library used by RTC uses this hardcoded constant that
is too small. Customer would like to submit a pull request for your team.
{color}
{color:#080707}Indeed they found a solution , but it first needs to be fixed in
Apachen and then , the RTC development team would deliver a final solution with
that fix.{color}
h5. The patch does not modify the Sspi.MAX_TOKEN_SIZE constant in JNA.
h5. It adds a change to
org.apache.http.impl.auth.win.WindowsNegotiateScheme#getToken in order to
either use the existing Sspi.MAX_TOKEN_SIZE constant or, when present use
instead the org.apache.http.maxKerberosTokenSize property.
h5. This allows specifying for example
"-Dorg.apache.http.maxKerberosTokenSize=32767" on the Java command line (or in
eclipse.ini, scm.ini, etc.) in order to allocate a bigger buffer to fit the
Kerberos token.
Could you please let us know how to proceed to request this fix, or if updating
the bug description is enough.
Thank you very much in advance.
> SSPI-based auth might fail if output token size is too small
> ------------------------------------------------------------
>
> Key: HTTPCLIENT-1582
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1582
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: HttpClient (classic)
> Affects Versions: 4.4 Beta1
> Reporter: Michael Osipov
> Priority: Major
> Labels: stuck, volunteers-wanted
> Fix For: Stuck
>
>
> It might happen that a user has many groups, this makes the output token
> bigger. It might exceed the limit defined by JNA. Refer to JNA's issue
> [261|https://github.com/twall/jna/issues/261].
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
