Hi! I would start with some experiments based on given information in order to figure out the better approach. If I have some questions/problems I'll write to this thread shortly. There are also your comments on github, I'll review them and prepare fixes.
P.S. Thank you for your confidence in me. I'm very happy to continue working on this project. Fjodor 2015-07-03 23:48 GMT+03:00 Mark Thomas <ma...@apache.org>: > On 03/07/2015 18:55, Fjodor Vershinin wrote: > > > For example the way how we handle module configurations. What do > > you think about my proposal to use Provider based config? > > OK. We need the configuration settings in the ServerAuthModule > implementations. It is pretty clear from the API that those settings are > meant to be passed via the options Map in initialize(). > > initialize() is called from the constructor of TomcatServerAuthContext. > The options Map is an argument that constructor. Question 1 why pass in > the module and all the other parameters to the constructor when you > coudl configure the module before calling the constructor and just pass > in the configured module? > > That constructor is called from TomcatAuthConfig.getAuthContext() which > passes in a properties Map. It looks as if the intention is that that > properties map contains the configuration settings for the module(s). It > would be reasonable to create a new Map, add those properties, add any > internal properties (like the Realm name) and pass the newly created Map > to the module. That has the added bonus (hopefully - it depends exactly > on the properties) of isolating the module form any later changes the > caller may make. > > TomcatAuthConfig.getAuthContext() is called from > JaspicAuthenticator.authenticate(). A quick aside here. How many of the > calls in that method might change their return values between different > requests? Any that will not would be better placed in start() for better > performance. > > Getting back to configuration, the JaspicAuthenticator has the > authProperties Map. If this Map were populated with the necessary > configuration settings, we can now see a path to getting this to the > ServerAuthModule where they are required. > > server.xml is processed by the Digester. Understanding how that works > can take a little while. The short version is is uses introspection to > set properties on objects and we can use this to set configuration > settings on the JaspicAuthenticator - in exactly the same way as we > currently do for the BasicAuthenticator, DigestAuthenticator etc. This > has the added bonus that as long as we keep the attribute names the > same, users can migrate their settings to use JASPIC simply by changing > the name of the Authenticator class they specify in server.xml / > context.xml. > > For this to work, we need to be able to put all the configuration > settings for JaspicAuthenticator in the authProperties Map. Luckily we > don;t need to define every possible setting - the digest supports > generic methods. If you add setProperty(String, String) and > getProperty(String) methods to the JaspicAuthenticator then the Digester > will do the rest. > > With all the information above you should have what you need to get > settings from a JaspicAuthenticator in server.xml / context.xml all the > way to the ServerAuthModule. If you need any help - particularly around > the digester or configuring the authenticator in server.xml / > context.xml just ask. > > > Finally, feel free to ignore all of the above and go a different route > but be prepared to justify why you think the different route is beter. > > > HTH and have a good weekend, > > Mark > > P.S. Congratulations on passing your mid-term. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > > -- Thanks, Fjodor
