Thank you, again! 😊 -----Original Message----- From: Mark Thomas <ma...@apache.org> Sent: Wednesday, September 7, 2022 6:31 AM To: users@tomcat.apache.org Subject: Re: [External] Re: Customizing CorsFilter
On 07/09/2022 12:22, Amit Pande wrote: > Thank you, Mark! Will do some more research on this and see if I can leverage > this. > > However, are we still okay refactoring the CorsFilter for extension? Yes, I am sure the committers will consider any such proposal. Mark > > Thanks, > Amit > > > > -----Original Message----- > From: Mark Thomas <ma...@apache.org> > Sent: Wednesday, September 7, 2022 6:18 AM > To: users@tomcat.apache.org > Subject: Re: [External] Re: Customizing CorsFilter > > On 07/09/2022 11:42, Amit Pande wrote: >> 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. > > The documentation is rather sparse. > > See conf/web.xml and look at the nested WatchedResource elements. > > If a reload of a running application is triggered the following happens: > - new requests are allowed but made to wait > - existing requests are allowed to complete > - the web application is stopped > - the web application is started (picking up any new configuration) > - any waiting new requests are allowed to proceed > > By default, any open sessions will be lost. If using the > StandardManager you can configure it to persist session across web > application (and > Tomcat) restarts. > >> 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? > > Personally, I'd just edit web.xml but I only manage my own very lightly used > web applications. Provided you don't have long running requests I'd recommend > that approach. > > For editing web.xml, if you want to be sure use a schema aware XML editor. > That should a) ensure it is syntactically correct and b) provide > auto-completion options. I normally use an IDE. > > Mark > > >> >> 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=http >>>> s >>>> % >>>> 3A%2F%2Ftomcat.apache.org%2Ftomcat-9.0-doc%2Fconfig%2Ffilter.html%2 >>>> 3 >>>> C >>>> ORS_Filter&data=05%7C01%7CAmit.Pande%40veritas.com%7C05dd6e26b6 >>>> 6 >>>> e >>>> 49dcaced08da909b854b%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%7C0%7C6 >>>> 3 >>>> 7 >>>> 981294884520628%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjo >>>> i >>>> V >>>> 2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=UVY >>>> m M 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%2Fg >>>> i >>>> t >>>> hub.com%2Fapache%2Ftomcat%2Fblob%2F9.0.65%2Fjava%2Forg%2Fapache%2Fc >>>> a >>>> t >>>> alina%2Ffilters%2FCorsFilter.java%23L712&data=05%7C01%7CAmit.Pa >>>> n >>>> d >>>> e%40veritas.com%7C05dd6e26b66e49dcaced08da909b854b%7Cfc8e13c0422c4c >>>> 5 >>>> 5 >>>> b3eaca318e6cac32%7C0%7C0%7C637981294884520628%7CUnknown%7CTWFpbGZsb >>>> 3 >>>> d >>>> 8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D >>>> % >>>> 7 >>>> C3000%7C%7C%7C&sdata=SaFrY7oHvHmErLFKaesA55hFPM9o7JiT%2F3M%2BCJ >>>> 4 >>>> s >>>> 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 >> > > --------------------------------------------------------------------- > 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 > --------------------------------------------------------------------- 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
