Add ability to encrypt entire folders with the same password for deployment #47
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
A few small tweaks to extend support to non-Single Page Applications, i.e. the ability to encrypt an entire folder of html pages, with the same password, and then to publish these encrypted html files such that the user only needs to enter the password once to then access the whole site.
The intention is to act similarly to a JS-version of HTTP basic auth-like behaviour (i.e. assumes that the client holding the password is trusted [kind of needs to be for any of this to work!], and so the security model is intentionally broken in a very specific way to enable this - by storing the password entered in localStorage, along with caching the different
k
's based on the URL in localStorage).The idea is to be able to use pagecrypt as a drop-in replacement for situations where HTTP Basic auth is not possible (e.g. Google Cloud Storage, S3, Github Pages), in order to prevent access from strangers stumbling across a website.
These patches also mean that different pages with different passwords hosted on the same server do not log you out of the other pages once you enter a password for another page (by storing the
k
values separately perwindow.location.href
) (e.g. in theverify:test
suite, logging into one page and then another, and then going back to the first page will not reprompt for the password again as happens in the current master branch)