Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Settings.config callback crashes when passed option containing encoded percent sign #171

Open
compelling opened this issue Sep 21, 2016 · 2 comments

Comments

@compelling
Copy link

Hi, I have have several users of Grosh for Pebble reporting they can login to the app in the settings web page running inside Pebble Time app, but the watch fails to connect using the credentials transferred back to the watch app from the web page.

Did some tests, and it turns out you cannot transfer password containing % sign.
The web page encodes the options
var location = "pebblejs://close#" + encodeURIComponent(JSON.stringify(options)); console.log("Warping to: " + location);

When entering g@gmail.com - G1234% and looking at the console, this looks fine:
Warping to: pebblejs://close#%7B%22email%22%3A%22g%40gmail.com%22%2C%22password%22%3A%22G1234%25%22%7D

So the % is nicely escaped. But the watch app dies:
URIError: URI error decodeURIComponent@[native code] at onCloseConfig (settings/settings.js:186:43)

Any ideas how to get around this, except telling users to stop using % in their password?

@matopeto
Copy link

matopeto commented Sep 27, 2016

As workaround you can encode password (like base64) in your settings page, and than decode after settings page is closed.

I am reproduced this error on iOS (even with Clay config) it seems to be OS problem when hash (after #) is decoded, so, %25 is decoded while reading, and double decoding causing the error.

Maybe Safari has the same problem as Firefox: http://stackoverflow.com/questions/4835784/firefox-automatically-decoding-encoded-parameter-in-url-does-not-happen-in-ie

@compelling
Copy link
Author

Yes, it was iOS that i tested on. Yes, base64 encoding should do the trick, will do that for now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants