Affects Version/s: 6.11.6
Fix Version/s: None
During normal operation of our NPM remote cache, we ran into this issue:
The instructions for resolving it, however do not work. It seems as though Artifactory remembers that this folder is a file, even after deleting it from the remote cache. The only way to fix this was to temporarily drop our cache periods down to a dangerously low value so the cached metadata would be invalidated, and requesting the broken NPM package again via the npm api endpoint.
Steps to reproduce:
- Create an NPM remote repository (eg. NPM_ORG)
- Set the NPM remote repository cache periods to a more sensible value (ie, >= 1 day)
- Request an NPM package using NPM from an incorrect url (ie, http://artifactory/NPM_ORG)
- Request the same NPM package using NPM from the correct url (ie, http://artifactory/api/npm/NPM_ORG) (results in the 400 rejected error)
At this point, the package requested will be in a broken state, and step 4 will fail with the above error, because the request to the "naked" repository URL will result in Artifactory incorrectly caching a folder as a file. Deleting this file as in the linked instructions will not clear the error until the metadata ages out of the cache period.
There are two issues that need to be addressed here:
- Artifactory needs to invalidate cache entries when the underlying cache repository is manually modified.
- Artifactory should appropriately handle NPM requests made to the naked endpoint (http://artifactory/NPM_ORG) to prevent this corruption from occurring in the first place. Either the cache depot needs to be restructured to prevent collisions, or Artifactory should rewrite or reject requests coming into that endpoint so it's never used.
Without 1, your instructions on how to fix this issue won't work. Without 2, you leave NPM remotes open to DoS attacks, intentional or not.