I did this for an Othello game back in the 90's. The state was encoded in the URL along with the players move. It seemed weird to encode a slightly different URL for every move the player might click, but that also meant squares that were not legal moves didn't get a URL. And that meant the mouse pointer would change when you hovered over a valid square! Another trick was to return the updated board state, but also include an automatic reload after a few seconds with the computers next move already determined. This made it look like "thinking" was going on when in fact it was already decided when the board updated on players move ;-) This was all in a CGI script. As others have pointed out, it also supported "undo" via the back button. Fun.
How to store your app's entire state in the url
111–120 of 416 posts
Re: How to store your app's entire state in the url
#112This is pretty common and has a bunch of advantages, like the fact you can link to and bookmark a particular state. Also, if you are careful you get undo and redo for free with the browser's back button doing all the work for you. The disadvantages are that your representation of internal state becomes part of the interface - if you ever change your app you need to deal with versioning the state so your new version c…
> The disadvantages are that your representation of internal state becomes part of the interface
This is the biggest reason to avoid this. URLs aren't meant to be used this way. I'd only do it if I wanted a quick and dirty solution.
Re: How to store your app's entire state in the url
#113App state in URL can be a good idea, but if possible I prefer readable path/query parameters instead of unreadable base64 encoding. As one comparison, this is Google Finance encoding stock chart parameters: https://www.google.com/finance/quote/F:NYSE?window=5Y Versus Yahoo! Finance doing the same: https://finance.yahoo.com/quote/F/chart?p=F#eyJpbnRlcnZhbCI6IndlZWsiLCJwZXJpb2RpY2l0eSI6MSwidGltZVVuaXQiOm51bGwsImNhbmRsZ…
The possible advantage of the encoding is that it that it can be encrypted and make parameter hacking impossible.
You don't need to encode it to do that though. You can just sign the URL
Re: How to store your app's entire state in the url
#114App state in URL can be a good idea, but if possible I prefer readable path/query parameters instead of unreadable base64 encoding. As one comparison, this is Google Finance encoding stock chart parameters: https://www.google.com/finance/quote/F:NYSE?window=5Y Versus Yahoo! Finance doing the same: https://finance.yahoo.com/quote/F/chart?p=F#eyJpbnRlcnZhbCI6IndlZWsiLCJwZXJpb2RpY2l0eSI6MSwidGltZVVuaXQiOm51bGwsImNhbmRsZ…
> https://finance.yahoo.com/quote/F/chart?p=F#eyJpbnRlcnZhbCI6... Dear god... this link was real. I thought it was like a joke or something
[flagged]
Re: How to store your app's entire state in the url
#115[deleted]
Re: How to store your app's entire state in the url
#116Isn't this also how old school games (I've seen it as late as the NES I think) did allow you to save progress, you'd get a short string as your "save" and could just enter it to restart the game in the same state later. I love that it offers essentially unlimited "saves"
And you can use your save on another system.
Re: How to store your app's entire state in the url
#117Just do not. That or alternatively a hidden field is how asp.net WebForms did it state management 20 years ago. Worst possible idea ever. Good for small scale unimportant external state management but not for your everyday web app.
It also degraded performance. I had to use a .NET-based issue tracking web app 20 years ago. The performance was horrible, with pages sometimes taking 20 seconds to load. I eventually viewed the source of the page and discovered a form field called "viewstate" that contained several megabytes of encoded data.
Re: How to store your app's entire state in the url
#118App state in URL can be a good idea, but if possible I prefer readable path/query parameters instead of unreadable base64 encoding. As one comparison, this is Google Finance encoding stock chart parameters: https://www.google.com/finance/quote/F:NYSE?window=5Y Versus Yahoo! Finance doing the same: https://finance.yahoo.com/quote/F/chart?p=F#eyJpbnRlcnZhbCI6IndlZWsiLCJwZXJpb2RpY2l0eSI6MSwidGltZVVuaXQiOm51bGwsImNhbmRsZ…
The possible advantage of the encoding is that it that it can be encrypted and make parameter hacking impossible.
Harder. Not impossible. Harder. I don't want to make it sound like I am being disagreeable just for the sake of being disagreeable. If there is one thing the past decade has shown, it is that hacking is just a matter of time and whether a determined person is willing to direct resources at it.
Re: How to store your app's entire state in the url
#119App state in URL can be a good idea, but if possible I prefer readable path/query parameters instead of unreadable base64 encoding. As one comparison, this is Google Finance encoding stock chart parameters: https://www.google.com/finance/quote/F:NYSE?window=5Y Versus Yahoo! Finance doing the same: https://finance.yahoo.com/quote/F/chart?p=F#eyJpbnRlcnZhbCI6IndlZWsiLCJwZXJpb2RpY2l0eSI6MSwidGltZVVuaXQiOm51bGwsImNhbmRsZ…
I decoded that, gzipped --best, then re-encoded and got something that's shorter at least H4sIAAAAAAACA7VU3W7TMBS+5ykmcxuNdOlGyd3QmECCIdYWNKYKnSanqVfHNrbTNqoq7QF4Sp6EYyfpaMYtdz7H5/vOz3fsHePSoVmDYCnbIK5YxDQarnKecVezdBAxx0ucSu5YKishIpaBzAV+47lbsnR4mgxHF+dv4jgZJYPh4PV5xBaCa405SxcgLEZsrUTlKXI0AojTmYq8kD90x8woa5fAzcGxBOMmtUaqSnCJVBVuHRLDE2sJZoVujNZyJS1Ld3viLAqDBTjytGi1FBlrCccZiI4RDHmtq3KOHst+P/6iMk8qmRs6eo9rCDovhXOpKxeiOZ…
you could come up with a better compression scheme given that the dict keys and many of the values are probably common across everyone even if they don't repeat multiple times for a given user. a lot of flexibility would be lost though, and you would need to always update the scheme in a backwards-compatible way.
Re: How to store your app's entire state in the url
#120App state in URL can be a good idea, but if possible I prefer readable path/query parameters instead of unreadable base64 encoding. As one comparison, this is Google Finance encoding stock chart parameters: https://www.google.com/finance/quote/F:NYSE?window=5Y Versus Yahoo! Finance doing the same: https://finance.yahoo.com/quote/F/chart?p=F#eyJpbnRlcnZhbCI6IndlZWsiLCJwZXJpb2RpY2l0eSI6MSwidGltZVVuaXQiOm51bGwsImNhbmRsZ…
The possible advantage of the encoding is that it that it can be encrypted and make parameter hacking impossible.
Would have to do the signing server-side, predicated on the server checking the entire state to ensure validity. Such effort being put into preventing parameter-hacking would suggest there are serious vulnerabilities in that website. The URL is meant to be modified by the client.