Comment by PNWChris | Hacker News Reader

Comment by PNWChris | Hacker News Reader

Parent Full thread

I have a personal project that saves state to the URL's hash (https://www.rebalancecalc.com).

I do that because I wanted users to be able to save their state without burdening those users with accounts or burdening myself with maintaining a DB for something so simple.

I also somewhat abuse the history API and use my "read the URL and load state" logic to implement undo-redo via navigating back and forth, though that doesn't seem to work right now. I am working on a refactor that uses redux to implement undo-redo and just replace state, to keep the user's history clean.

Storing encoded JSON in the URL hash is a nifty hack in my opinion. Users can save state in a bookmark or share it with others easily, and it's clear to the users that "where they are" in the URL bar maps to the current app state. Plus, bookmark syncing is taken care of by most browsers to make that state available elsewhere, etc. For the site owner, it means not needing a DB to make an app with some kind of state persistence.

One risk: be sure the state you persist to the URL is in a schema you plan to retain compatibility with! Blind serialization and de-serialization is a recipe for bugs and misery the next time you add a feature.

I do the same on a production app at work, but for a different reason.

Storing confidential data in the hash assures my users that I (the developer) don’t have access to this data, since anything after the hash never gets sent to the server by the browser.

It wouldn’t stop me from sending that information with a post request afterwards but the code is open source and it could be noticed in developer tools.

Sorry I don't understand, you put confidential data into an URL so it's probably in server logs etc.?

If a user types in web browser: https://www.example.com/webpage?q=54#{"userdata":"its a secret"}

Then the web browser sends a message to the server that looks something like this:

   GET /webpage?q=54 HTTP/1.1
   Host: www.example.com
   Cookie: well maybe there's a cookie here

Although it's encrypted with ssl and there's some hopefully irrelevant messages along with it (which aren't irrelevant so they can be used to fingerprint you).

As you can see, the bit that comes after the hash isn't ever sent from the client to the server. It was originally meant so that you could link to a particular section of a longer web page, so it was quite irrelevant.

Nowadays it's exposed to javascript. This means that the code can rely on it - it can read and set it. The javascript author could read it and use it in an entirely inbrowser javascript app. Or the javascript author could read it and send it to the server in a more secure channel, like the body of a POST request, to reduce the chances it gets stored in server logs.

But what comes after the hash is never processed by any standards compliant web server not transmitted by any standards compliant web browser/client.

you missed the part when he says browsers do not send the bits after the hash character.

Reply on news.ycombinator.com