How to password protect a static HTML page with no JavaScript
shkspr.mobi
shkspr.mobi
I guess its a good thing that people have gone through hype and now are in search for a smaller more focused tool.
I wonder why standard committees don’t seem to be working on a auth solution that doesn’t require code and is more just markup/server config, but with modern things like passkeys and stuff… or maybe I’ve missed something obvious.
If I had to guess, I would say that the web was supposed to be stateless, and cookies/local storage were tacked on after the fact to give it state, so by the time WebApps became more common than web pages people were already used to custom login pages.
It is? And I imagine that's why it "sucks" for you, since I think you actually mean it should be built-in to the HTML / Styling of the site. But that would defeat the purpose, to a degree.
Normal auth sends a cookie every request. That is really the same. You have to do state somehow.
> and for get requests it shows in the url
This is not true
Sending a token and sending a password are not the same thing.
And I thought basic auth GET requests looked like this: http://username:password@somesite.com, did that change at some point?
Not exactly, as a cookie a) isn't something you can just read and remember easily (noting that Basic Auth uses base64-encoding, but that's a pretty flimsy layer of 'protection') b) is only of any use for a single session in a single context. If I see somebody's password while inspecting logs/network traffic etc. there's a decent chance I'll be able to use that information to help me access any number of resources that user might access, at any time. What I don't get is why there's no proposal yet (that I'm aware of) to have browsers automatically send Authorization headers once a bearer token has been established for a particular domain or URL path.
https://docs.nginx.com/nginx/admin-guide/security-controls/c...
The authors hacky way have the benefit of also password-protecting the contents if you CTRL+S the page in the browser as .html, and send it to someone else.
Edit - oh that wasn’t the rule I guess
By that I mean: one way to implement turing completeness is arithmetic+looping. In this situation the CSS provides the arithmetic, and the user has to provide the looping.
This means it only sort of counts as turing complete, and it's unusably slow for calculations. Especially because rule 110 is on the edge of technical capability and rarely usable even in an optimized environment.
This statement is correct.
The question is whether it's legitimate to omit "with the cranking system" when you talk about the turing completeness, or to treat it as negligible. Because it does a lot more than an actual crank.
But I'm not going to argue about semantics. If you think I phrased things badly, then I apologize and concede the phrasing.
The more important part, in my view, is that the user will never get through enough iterations to run decryption logic.
That is, to avoid having your "not-so-secret" link having your "secret content" from being scanned by their "content" scanners or conversation "recorders" (as often mandated by SEC and Feds).
While it can easily be used for nefarious purposes, it does have valid usages such as sending license info, one-shot correspondence, crash dump, or anything that can be legally pastebin.
Yes, this text is encrypted using a simple Caesar cipher, specifically ROT13. The ROT13 ("rotate by 13 places") is a simple letter substitution cipher that replaces a letter with the 13th letter after it in the alphabet. It's an example of the Caesar cipher, developed in ancient Rome.
When I apply ROT13 decryption to your text, the result is:
"This is my super secret text. No one can read it. Not even Caesar himself! If you want to understand how this incredibly strong and foolproof encryption works"
---
cool hack, though, TIL!
- Static sites password (1)
- Link lock, to lock the url (2)
(1) https://github.com/matteobrusa/Password-protection-for-stati...
Your examples make use of JavaScript.