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

Android 10 replacing @ with @ in requestDump #137

Open
android-dataticket opened this issue Aug 18, 2020 · 4 comments
Open

Android 10 replacing @ with @ in requestDump #137

android-dataticket opened this issue Aug 18, 2020 · 4 comments

Comments

@android-dataticket
Copy link

android-dataticket commented Aug 18, 2020

https://stackoverflow.com/questions/63475044/android-10-changing-sign-to-64-when-sending-auth-header-through-ksoap2

Android 4.4 through Android 9.0 will properly send the '@' character as is inside a request envelope.

Android 10.0 is changing the '@' character into '&#64 ;' which is the ascii code for the '@' character.

Can't find out how to prevent this on the outside, it looks like it's happening in the library during the envelope creation/execution.

For example, let's say one of the nodes I'm sending is a username that uses an '@' inside, like username@areaname.

    SoapObject request2 = new SoapObject(NAMESPACE, "request");
    PropertyInfo pi = new PropertyInfo();
    pi.setName("UID");
    pi.setValue("username@areaname");
    pi.setType(String.class);
    pi.setNamespace(NAMESPACE2);
    request2.addProperty(pi);

this will get sent in the envelop as <UID>username&#64 ;areaname</UID> if using Android 10.0

Using latest KSOAP2 3.6.4.

@Kisty
Copy link

Kisty commented Aug 18, 2020

Can you make a simple repo recreating this bug? That will help the developers tackle this one

@android-dataticket
Copy link
Author

I don't have the time for that now, but I can share what I found by stepping through it.

envelope.bodyOut correctly displays the '@' sign
httpTransport.requestDump incorrectly displays the ascii code '&#64 ;'

it's happening at line 62 in HttpTransportSE.class:
byte[] requestData = this.createRequestData(envelope, "UTF-8");

when SoapEnvelope is writing to the KXmlSerializer on line 138 of Transport.class:
envelope.write(xw);

somewhere here, the XmlSerializer writer is changin the '@' to '&#64 ;' on Android 10.0 devices.

I wish I could provide more help!

@Kisty
Copy link

Kisty commented Aug 18, 2020

Sounds like a framework issue. Have you tried searching for the bug on https://b.android.com?

@android-dataticket
Copy link
Author

hello @Kisty , I ran into this issue again, over a year later.. and instead of asking our vendor if they could change the username to remove the @ sign, I dug deeper into the KSOAP classes.

I found the issue to be the following line, in the KXmlSerializer.class, line 98, it's an IF statement that appears to work with Android 9.0 and below, but has a slightly different behavior on Android 10+

if (c < ' ' || c == '@' || c >= 127 && !this.unicode) {
            this.writer.write("&#" + c + ";");
        } else {
            this.writer.write(c);
        }

What is happening here, correct me if I'm wrong, is that if 'unicode' is true, then this entire IF statement should return false and the writer should call this.writer.write(c) instead of this.writer.write("&#" + c + ";");

However, on Android 10+, it seems that we need to encapsulate the OR's and make sure the AND section overshadows the entire IF statement.. for example, when I change this line to the following, it works as intended on Android 10+:

        if ((c < ' ' || c == '@' || c >= 127) && !this.unicode) {
            this.writer.write("&#" + c + ";");
        } else {
            this.writer.write(c);
        }

Notice I am putting an extra set of brackets over (c < ' ' || c == '@' || c >= 127) so that it will always also check for && !this.unicode..

I don't know why, but with Android 10+, it is evaluating this as if it were (c < ' ' || c == '@') || (c >= 127 && !this.unicode)

Is there any way this could be fixed in the library? I know it hasn't been changed in a while and maybe nobody else runs into this because nobody else is trying to pass an @ sign in a header item string...

I hope it was easy enough to follow, let me know if I can help any...

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