[
https://issues.apache.org/jira/browse/TAP5-2835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18097268#comment-18097268
]
ASF subversion and git services commented on TAP5-2835:
-------------------------------------------------------
Commit 7ab8a7992bf2cfe38b35ca50aa3128eacf5b04f0 in tapestry-5's branch
refs/heads/master from Ben Weidig
[ https://gitbox.apache.org/repos/asf?p=tapestry-5.git;h=7ab8a7992 ]
TAP5-2835: ContextAssetProtectionRule chain added, don't serve source maps in
prod
> JavaScript source mapes (*.map) shouldn't be served by default when running
> in production mode
> ----------------------------------------------------------------------------------------------
>
> Key: TAP5-2835
> URL: https://issues.apache.org/jira/browse/TAP5-2835
> Project: Tapestry 5
> Issue Type: Improvement
> Components: tapestry-core
> Affects Versions: 5.9.1
> Reporter: Ben Weidig
> Assignee: Ben Weidig
> Priority: Minor
>
> h2. Problem
> Even though Tapestry doesn't generate sources maps, there are possible maps
> to be found in most projects:
> * build artifact copied into {{META-INF/assets}} or {{META-INF/modules}}
> alongside the application's compiled/bundled JS
> * vendored third-party bundle + map dropped into the webapp context and
> referenced via the {{context:}} prefix
> (e.g.{{{}@Path("context:js/vendor.min.js"){}}}).
> In production, these maps let anyone reconstruct original, unminified (and
> potentially unobfuscated/uncommented) source from the shipped bundle simply
> by requesting {{{}<bundle>.js.map{}}}.
> h2. Proposed Solution
> Introduce a new {{ContextAssetProtectionRule}} chain-of-responsibility
> service, mirroring the existing {{{}ClasspathAssetProtectionRule{}}}.
> Both are ordered-configuration chains where any contributed rule returning
> true for a path blocks the request (handler returns 404).
> * {{ContextAssetRequestHandler}} consults an injected
> {{ContextAssetProtectionRule}}
> * {{ClasspathAssetRequestHandler}} already had this mechanism, no change to
> the handler itself.
> * {{AssetsModule}} contributes a {{SourceMapFile}} rule to both chains,
> blocking any path ending in {{{}.map{}}}, gated on
> {{{}@Symbol(TapestryHttpSymbolConstants.PRODUCTION_MODE){}}}. The rule is
> only added when production mode is active, so development/QA environments are
> unaffected.
> Because both rules are ordinary IoC contributions, applications retain full
> control.
> *Note:* the {{asset:}} prefix resolves to a path under {{META-INF/assets/}}
> on the classpath and is served through {{{}ClasspathAssetRequestHandler{}}}.
> It is therefore already covered by the {{ClasspathAssetProtectionRule}} chain
> and needs no separate handling.
> h2. Caveat
> The new chain for {{ContextAssetRequestHandler}} won't change the existing
> behaviour and filter out {{{}WEB-INF{}}}, {{{}META-INF{}}}, and {{*.tml}}
> files.
> These rules are non-negotiable regardless of production mode.
> h2. Risks
> h3. Behavioral change for existing apps
> Any application currently relying on .map files being served in production
> will see those requests start returning 404 after upgrading.
> h5. Mitigation
> Documented as an intentional default.
> Recoverable via a one-line
> {{{}ContextAssetProtectionRule{}}}/{{{}ClasspathAssetProtectionRule{}}}
> contribution override, and behavior is unchanged in development mode.
> h3. Rule scope is extension-based, not content-based
> The block is a simple {{.toLowerCase().endsWith(".map")}} check.
> Any legitimate, non-source-map asset that happens to use a {{.map}} extension
> would also be blocked in production under the default rule.
> h5. Mitigation
> Same override path as above.
> h3. Two independent rule chains
> Because context and classpath assets now have separate protection mechanisms,
> an app overriding one (e.g., to re-enable maps under {{{}context:{}}}) must
> remember the other chain ({{{}classpath:{}}}) still blocks them by default,
> and vice versa.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
