https://bz.apache.org/bugzilla/show_bug.cgi?id=64715
--- Comment #14 from Robert Rodewald <robert.rodew...@kopsis.com> --- (In reply to Christopher Schultz from comment #12) > Doesn't this tie the implementation class to Tomcata internals? It would be > nice to implement a CallbackHandler which can be built (and run) > independently of Tomcat classes. Or do I have an unrealistic expectation, > here, of the way CallbackHandlers would be implemented? Is it possible for > them to be container-agnostic? In my understanding the CallbackHandler cannot be decoupled from Tomcat (the "runtime" in the JASPIC specification), because it represents the "glue code" to the runtime. A replacement of the implementing class is not intended anywhere in the JASPIC specification as far as I can see, but is a nice thing to have. This way the user can implement some very special non-standard Callbacks. The inner workings of the CallbackHandler are not well defined in the specs, neither are the standard callbacks. For example the PasswordValidationCallback: - Shall it set the principal in the client subject or shall it just return true or false for the getResult method? - The password field may be null (as per spec) but how should the CallbackHandler handle this case? Set the roles/groups of the principal anyway? -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
