WWW.EscapeURL(...) causes error?

[Whyser]

I'm not really sure if this is related to your code or a Firebase-change or something else, but it's super weird. I'm not using the latest version of your code, but I started receiving "Permission Denied" from nowhere when making requests (have not touched Firebase-part of the code in probably +6months). I found the issue being the use of WWW.EscapeURL(...) on multiple places inside Firebase.cs which hasn't been an issue before, but if I remove the EscapeURL(...) everything works as expected. Currently using Unity 2017.4.10f1 (haven't updated in a long time). My Firebase rules state that I need Auth parameters, but when escaping the auth=kjbandkjbnasfjkasfkjb it will not be "valid" (it will work if I don't escape it).

How can this be? Since I haven't updated Unity it shouldn't be the problem and this issue is occuring both in the Editor and on Android device (haven't tested iOS) which makes me lean towards a Firebase issue.

I've contacted Firebase about this to see if they know anything more, but would be great if you can confirm if this is an issue for you as well (as you might need to remove the EscapeURL).

[mtvg]

Encountering the issue as well! The HTTP request is clearly mis formatted and have no idea how it used to work previously...

[Whyser]

"Glad" that someone else is having this issue as well. As I said in my previous post, I've contacted Firebase but have yet to receive a response.

[eladleb]

@Whyser Same here, I've also contacted firebase support with this issue, although removing the EscapeURL is a valid workaround, I'm unsure if it's the right approach going forward.

[XenoTheDragon]

@Whyser

Here it says that they will change their url parameter parsing some time in february:
https://firebase.google.com/docs/reference/rest/database/ Maybe this is the culprit. I am not sure how far you tracked down the problem but I noticed that since the "=" that separates the parameter from the key is url-encoded to %3d, the parameter itself becomes the key, missing a parameter. At firebase they maybe are not directly at fault as it (now) conforms to the standard.

[Whyser]

Nice find @XenoTheDragon this must be it! But I'm having a hard time understanding if the warning on the page you link;

1. say that they are aware that they are currently not acting according to the standard and that they will fix it in February or
2. that they just now implemented the "fix" and that is now causing the problem.

Anyhow, it seems if they make this "big" change, shouldn't they make an email notice to people who have been using it the wrong way (as they obviously know that they have allowed requests to be made "wrongly")?

[rockwotj]

Hey Firebase Engineer here.

We've fixed the buggy behavior in our latest deploy. You should have received an email for this but it seems our analysis of this did not account for users relying on the fact that the old code allowed for %3d to work as a = to a query parameter. However you should still URL encode query parameter "values" (the part after the = until the next &) as needed.

If you update your URL decoding to not encode = as %3d then this will be fixed. If you need an extension of the old behavior please contact Firebase support: https://firebase.google.com/support/contact/

[eladleb]

Hey @rockwotj , thanks sharing more information.
Specifically in this repository, the "auth=(FirebaseIdToken)" is being encoded.

Will the firebase auth token ever need to be URL encoded, or can we rely on it being URL friendly and simply remove the EscapeURL altogether.
Removing it works but I just want to make sure it's the right approach going forward.

[rockwotj]

The auth token should be URL safe at the moment but I'm not sure this is a hard gaurentee forever.

[mtvg]

For safety, in addition of removing the WWW.EscapeURL in the Firebase class, you can EscapeURL the values of all query parameters in the FirebaseParam class:

public FirebaseParam Add(string parameter) {
    var i = parameter.IndexOf('=')+1;
    parameter = parameter.Substring(0, i) + WWW.EscapeURL(parameter.Substring(i));

As all query parameters seem to go through that Add method, including authentication, this should be safe.