6

I would like to take a JSON string and encrypt/hash/encode it so that I can put it into a URL so that it would resemble something such as seen below:

var stringToEncode = JSON.stringify({foo: 'baz', bar: [1,2,3,4,5], baz: {fizzle: 'buzz'}});

'www.myrandomurl.com/someurl/123fas234asf1543rasfsafda'

I would then like to take that encrypted/hashed/encoded string, and decode it back to its original JSON string so that I can use it to bind to various elements on a single-page AngularJS application.

The contents of the JSON string are not sensitive so security or complex hashing is not required. The only condition is that It needs to be a "URL/URI 'safe'" string that is hashed for vanity purposes like seen above.

I am limited in knowledge of encrypting/encoding however I have thought about simply encoding the string to Base64 and decoding it again.

Is this the best approach? What is a better method if not?

Sean Larkin
  • 6,290
  • 1
  • 28
  • 43

1 Answers1

7

Use encodeURIComponent() to encode it for the url

To decode use the decodeURIComponent() function

Base64 is not URL safe since it can contain non url characters like / + -. (See this question)

If you want your url to not be too similair to the original string you can first covert to base64 and then encode and reverse by decoding and covrrtibg back from base 64

// to url
encodeURIComponent(btoa(str))

// from url
atob(decodeURIComponent(uri))
Community
  • 1
  • 1
Nachshon Schwartz
  • 15,289
  • 20
  • 59
  • 98
  • 2
    I think he's looking for something that won't be plain text readable but doesn't necessarily need to be secure. – jered Dec 10 '15 at 22:04
  • If u read his question all he wants is url safe... `...The only condition is that It needs to be a "URL/URI 'safe'" string...` – Nachshon Schwartz Dec 10 '15 at 22:05
  • base64 would be shorter actually. 76 vs 111 characters (for the input from the question) – zerkms Dec 10 '15 at 22:08
  • @zerkms, See my answer as to why base64 wouldnt always work – Nachshon Schwartz Dec 10 '15 at 22:15
  • 1
    @Nayish presence of those characters does not mean it would not work. If you have `/someurl/` url - and you know the last part is the base64 - there is no problem with it. So, your "is not URL safe" --- is not precise. – zerkms Dec 10 '15 at 22:17
  • I wouldnt risk it for such a small diference... theres a reason those chars are escaped... the 'you know the last part is base64' is a big opening for bugs further down the line. you can always combine the two and encode the base64 which would only escape the problematic chars – Nachshon Schwartz Dec 10 '15 at 22:24
  • "theres a reason those chars are escaped" --- those are not "escaped", please check the RFC to see you can safely use any of `/` or `+` or `=`. "is a big opening for bugs further down the line", "the problematic chars" --- and that's the problem: you base your scares on a wrong assumption. – zerkms Dec 10 '15 at 22:26
  • 'URLs use some characters for special use in defining their syntax. When these characters are not used in their special role inside a URL, they need to be encoded.' http://www.blooberry.com/indexdot/html/topics/urlencoding.htm#whatwhy – Nachshon Schwartz Dec 10 '15 at 22:31
  • @Nayish 1. you're checking not rfc but something that is literally 20 years old 2. If you checked RFC 3986 you would see that requirements for encoding path and query parts are different. Please refresh your knowledge on URIs before you continue arguing. https://tools.ietf.org/html/rfc3986#section-3.3 – zerkms Dec 10 '15 at 22:33
  • A more modern aproach: https://perishablepress.com/stop-using-unsafe-characters-in-urls/. Simply put if the / character doesnt represent what I t is supposed to (and it definitly doesnt in a base 64 string injected into a url) it should not be used although technically it id allowed – Nachshon Schwartz Dec 10 '15 at 22:40
  • `/` represents exactly what you type - it's a `/` character. That article is irrelevant again: it's about escaping characters in query part not in path. The RFC is very clear about encoding: it is not hard to read and understand it once (but for some reason you prefer some weird articles over the standard). "it should not be used" --- if you don't understand how URIs work - for sure you better not use it. I don't have any problems with it though. But I'm off, have fun spreading your misunderstanding. – zerkms Dec 10 '15 at 22:42
  • Of course it is not safe in the path since if the id of a post was converted to the string `5a/comments/4b` when adding it at the end of the path we would get a whole new meaning to our path `posts/a5/comments/4b` which makes it seem like comment `4b` of post `a5` instead of a post with an escaped id of `5a/comments/4b` – Nachshon Schwartz Dec 10 '15 at 22:48
  • @DavidMårtensson please check what section you're checking: `3.4. Query`, while the OP is using it as a path – zerkms Dec 10 '15 at 22:48
  • @Nayish in your app all URLs follow some structure - and you always know what every part of URL represents. – zerkms Dec 10 '15 at 22:50
  • @DavidMårtensson and `/` and `=` and `+` are safe characters (as per the RFC) that need not be escaped. – zerkms Dec 10 '15 at 22:51
  • @zerkms.. all I am saying is better safe than sorry... using base 64 is accident prone. Better off not risking it. Notice my example is a real world restful url example where the meaning is not clear... – Nachshon Schwartz Dec 10 '15 at 22:52
  • @Nayish there is no risk if you understand what you do. If not - anything is not safe (since applying random functions that are not designed to be used for what you suggest - is harmful as well). – zerkms Dec 10 '15 at 22:53
  • I work in a team of 10... I know what im doing does the next guy replacing me know what I was thinking... probably not :) – Nachshon Schwartz Dec 10 '15 at 22:55
  • Agakn my example is something that could happen in real world app.. I write an apllication with posts where I bsde64 the ids. A month later a team member is asked to add comments... we both know how uri's work...and that why we mind / since they are logical deviders within uri's representing sub entity pages – Nachshon Schwartz Dec 10 '15 at 22:59
  • @JCD exactly it looks a little better in the URL if it's an encoded or hashed string for vanity purposes. Is there a shorter alternative to Base64? – Sean Larkin Dec 10 '15 at 23:06