RE: [External] Re: Customizing CorsFilter

2022-09-07 Thread Amit Pande
Thank you, again! 😊

-Original Message-
From: Mark Thomas  
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 
> 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 
>> 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.
>&g

Re: [External] Re: Customizing CorsFilter

2022-09-07 Thread Mark Thomas

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 
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 
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
8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL

RE: [External] Re: Customizing CorsFilter

2022-09-07 Thread Amit Pande
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  
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 
> 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 per

Re: [External] Re: Customizing CorsFilter

2022-09-07 Thread Mark Thomas

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 
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 e

RE: [External] Re: Customizing CorsFilter

2022-09-07 Thread Amit Pande
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  
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 processe

Re: Customizing CorsFilter

2022-09-06 Thread Mark Thomas




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, 
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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: Customizing CorsFilter

2022-09-06 Thread Mark Thomas

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,
 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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Customizing CorsFilter

2022-09-06 Thread Amit Pande
Hello all,

I am currently using the Tomcat 9.0.65 (9.x) and looking at the possibility of 
extending the 
CorsFilter,
 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