UserConverter.decode NPE when deserializing default constructed UserImpl about vertx-auth HOT 8 CLOSED

The problem is UserImpl makes checks (like create a User without providing a principal) that the change allows to circumvent.

My opinion is VertxProfileManager in Pac4j shouldn't invoke an internal constructor in UserImpl. Instead, it should one of the creation methods in the User interface.

from vertx-auth.

I will submit a PR

from vertx-auth.

Submitted #658

from vertx-auth.

If an instance of UserImpl is constructed using the default constructor

@jpenglert this should not be done by user code. The default constructor is only present because it is required for ClusterSerializable implementations.

from vertx-auth.

@tsegismont understood that an instance of UserImpl should not be constructed using the default constructor by user code. However, is there any harm in updating the deserializing code to be more robust by handling null fields like the serializing code does?

from vertx-auth.

@tsegismont I made a PR for vertx-pac4j but that project looks pretty dead. If you know anyone over there maybe you could ping them?

Seems like vertx-pac4j may need to do a more in-depth re-work such that instead of extending UserImpl with Pac4jUser they use the io.vertx.ext.auth.authorization.Authorization interface instead?

from vertx-auth.

@jpenglert sorry, I don't know any maintainers personally and I'm not familiar with vertx-pac4j

Have you tried to look at the GH profile of the committers? Maybe someone shares an email address?

from vertx-auth.

@tsegismont no worries...one of the committers responded and merged my PR. Thanks again for your help on how to resolve this.

from vertx-auth.