W-22917333: Rename beacon_child_consumer_{key,secret} to auto_installed_app_org_consumer_{key,secret}#2923
Conversation
Generated by 🚫 Danger |
| tokenFormat = object.optString(TOKEN_FORMAT, null); | ||
| beaconChildConsumerKey = object.optString(BEACON_CHILD_CONSUMER_KEY, null); | ||
| beaconChildConsumerSecret = object.optString(BEACON_CHILD_CONSUMER_SECRET, null); | ||
| autoInstalledAppOrgConsumerKey = object.optString(AUTO_INSTALLED_APP_ORG_CONSUMER_KEY, null); |
There was a problem hiding this comment.
Upgrade path for existing stored accounts
You've probably already considered this — for users who authenticated via an auto-installed app on 13.1+, their account data is persisted under the old "beacon_child_consumer_key" key. Between app upgrade and first successful token refresh, deserialization here won't find the value under the new key name, so getClientIdForRefresh() would fall back to the configured clientId.
Is the expectation that the refresh still succeeds with the configured clientId in that scenario (server accepts either), or would a fallback read be worth adding?
autoInstalledAppOrgConsumerKey = object.optString(AUTO_INSTALLED_APP_ORG_CONSUMER_KEY,
object.optString("beacon_child_consumer_key", null));(Same would apply to the secret, the Bundle constructor, and UserAccountManager.decryptUserData.)
This response was generated by an AI agent on behalf of @JohnsonEricAtSalesforce.
| public static final String TOKEN_FORMAT = "tokenFormat"; | ||
| public static final String BEACON_CHILD_CONSUMER_KEY = "beacon_child_consumer_key"; | ||
| public static final String BEACON_CHILD_CONSUMER_SECRET = "beacon_child_consumer_secret"; | ||
| public static final String AUTO_INSTALLED_APP_ORG_CONSUMER_KEY = "auto_installed_app_org_consumer_key"; |
There was a problem hiding this comment.
Scope vs. GUS story — confirming intent
I'm sure you decided this deliberately — the GUS story mentions keeping Java identifiers unchanged with no public API changes, but the PR renames constants, getters, and builder methods (public API break for 14.0). Just confirming this was an intentional expansion beyond what the story's agent wrote, since it seems like the right call for a major version.
This response was generated by an AI agent on behalf of @JohnsonEricAtSalesforce.
| InfoSection(title = BEACON) { | ||
| InfoRowView(label = BEACON_CHILD_CONSUMER_KEY, value = currentUser?.beaconChildConsumerKey) | ||
| InfoRowView(label = BEACON_CHILD_CONSUMER_SECRET, value = currentUser?.beaconChildConsumerSecret, isSensitive = true) | ||
| InfoRowView(label = AUTO_INSTALLED_APP_ORG_CONSUMER_KEY, value = currentUser?.autoInstalledAppOrgConsumerKey) |
There was a problem hiding this comment.
Minor: The UI section header still says "Beacon" (line 60). Probably intentional to keep it short, but mentioning in case it was just overlooked in the sweep.
This response was generated by an AI agent on behalf of @JohnsonEricAtSalesforce.
…y,secret} to auto_installed_app_org_consumer_{key,secret}
Updates only the string values parsed from the token endpoint response.
All code symbol names (constants, fields, getters, builder methods) are unchanged.
wmathurin
force-pushed
the
rename-beacon-child-consumer-keys
branch
from
1b37c45 to
4602aad
Compare
…eld absent
Checks auto_installed_app_org_consumer_{key,secret} first; falls back to
the old beacon_child_consumer_{key,secret} name for servers that have not
yet rolled out version 264.
LogRedactor now redacts both auto_installed_app_org_consumer_secret and beacon_child_consumer_secret. The old pattern is guarded with a TODO to remove it once server version 264 has rolled out everywhere.
|
I decided to only change the value of the fields we look for in the response and keep beacon in our code and tests. The changes were getting large and would make cherry picking harder. Further more AutoInstalledApp is a mouthful compared to Beacon. |
| tokenFormat = parsedResponse.optString(TOKEN_FORMAT); | ||
|
|
||
| // Beacon child fields expected when using a beacon app and web server flow | ||
| // TODO: Remove LEGACY_BEACON_CHILD_CONSUMER_* fallback once server version 264 has rolled out everywhere. |
There was a problem hiding this comment.
That way we can go against older instances and it should still work.
2 participants
Summary
Updates the token endpoint wire-format keys and adds a legacy fallback for servers that haven't yet rolled out version 264.
When parsing the token response, the SDK now:
auto_installed_app_org_consumer_{key,secret}(new field name)beacon_child_consumer_{key,secret}if the new field is absentA
TODOcomment marks both fallback constants and the fallback logic for removal once server version 264 has rolled out everywhere.All code symbol names (
BEACON_CHILD_CONSUMER_KEY/SECRETconstants,beaconChildConsumerKeyfield/getter, builder methods, etc.) are unchanged.Files changed
OAuth2.java— new constant values + legacy fallback constants + parsing updated with new-then-old fallbackUserAccount.java—BEACON_CHILD_CONSUMER_KEY/SECRETconstant values updatedAuthenticatorService.java—KEY_BEACON_CHILD_CONSUMER_KEY/SECRETconstant values updatedLogRedactor.kt— redaction regex pattern string updatedUserAccountTest.java— test map key strings updatedSalesforceLoggerTest.java— test JSON key strings updatedTest plan
connectedAndroidTestpasses (requires connected device)Related