Quantcast

Java 9 java.net.Authenticator api change

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Java 9 java.net.Authenticator api change

Adam T Anderson


Hello,

In CXF we use org.apache.cxf.transport.http.ReferencingAuthenticator to
create a chain of org.apache.cxf.transport.http.CXFAuthenticators.
Every time we add a new CXFAuthenticator we set the new link as the default
authenticator and link to the old head. This is so we can delegate the
static call Authenticator.requestPasswordAuthentication() to a non-static
list of instances of CXFAuthenticator.

When Authenticator.requestPasswordAuthentication() is called, the JDK pass
es in the requesting host, port, protocol, scheme etc... which get set as
private variables on the current head ReferencingAuthenticator and then
ReferencingAuthenticator.getPasswordAuthentication() gets called.
ReferencingAuthenticator.getPasswordAuthentication() uses deep reflection
to copy the private non-static variables of java.net.Authenticator from the
head to each link in the chain before calling getPasswordAuthentication()
on each of the wrapped CXFAuthenticators.

This will no longer work in Java 9 with the new jigsaw module changes. We
need a mechanism in Java 9 to copy those private variables from one
authenticator to another for our Authenticator chain to work.

The 2 options I see are:

1. Request Oracle to add setter methods for each variable (there are
already getters) to the Authenticator API.
2. Request Oracle to add a "copyState" method to the Authenticator API
which copies all private non-static variables of one Authenticator to
another.

Right now I am leaning towards options #2.

What are your thoughts? Are there any other options to make this work with
Java 9?
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Java 9 java.net.Authenticator api change

Sergey Beryozkin
Administrator
Hi

Request for Option2 (or something similar like clone()) is more likely
to be accepted IMHO

Cheers, Sergey
On 17/05/17 23:09, Adam T Anderson wrote:

>
>
> Hello,
>
> In CXF we use org.apache.cxf.transport.http.ReferencingAuthenticator to
> create a chain of org.apache.cxf.transport.http.CXFAuthenticators.
> Every time we add a new CXFAuthenticator we set the new link as the default
> authenticator and link to the old head. This is so we can delegate the
> static call Authenticator.requestPasswordAuthentication() to a non-static
> list of instances of CXFAuthenticator.
>
> When Authenticator.requestPasswordAuthentication() is called, the JDK pass
> es in the requesting host, port, protocol, scheme etc... which get set as
> private variables on the current head ReferencingAuthenticator and then
> ReferencingAuthenticator.getPasswordAuthentication() gets called.
> ReferencingAuthenticator.getPasswordAuthentication() uses deep reflection
> to copy the private non-static variables of java.net.Authenticator from the
> head to each link in the chain before calling getPasswordAuthentication()
> on each of the wrapped CXFAuthenticators.
>
> This will no longer work in Java 9 with the new jigsaw module changes. We
> need a mechanism in Java 9 to copy those private variables from one
> authenticator to another for our Authenticator chain to work.
>
> The 2 options I see are:
>
> 1. Request Oracle to add setter methods for each variable (there are
> already getters) to the Authenticator API.
> 2. Request Oracle to add a "copyState" method to the Authenticator API
> which copies all private non-static variables of one Authenticator to
> another.
>
> Right now I am leaning towards options #2.
>
> What are your thoughts? Are there any other options to make this work with
> Java 9?
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Java 9 java.net.Authenticator api change

Adam T Anderson

Hi,

That is what I was thinking as well. It would be nice to have support for multiple Authenticators in the JDK but I think that is unlikely for Java 9. It could be something that we pursue in Java 10.

Thanks, Adam

Sergey Beryozkin ---05/18/2017 03:58:39 AM---Hi Request for Option2 (or something similar like clone()) is more likely

From: Sergey Beryozkin <[hidden email]>
To: [hidden email]
Date: 05/18/2017 03:58 AM
Subject: Re: Java 9 java.net.Authenticator api change





Hi

Request for Option2 (or something similar like clone()) is more likely
to be accepted IMHO

Cheers, Sergey
On 17/05/17 23:09, Adam T Anderson wrote:

>
>
> Hello,
>
> In CXF we use org.apache.cxf.transport.http.ReferencingAuthenticator to
> create a chain of org.apache.cxf.transport.http.CXFAuthenticators.
> Every time we add a new CXFAuthenticator we set the new link as the default
> authenticator and link to the old head. This is so we can delegate the
> static call Authenticator.requestPasswordAuthentication() to a non-static
> list of instances of CXFAuthenticator.
>
> When Authenticator.requestPasswordAuthentication() is called, the JDK pass
> es in the requesting host, port, protocol, scheme etc... which get set as
> private variables on the current head ReferencingAuthenticator and then
> ReferencingAuthenticator.getPasswordAuthentication() gets called.
> ReferencingAuthenticator.getPasswordAuthentication() uses deep reflection
> to copy the private non-static variables of java.net.Authenticator from the
> head to each link in the chain before calling getPasswordAuthentication()
> on each of the wrapped CXFAuthenticators.
>
> This will no longer work in Java 9 with the new jigsaw module changes. We
> need a mechanism in Java 9 to copy those private variables from one
> authenticator to another for our Authenticator chain to work.
>
> The 2 options I see are:
>
> 1. Request Oracle to add setter methods for each variable (there are
> already getters) to the Authenticator API.
> 2. Request Oracle to add a "copyState" method to the Authenticator API
> which copies all private non-static variables of one Authenticator to
> another.
>
> Right now I am leaning towards options #2.
>
> What are your thoughts? Are there any other options to make this work with
> Java 9?
>




Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Java 9 java.net.Authenticator api change

Moritz Bechler
Hi,

>
> That is what I was thinking as well. It would be nice to have support
> for multiple Authenticators in the JDK but I think that is unlikely for
> Java 9. It could be something that we pursue in Java 10.
>

Not exactly sure whether that completely mitigates the problem (as far
as I can tell the chaining is to allow CXF to inject an authenticator
and keep one set up by the user, but I might have missed something), but
in case you are not aware - Java 9 is finally going to have per
HttpURLConnection Authenticators - I guess injecting a CXFAuthenticator
per instance and delegating to the default one could be a solution:

https://bugs.openjdk.java.net/browse/JDK-8169495


regards

Moritz

--
AgNO3 GmbH & Co. KG, Sitz Tübingen, Amtsgericht Stuttgart HRA 728731
Persönlich haftend:
Metagesellschaft mbH, Sitz Tübingen, Amtsgericht Stuttgart HRB 744820,
Vertreten durch Joachim Keltsch
Loading...