Change Details

= Background Information In order to deprecate RESTBase some of its logic need to be re-implemented in order to have full-feature parity. For #page_content_service one of the components is the [[ https://github.com/wikimedia/restbase/blob/master/lib/security_response_header_filter.js | lib/security_response_header_filter.js ]] filter. == Possible solutions - Implement a shared JavaScript library and apply it to all #page_content_service endpoints. - It's basically a copy+paste from restbase to the other NodeJS services. - Relatively easy transition for NodeJS services that should install a new npm package - Introduce a maintenance burden for all NodeJS services that have to implement the Security Response Header Filter in the application layer - Implement the security response header filter in the envoy layer - Avoid having to re-create this as a JavaScript library and the maintenance burden of having it applied to all NodeJs services. - This filter makes more sense to be applied on the API Gateway / envoy layer and not in the application layer == Open questions - Can/Should this really be handled by envoy or any API Gateway? === Acceptance Criteria - [ ] Current NodeJS services that depends on `lib/security_response_header_filter.js` can apply this logic without RESTBase

== Background Information In order to deprecate RESTBase some of its logic need to be re-implemented in order to have full-feature parity. For #page_content_service one of the components is the [[ https://github.com/wikimedia/restbase/blob/master/lib/security_response_header_filter.js | lib/security_response_header_filter.js ]] filter. == Possible solutions - Implement a shared JavaScript library and apply it to all #page_content_service endpoints. - It's basically a copy+paste from restbase to the other NodeJS services. - Relatively easy transition for NodeJS services that should install a new npm package - Introduce a maintenance burden for all NodeJS services that have to implement the Security Response Header Filter in the application layer - Implement the security response header filter in the envoy layer - Avoid having to re-create this as a JavaScript library and the maintenance burden of having it applied to all NodeJs services. - This filter makes more sense to be applied on the API Gateway / envoy layer and not in the application layer == Open questions - Can/Should this really be handled by envoy or any API Gateway? == Acceptance Criteria - [ ] Current NodeJS services that depends on `lib/security_response_header_filter.js` can apply this logic without RESTBase

== Background Information In order to deprecate RESTBase some of its logic need to be re-implemented in order to have full-feature parity. For #page_content_service one of the components is the [[ https://github.com/wikimedia/restbase/blob/master/lib/security_response_header_filter.js | lib/security_response_header_filter.js ]] filter. == Possible solutions - Implement a shared JavaScript library and apply it to all #page_content_service endpoints. - It's basically a copy+paste from restbase to the other NodeJS services. - Relatively easy transition for NodeJS services that should install a new npm package - Introduce a maintenance burden for all NodeJS services that have to implement the Security Response Header Filter in the application layer - Implement the security response header filter in the envoy layer - Avoid having to re-create this as a JavaScript library and the maintenance burden of having it applied to all NodeJs services. - This filter makes more sense to be applied on the API Gateway / envoy layer and not in the application layer == Open questions - Can/Should this really be handled by envoy or any API Gateway? === Acceptance Criteria - [ ] Current NodeJS services that depends on `lib/security_response_header_filter.js` can apply this logic without RESTBase