eozmen410 commented on pull request #442: URL: https://github.com/apache/wicket/pull/442#issuecomment-672731231
Hi @svenmeier! Thanks for your review. :) > Are you sure two separate listeners are the best solution? COEP is a single header only and to quote [https://web.dev/coop-coep/]: "Use a combination of COOP and COEP HTTP headers to opt a web page into a special cross-origin isolated state." I wonder whether a single listener would be better from the usage perspective. Here's our reasoning behind having 2 separate listeners: * We chose to have two separate listeners for COOP and COEP because they are independent mechanisms that can be deployed separately. Setting COEP headers ensures that a document can only load resources from the same origin, or resources explicitly marked as loadable from another origin. This means that, when COEP is enabled, all the resources loaded from cross-origin need to support CORS and will be blocked if they don't. COOP on the other hand does not require CORS support. It's sufficient to set the COOP response header to process-isolate your document so potential attackers can't access your global object if they were opening a pop-up (preventing XS-leaks). If the application doesn't depend on cross-origin interactions between top-level windows, there should be no observable effect of enabling COOP, while enabling COEP might require some refactoring on the Wicket user's part if they are using cross-origin resources. You're right in pointing out that enabling COOP and COEP together is the best practice for cross-origin isolation. We thought we would give Wicket users more flexibility if they wanted to enable them separately for any reason. Having a single listener for both COOP and COEP would also achieve the same results, if we provide flexible ways to configure the listener. In that case, while we can provide a single configuration, it might be somewhat confusing to have `CoepMode` and `CoopMode` especially since the acronyms COEP and COOP are already fairly confusing! Having separate configs also has less risk of introducing non-backward compatible configs on that object. If you think having a single listener is better from a usability perspective, we can change our implementation to merge COOP and COEP into a single listener and provide two separate config objects and handy constructors for the listener that can receive either `CooepConfiguration` or `CoopConfiguration` or both. WDYT? ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
