Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Gad! I have spent all morning trying to --- password protect a static html page. How in the hell does HN have a story about the exact topic I've been struggling with appear just a dozen or so hours after I started working on it. Wow.

I was _extremely_ happy to see this posted.

However when I click the link I am taken to the library I had initially tried and had to reject. Without getting into the crypto side of things (which very well may resolve to "just make it tough enough for most folks") I crashed and burned using this tool once my page reached certain sizes. (I was cramming everything I needed into one page and I had a big hunk of bytes that I didn't want hanging out on the filesystem)

As I understand it, this is a known issue in V8. V8 limits the number of properties/collection members an object can have. There's a flag you can use with node to get a little more headspace, I believe it's something like "--max-old-space-size=8192" but it's a V8 problem, not a node problem. The staticrypt coders could also switch to a streaming cryptography instead of block, but that's far too much to ask of the casual user who only wants to lock up a page or two.

This is a really cool tool, and I wished I could have used it. Good luck to the team going forward. I've gotta find something else as this doesn't work for me.



If your server supports it, a fast and easy way to password protect a page is to put it in a folder and password protect that folder with htaccess:

https://ithemes.com/blog/what-is-the-htaccess-file/#password...


Keep in mind the same server will lock you out for a day or so if you autofill the wrong password, be warned. :D


No it won't, just restart the browser if cleaning cookies didn't work. Entered password is only valid for a session.


HTTP basic authentication is stateless


This could be true if the server is using something like fail2ban.


Something similar has been posted before some time ago: https://news.ycombinator.com/item?id=34083366


Which in turn has inspired the creation of PrivacyProtect [0]. It allows to do basically the same thing as the other applications, but in my opinion the interface is better, it also allows you to directly select a file which I guess is easier than copying the contents, it also means you can just select an image file for instance or some other type of file other than a web page.

[0]: https://www.privacyprotect.dev/


Why is everybody forcing me to upload to the web the very files I want to keep private to myself? If any code in the universe should run locally, it's this kind of code.

I don't get it.

Great UI, though. But I still don't get it.


That the frontend is hosted on someone else's server is a convenience, but I see your point and agree. Technically nothing is uploaded anywhere, nor does it call any APIs to do the de/encryption. Instead, it uses the cryptography mechanisms built into your browser. Local file access and creation are via FileSystem api[0]. Said differently, you could save the page to your desktop—ensure all the includes are to local files, and still run it. In fact, thats's what I did with Portable Secret[1] which others noted was previously posted here. I can confirm this works and nothing "calls home".

[0] https://developer.mozilla.org/en-US/docs/Web/API/FileSystem [1] https://mprimi.github.io/portable-secret


> Why is everybody forcing me to upload to the web the very files I want to keep private to myself?

This isn't the use-case I had in mind.

My personal one: I want to build a small utility web app for a very specific task, and it would be used by me and by some of my friends (less than 10 users total). The entire thing can easily be front-end code, which is nice, because I can just host it on Netlify and not bother with hosting, managing it, etc., thus making the complexity of it all much lower.

But there is one catch - the web app uses an external API, and, along with it, the API access key. This puts a big stop sign for making it front-end only. And I don't want to up the level of complexity by managing the back-end just for the API access key retrieval (for a webapp used by less than 10 people). Exposing the API key in the front-end code on a publicly accessible website is one of the worst ideas I can think of.

I haven't done the evaluation on how well the solution in the OP would serve my specific purpose, but it looks promising.


That project and the parent do exactly what you wish:

- run encryption locally

- do not upload anything

You may not realize that’s the case because it’s a web form


https://github.com/robinmoisson/staticrypt#encrypting-multip...

> This allows encrypting multiple page on a single domain with the same password

This might still work for you if putting everything on one page isn't a requirement. Using the "remember me" checkbox means the user only has to input this password once.


> I have spent all morning trying to --- password protect a static html page

Curious. Can you say more about your use case, even if only in general terms?


Is there a reason you can't load it up as a pdf with pdf.js?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: