Vertx-web: AuthorizationAuthHandler is in package access level

Created on 20 May 2018  路  5Comments  路  Source: vert-x3/vertx-web

Version

  • vert.x core: 3.5.1
  • vert.x web: 3.5.1

Context

I have encountered a problem trying to implement an AuthHandler extending the AuthorizationAuthHandler. The problem is that the class AuthorizationAuthHandler is declared in the package access level. Is that intentional or just a little lapse? If it had been declared in public access level as most of the other classes there should not be a problem.

Regards

question

Most helpful comment

Then I think there perhaps is a need to move both the classes AuthHandlerImpl and AuthorizationAuthHandler out of the impl packages or whatever strategy is applicable to make them extendable. I do not know much about the impact of Java-modules. The only thing I know currently is that these two classes seems to include the basis for many variants of custom auth-handlers. Without being able to inherit from them as they are constructed today I will have to recreate and maintain the same logic in my custom auth-handlers. For one of my scenarios I had to create a token auth-handler quite similar to the class JWTAuthHandlerImpl but I could not do it in the same manner since the constructors for the class AuthorizationAuthHandler were in package access level. Now I have inherited directly from the class AuthHandlerImpl for some custom auth-handlers but are that also going to be a problem with vertx-web and Java-modules?

All 5 comments

This code was extracted from a couple of auth handlers as was supposed to be an implementation details (hence the reason why it's not public) what do you need specifically from it to be public?

No need for it to be public but at least protected so it can be used or overridden in an inherited class not residing in the same package.

It's not as simple as that, specially with java >=9 module we will need to start listing what each module exports publicly and not, and currently the non enforcing way we're using is that everything inside impl packages is not public. So say that the class is made public you won't be able to use it with modules as it does not get in the exports section of the module. So my question was, what functionality are you missing and we will see what we can move to the public side (meaning outside the impl)

Then I think there perhaps is a need to move both the classes AuthHandlerImpl and AuthorizationAuthHandler out of the impl packages or whatever strategy is applicable to make them extendable. I do not know much about the impact of Java-modules. The only thing I know currently is that these two classes seems to include the basis for many variants of custom auth-handlers. Without being able to inherit from them as they are constructed today I will have to recreate and maintain the same logic in my custom auth-handlers. For one of my scenarios I had to create a token auth-handler quite similar to the class JWTAuthHandlerImpl but I could not do it in the same manner since the constructors for the class AuthorizationAuthHandler were in package access level. Now I have inherited directly from the class AuthHandlerImpl for some custom auth-handlers but are that also going to be a problem with vertx-web and Java-modules?

Hi @pmlopes thanks for your support.

I'm having the same difficulty today with this class since I'm trying to create a custom implementation by taking advantage of the behavior that AuthorizationAuthHandler has. For example: I'm also creating an auth handler using the bearer token, similar to JWT but in a simpler way. Are you considering making this class public or do we consider extending from AuthHandlerImp?

Best.

Was this page helpful?
0 / 5 - 0 ratings