JSON in URL Hash - A bad or good idea?

I've created a helper object to store JSON in the URL hash. See project here on GitHub:

This is useful for persisting page settings without a cookie. Works pretty good and I like it.开发者_运维技巧

What are thoughts for and against this approach? I've read security might be. Is it really when you are using json2.js or the native JSON object in newer browsers?

---

rison seems like a more compact and efficient way. Especially since many characters used in JSON aren't URI-safe.

Also, it's seldom wise to include sensitive information (that is, most of it) in anything that goes back and forth between server and client. That's why most 'session' schemes store only a session ID in a cookie, and not all the information. In that case, adding the ID to the URL isn't any harder than using the cookie. In fact, that was the default way to do sessions in PHP back in the old days when cookies were an advanced feature of a few browsers.

---

You should aware there is a limit to the url length and it changed between different browsers: http://www.boutell.com/newfaq/misc/urllength.html

---

In which part of the url are you storing it? The #fragment or the ?query ?

If it's the query... don't.

As those:

• remain in server logs,
• are captured by proxies,
• and are sent as referers to fellow sites you may link to from your page.

---

If the state is to be managed within a single browser, and not shared with other users or browsers, maintaining the state in localStorage may be a better bet. A framework such as amplify.store supports most browsers you'll encounter (IE 5+, Firefox 2+, Safari 4+, Chrome, Opera 10.5+, iPhone 2+, Android 2+): http://amplifyjs.com/api/store/

It's far easier to use than a cookie, much more powerful, and does not have the potential concerns that @Javier mentions.

If you do need the state to be managed across browsers (and/or users), the url is your better bet, and in that case I too would look at rison.