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

Stripped non-printing, non-ASCII chars from user agent #1819

Merged
merged 5 commits into from
Dec 1, 2018
Merged

Stripped non-printing, non-ASCII chars from user agent #1819

merged 5 commits into from
Dec 1, 2018

Conversation

chrlie
Copy link
Contributor

@chrlie chrlie commented Nov 30, 2018

HTTP headers support Latin-1 only. See this okhttp PR

@mobilesdk-bot
Copy link

mobilesdk-bot commented Nov 30, 2018

2 Warnings
⚠️ libs/SalesforceSDK/src/com/salesforce/androidsdk/app/SalesforceSDKManager.java#L148 - Do not place Android context classes in static fields (static reference to SalesforceSDKManager which has field context pointing to Context); this is a memory leak (and also breaks Instant Run)
⚠️ libs/SalesforceSDK/src/com/salesforce/androidsdk/app/SalesforceSDKManager.java#L235 - Using getString to get device identifiers is not recommended.

Tests results for SalesforceSDK

Generated by 🚫 Danger

SDK_VERSION, Build.VERSION.RELEASE, Build.MODEL, appName, getAppVersion(),
appTypeWithQualifier, uid, TextUtils.join(".", features));

// Strip out all non-printing non-ASCII characters
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Those characters probably come from the appname.
They might not be readable but if we strip them, it will change the app name in our logs - and impact our stats.
What problem are they causing?

Copy link
Contributor

@bhariharan bhariharan Nov 30, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@wmathurin

1. The MobileSDK is getting the app name
2. One of our customers is not using a regular quotation mark, but rather \u026F, which is `'`
3. Android is okay with this (which explains why the build worked on the pipeline before) but OkHTTP isn’t okay with it - it doesn’t like unencoded unicode
4. Trying to send a `User-agent` header with this value fails
so the fix is in the MobileSDK and it’s to encode the user agent properly, which requires ISO-8859-1 encoding (ASCII)
5. The customer can't login.

Root cause is here.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@bhariharan Are you saying we should encode it better or just strip the characters?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

After talking to Bharath, I've taken a less aggressive approach and moved the logic to get the app's display name into an overrideable method. This allows me to fix this at the app level.

@bhariharan bhariharan merged commit d7a9fce into forcedotcom:dev Dec 1, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants