On Wed, 11 Mar 2026 13:30:37 GMT, Vishva N <[email protected]> wrote: > ### Problem > In a large java project with multiple third party dependencies, there is a > case where the default **Authenticator** set by the java project owner is > overridden by the third party dependency jars. > > ### Example > While using **Google Big Query JDBC Jar**, If proxy username property is > present in the connection url, the **default authenticator is reset** by a > code piece in the jar without any checks for existing authenticator. > > ### Solution > Since, Authenticator is set on JVM level, the modification should provide > **access control capability to the java project owner**. > > ### Changes > In java.net.Authenticator class, an AccessChecker class is initialized on > class loading. By default, **java.net.AuthenticatorModifyAccessChecker** is > loaded. The Java project owner can extend this class and implement their own > custom implementation for **canModifyAuthenticator()** method. Java project > owner should supply the custom class name in > _"**authenticator.modify.access.checker.class**"_ system property which will > be initialized on class loading time. > > ### Result > This change will give access modification control for the Java Project owner. > The project owner can just skip the setDefault() call by return false in > canModifyAuthenticator() method or can throw error according to their need.
The fix proposed here doesn't look right. >While using Google Big Query JDBC Jar, If proxy username property is present >in the connection url, the default authenticator is reset by a code piece in >the jar without any checks for existing authenticator. This seems wrong and is the root of the issue, so I would suggest fixing the behaviour of that jar instead. ------------- PR Comment: https://git.openjdk.org/jdk/pull/30193#issuecomment-4039685398
