News for hackers. Stuff that matters.
Re:Password protect a static HTML page by garrison on Saturday February 18, 2023 @06:15PM (#34852134)
My recent solution to this problem -- for an entire static site -- was to use HTTP Basic authentication with CloudFlare Pages: https://github.com/garrison/cloudflare-pages-shared-password
Re:Password protect a static HTML page by deaddodo on Saturday February 18, 2023 @09:57PM (#34853810)
I was digging through the comments for someone to point this out. I’m honestly curious why people are using these overly complex options when a solution has been built into the HTTP standard for decades (and, in fact, is heavily abused for many APIs).

And it’s superior in many ways, since the file is never delivered until authentication has been completed.

Re:Password protect a static HTML page by chii on Saturday February 18, 2023 @11:53PM (#34854565)
with basic authentication, you cannot embed the decryption key into the url via a hash fragment.

This means you must have a secondary channel to communicate to the user about the password, and the server must also know the password.

So depending on your use-case, the basic auth isn't suitable. For example, mega : https://en.wikipedia.org/wiki/Mega_(service) , in which you want to ensure that the decrypted data is _not_ accessible to the server, so the key is not stored nor sent to the server!

Re:Password protect a static HTML page by rvnx on Sunday February 19, 2023 @11:51AM (#34859246)
In a real-life scenario, the server can access the key and collect it back (just farming location.hash)
Re:Password protect a static HTML page by deaddodo on Monday February 20, 2023 @01:32AM (#34865586)
Sure you can, it’s been built-in to the HTTP spec since RFC1738[1]. You just do:

//<user>:<pass>@<url>[:<port>][/<location>]/

It doesn’t work on IE classic, but should still be perfectly valid on Chrome, Safari, Firefox, etc.

1 - https://www.ietf.org/rfc/rfc1738.txt

Re:Password protect a static HTML page by yoble on Sunday February 19, 2023 @06:17AM (#34856588)
Author here - the specific use case is when you _don't_ have or want server-side logic or a DB. For example on static hosting (hence the name StatiCrypt) like Github pages, Netlify, etc.

That means nothing to maintain, no server cost, no serverless functions to rely on, etc.

But when that's not a constraint there are many different options that might make more sense.

Re:Password protect a static HTML page by deaddodo on Monday February 20, 2023 @01:34AM (#34865599)
Sure, I’ll give you that use case.

It’s just weird how many people are jumping on this as some new technique when Basic Auth is fully usable in many other cases.

Re:Password protect a static HTML page by flippinburgers on Monday February 20, 2023 @07:19PM (#34874763)
Person A doesn't know about basic auth - primarily because it isn't a hip way to solve the problem - so person A spends a bunch of time understanding, installing, and using something unnecessarily convoluted. When presented with evidence of a simpler solution, they balk because humans value things they have spent time on especially when it is their own solution, their own "discovery".