Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
erp5 erp5
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Labels
    • Labels
  • Merge requests 139
    • Merge requests 139
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Operations
    • Operations
    • Environments
  • Analytics
    • Analytics
    • CI/CD
    • Repository
    • Value Stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Members
    • Members
  • Activity
  • Graph
  • Jobs
  • Commits
Collapse sidebar
  • nexedi
  • erp5erp5
  • Merge requests
  • !1056

Closed
Created Feb 19, 2020 by Vincent Pelletier@vpelletierOwner
  • Report abuse
Report abuse

Set response headers

  • Overview 10
  • Commits 2
  • Changes 8

The intent of this change is to be able to manage certain HTTP response headers based on traversed documents.

Here is a (non-exchaustive) list of headers which are considered for this feature: Content-Security-Policy, X-Content-Type-Options, X-Frame-Options, Referrer-Policy.

It is possible to extend (for comma-separated headers), replace and remove headers set by a parent document, to allow (for example) ERP5 to be protected by a given Content-Security-Policy rule set configured on its ERP5Site instance, but a contained website (web_site_module/foo) would be protected by a (possibly completely) different rule set for the same header.

The main design principle is to always have a sane fallback value & behaviour for every declared header, in case any error happen when the associated script is executed: such error could otherwise either cause the protection to be absent (exception caught without fallback), or prevent the issue from being fixed (exception not caught, preventing traversal).

This change has no effect on normal control of these headers: any script with access to current HTTPResponse object can read/add/remove/replace any header set in this way. It is not intended to replace immediate-context-dependent header generation, but rather to allow adding response headers for every single page published under (in publication traversal subtree sense) a specific object.

This change has no effect on normal document traversal (ex: restrictedTraverse), only on publication traversal.

To make the API easily available on many document types, I'm reworking class inheritance of Base/Folder, which is quite delicate. Using a test I exctracted the value of all Folder class properties to compare before & after and besides the new API the only changes I see are:

Attribute Before After My comment
Description method from Products/CMFCore/PortalFolder.py method from ERP5Type/Base.py Looks like progress
getId method from OFS/SimpleItem ERP5 accessor Looks like progress
getId__roles__ None PermissionRole object Looks like progress
icon '' method from Products/CMFCore/DynamicType.py Do we care ?

Some maybe-not-obvious attention points:

  • there is no UI (only an API). Does it need one ?
  • the rules are intended to be committed along with the document they are attached to (when such document is itself committed)
  • updating the rules attached to known-but-not-committed documents (ex: an instance with multiple ERP5JS websites, and the rules are set by generic code) would be done using upgrader constraints, matching such document in whatever way is applicable (for Web Sites it can be a layout property comparison, for example)

/cc @romain @jerome @tb @georgios.dagkakis

Assignee
Assign to
Reviewer
Request review from
None
Milestone
None
Assign milestone
Time tracking
Source branch: set_response_headers
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7