Thank you Mark for the inputs. Agree on your points about enhancing the CORS filter for extension.
And, yes, thread-safety could be tricky for any dynamic configuration. Could you please share more details on "web.xml" changes and dynamic reload of applications? Some documentation link or something would be helpful. I couldn't find anything online. Also, wanted to check with the community - how they handle such a requirement where the CORS allowed origins can change over time -presumably infrequently but still. Manual edit of web.xml and leverage the reload of apps? Or server restart? What is the best/safe way to edit the main web.xml? Thanks, Amit -----Original Message----- From: Mark Thomas <ma...@apache.org> Sent: Wednesday, September 7, 2022 1:37 AM To: users@tomcat.apache.org Subject: [External] Re: Customizing CorsFilter On 07/09/2022 07:31, Mark Thomas wrote: > On 06/09/2022 18:42, Amit Pande wrote: >> Hello all, >> >> I am currently using the Tomcat 9.0.65 (9.x) and looking at the >> possibility of extending the >> CorsFilter<https://nam12.safelinks.protection.outlook.com/?url=https% >> 3A%2F%2Ftomcat.apache.org%2Ftomcat-9.0-doc%2Fconfig%2Ffilter.html%23C >> ORS_Filter&data=05%7C01%7CAmit.Pande%40veritas.com%7C05dd6e26b66e >> 49dcaced08da909b854b%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%7C0%7C637 >> 981294884520628%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV >> 2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=UVYmM >> wnGj19cJCuA0Nlc%2Few5SMMGF2nXyJiFasO11hc%3D&reserved=0>, >> specially the configuration part. >> >> I am looking at the ability to initialize the parameters of Tomcat's >> CorsFilter from a source other than "web.xml" (one under >> TOMCAT_INSTALL_DIR/conf - so that settings apply for all applications >> inside this web server). E.g., the configuration could a key-value >> data store (or a simple property file). >> >> Hand-editing the "web.xml" could be calling for trouble if not done >> carefully. And AFAICT, there isn't any tooling/interface to allow >> easily and reliably editing the "web.xml". >> >> Also, ability to poll the external configuration source allows >> dynamically reload the CorsFilter configuration without requiring the >> Tomcat restart. In certain product deployments, web server is just a >> part and having to restart for some configuration changes to take >> effect isn't desired, though isn't not a must-have. >> >> >> I was looking for something like: >> >> public class CustomCorsFilter extends CorsFilter { >> >> @Override >> public void init() { >> >> // load configuration from some other persistence store // initialize >> fields from super class (which are then used in the actual CORS >> validation) } >> >> @Override >> public void doFilter(ServletRequest request, ServletResponse >> response, FilterChain chain) >> throws IOException, ServletException { >> super.doFilter(request, response, chain); >> } >> >> } >> >> // Additionally, the init can be called periodically which could >> re-initialize the fields from CorsFilter class. >> >> However, currently, the configuration fields are private and there >> are no setters. >> >> Before I explore the option of looking for adding interface to "edit" >> the web.xml, wanted to check if it's possible to update the >> CorsFilter and make some methods protected (e.g. >> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit >> hub.com%2Fapache%2Ftomcat%2Fblob%2F9.0.65%2Fjava%2Forg%2Fapache%2Fcat >> alina%2Ffilters%2FCorsFilter.java%23L712&data=05%7C01%7CAmit.Pand >> e%40veritas.com%7C05dd6e26b66e49dcaced08da909b854b%7Cfc8e13c0422c4c55 >> b3eaca318e6cac32%7C0%7C0%7C637981294884520628%7CUnknown%7CTWFpbGZsb3d >> 8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7 >> C3000%7C%7C%7C&sdata=SaFrY7oHvHmErLFKaesA55hFPM9o7JiT%2F3M%2BCJ4s >> WgY%3D&reserved=0) >> for extension. > > Refactoring the CorsFilter to make it extensible is certainly an option. > Some things to keep in mind: > > - Increasing the visibility of methods is unlikely to be controversial > > - Getters and setters are preferred to non-private fields > > - Any changes need to be backwards compatible > > - Supporting dynamic reconfiguration means ensuring that any such > configuration changes are made in a thread-safe manner. Note that the > configuration could change in the middle of a request being processed > by the filter. > > That last point is the potentially tricky one. My concern would be the > performance impacts of any measures taken to ensure thread safety. Something that occurred to me just after I pressed send was that Tomcat has a built-in, general solution to the reconfiguration problem. In a default configuration, changes to web.xml will trigger a graceful reload of the web application. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
