You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Amit Pande <Am...@veritas.com.INVALID> on 2022/09/06 17:42:31 UTC
Customizing CorsFilter
Hello all,
I am currently using the Tomcat 9.0.65 (9.x) and looking at the possibility of extending the CorsFilter<https://tomcat.apache.org/tomcat-9.0-doc/config/filter.html#CORS_Filter>, 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://github.com/apache/tomcat/blob/9.0.65/java/org/apache/catalina/filters/CorsFilter.java#L712) for extension.
Thanks,
Amit
RE: [External] Re: Customizing CorsFilter
Posted by Amit Pande <Am...@veritas.com.INVALID>.
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-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [External] Re: Customizing CorsFilter
Posted by Mark Thomas <ma...@apache.org>.
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=https
>>>> %
>>>> 3A%2F%2Ftomcat.apache.org%2Ftomcat-9.0-doc%2Fconfig%2Ffilter.html%23
>>>> C
>>>> ORS_Filter&data=05%7C01%7CAmit.Pande%40veritas.com%7C05dd6e26b66
>>>> e
>>>> 49dcaced08da909b854b%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%7C0%7C63
>>>> 7
>>>> 981294884520628%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoi
>>>> V
>>>> 2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=UVYm
>>>> 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%2Fgi
>>>> t
>>>> hub.com%2Fapache%2Ftomcat%2Fblob%2F9.0.65%2Fjava%2Forg%2Fapache%2Fca
>>>> t
>>>> alina%2Ffilters%2FCorsFilter.java%23L712&data=05%7C01%7CAmit.Pan
>>>> d
>>>> e%40veritas.com%7C05dd6e26b66e49dcaced08da909b854b%7Cfc8e13c0422c4c5
>>>> 5
>>>> b3eaca318e6cac32%7C0%7C0%7C637981294884520628%7CUnknown%7CTWFpbGZsb3
>>>> d
>>>> 8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%
>>>> 7
>>>> C3000%7C%7C%7C&sdata=SaFrY7oHvHmErLFKaesA55hFPM9o7JiT%2F3M%2BCJ4
>>>> 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-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: [External] Re: Customizing CorsFilter
Posted by Amit Pande <Am...@veritas.com.INVALID>.
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?
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=https
>>> %
>>> 3A%2F%2Ftomcat.apache.org%2Ftomcat-9.0-doc%2Fconfig%2Ffilter.html%23
>>> C
>>> ORS_Filter&data=05%7C01%7CAmit.Pande%40veritas.com%7C05dd6e26b66
>>> e
>>> 49dcaced08da909b854b%7Cfc8e13c0422c4c55b3eaca318e6cac32%7C0%7C0%7C63
>>> 7
>>> 981294884520628%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoi
>>> V
>>> 2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=UVYm
>>> 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%2Fgi
>>> t
>>> hub.com%2Fapache%2Ftomcat%2Fblob%2F9.0.65%2Fjava%2Forg%2Fapache%2Fca
>>> t
>>> alina%2Ffilters%2FCorsFilter.java%23L712&data=05%7C01%7CAmit.Pan
>>> d
>>> e%40veritas.com%7C05dd6e26b66e49dcaced08da909b854b%7Cfc8e13c0422c4c5
>>> 5
>>> b3eaca318e6cac32%7C0%7C0%7C637981294884520628%7CUnknown%7CTWFpbGZsb3
>>> d
>>> 8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%
>>> 7
>>> C3000%7C%7C%7C&sdata=SaFrY7oHvHmErLFKaesA55hFPM9o7JiT%2F3M%2BCJ4
>>> 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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [External] Re: Customizing CorsFilter
Posted by Mark Thomas <ma...@apache.org>.
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=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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: [External] Re: Customizing CorsFilter
Posted by Amit Pande <Am...@veritas.com.INVALID>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Customizing CorsFilter
Posted by Mark Thomas <ma...@apache.org>.
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://tomcat.apache.org/tomcat-9.0-doc/config/filter.html#CORS_Filter>,
>> 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://github.com/apache/tomcat/blob/9.0.65/java/org/apache/catalina/filters/CorsFilter.java#L712)
>> 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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Customizing CorsFilter
Posted by Mark Thomas <ma...@apache.org>.
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://tomcat.apache.org/tomcat-9.0-doc/config/filter.html#CORS_Filter>, 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://github.com/apache/tomcat/blob/9.0.65/java/org/apache/catalina/filters/CorsFilter.java#L712) 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.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org