You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Dec 1, 2017. It is now read-only.
I have several resources (images) referenced from CSS file that is cachified - which means that they get 'cachify' treatment by the virtue of their URLs having the same prefix as the CSS file that is referencing them. It worked OK until #32 was merged - I know that images do not change whenever CSS changes (or vice versa) but it was a good enough solution.
Of course it does not work in 0.0.14 or later since we are now making sure that file we are returning has the same hash that is referenced by the URL.
If that really is a desired behavior, that's fine. If not I have couple of ideas I would gladly implement if there is any interest:
we could make 'strict checking' optional, or
we could make 'strict checking' smarter - for example by only allowing only a set of prefixes that we previously generated (which incidentally should be much faster than recalculating the hash on each request and still provide decent security)
If something like that seems remotely merge-able I'll try to prepare a PR. If I am missing the point here or misusing the module I'll close the issue to take my worries to a private fork.
Thanks for the great module.
The text was updated successfully, but these errors were encountered:
pirxpilot
added a commit
to pirxpilot/connect-cachify
that referenced
this issue
Sep 15, 2013
Instead of checking cachify prefix against the md5 hash of the file
content we just check if the said prefix is among the ones that we
previously generated.
It provides a safeguard against someone maliciously attempting to clog
the downstream cache by sending us a great number of invalid URLs and
has an added benefit of beeing much simpler than 'recalculate the hash'
method.
Fixesmozilla#37
Yup: it's still an issue and it affects all relative URL regardless of the resource type.
See comments on my PR #38
I since decided to write connect-cachify-static that is limited to static resources but does not have this particular problem. Maybe you can use it instead.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
I have several resources (images) referenced from CSS file that is cachified - which means that they get 'cachify' treatment by the virtue of their URLs having the same prefix as the CSS file that is referencing them. It worked OK until #32 was merged - I know that images do not change whenever CSS changes (or vice versa) but it was a good enough solution.
Of course it does not work in 0.0.14 or later since we are now making sure that file we are returning has the same hash that is referenced by the URL.
If that really is a desired behavior, that's fine. If not I have couple of ideas I would gladly implement if there is any interest:
If something like that seems remotely merge-able I'll try to prepare a PR. If I am missing the point here or misusing the module I'll close the issue to take my worries to a private fork.
Thanks for the great module.
The text was updated successfully, but these errors were encountered: