-
Notifications
You must be signed in to change notification settings - Fork 429
Allow consumer key to be defined at runtime by application #3946
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
Conversation
…e dynamic config (WIP)
…g or some dynamic config (WIP)" This reverts commit 7356c32.
Made sections more readable / collapsable etc
…given the login host and will return the desired app config.
Also showing scopes in config screen and allowing user to enter scopes for dynamic config
NB: using "instant login" for authenticated tests
Generated by 🚫 Danger |
Clang Static Analysis Issues
Generated by 🚫 Danger |
| request.oauthClientId = self.oauthClientId; | ||
| request.oauthCompletionUrl = self.oauthCompletionUrl; | ||
| request.scopes = self.scopes; | ||
| request.oauthClientId = appConfig != nil ? appConfig.remoteAccessConsumerKey : self.oauthClientId; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's the heart of the change
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't see it in the MDM docs, but I noticed that we have the consumer key and callback URL as managed preferences that get set on the manager here. Do we still support that and should the runtime one take precedence if we do?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's a bit messy. SFUserAccountManager has clientId/callback URL etc on the shared instance / which is backed by prefs and initially populated from the static bootconfig.
For login, I now allow the app to inject alternate values in which case the shared instance values / prefs are not used but left alone (but they are not overridden either). The client id etc used during login is saved in the user account creds (that's not a new behavior) so will be used during refresh.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also I'm thinking of having the new block take a callback to allow the app to do an async operation (e.g. network call) to figure out what client id to use. I believe that's how SApp wants to use it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Now it's async: see 5ff8ac4
|
|
||
| // Configure launch arguments | ||
| app.launchArguments = [ | ||
| "-creds", credentialsString |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Using instant login !
| import XCTest | ||
|
|
||
| /// Helper functions for AuthFlowTester UI Tests | ||
| class TestHelper { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we do more UI tests in the main repo, we should move that class out to SalesforceSDKCore (it complements TestSetupUtils).
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## dev #3946 +/- ##
==========================================
- Coverage 63.32% 62.05% -1.27%
==========================================
Files 250 249 -1
Lines 22548 22472 -76
==========================================
- Hits 14278 13946 -332
- Misses 8270 8526 +256
🚀 New features to boost your workflow:
|
Static configuration can be edited Took out broken new tests (will bring them back if they make sense)
- changed SFSDKAppConfigRuntimeSelectorBlock to take a callback parameter - renamed runtimeSelectedAppConfig to appConfigForLoginHost and it now takes a callback parameter - moved the call to appConfigForLoginHost in SFUserAccountManager to the async part of authenticateWithRequest (leaving the building of the auth request unchanged from before this PR) - updated tests / sample app
It's not high value and we will be back in that code when we will add support for refresh token migration
| <dict> | ||
| <key>keychain-access-groups</key> | ||
| <array> | ||
| <string>$(AppIdentifierPrefix)com.salesforce.mobilesdk.sample.authflowtester</string> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are we going to use the app for shared keychain testing? Asking because a lot of our apps have a shared keychain set by default but if we don't need it, it's easier to do on-device testing if we don't specify one
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are you saying it would be better to remove this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 (unless you need it)
Have the default bootconfig be the "old" one (opaque token) and the dynamic one be the "new" one (jwt based token)
| // func testSessionDetailScreenIsVisible() throws { | ||
| // // Verify we're on the session detail screen (not config picker) | ||
| // XCTAssertTrue(app.navigationBars["AuthFlowTester"].waitForExistence(timeout: 10)) | ||
| // | ||
| // // Should see authenticated UI elements | ||
| // XCTAssertTrue(app.buttons["Revoke Access Token"].waitForExistence(timeout: 5)) | ||
| // XCTAssertTrue(app.buttons["Make REST API Request"].waitForExistence(timeout: 5)) | ||
| // | ||
| // } | ||
|
|
||
| // | ||
| // TODO write more tests | ||
| // |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this be in the PR?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure these tests on the test app are very useful overall.
We probably want to build robust UI tests (most likely in the UI-Tests repo) that use the test app to test the various login flows.
I can leave the tests in for that PR but might remove them entirely in some future PR (before we tag for the next release).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Or I can remove them now?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Either way is fine by me if we have stories test this in the other repro. Do you want me to create them?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I will remove them from here. The code still lives in my fork / branch so could be used for inspiration for the UI-Tests work. Please go ahead and create the new stories.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Removed the UI tests with 90df65a
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done. W-20117061 and W-20117067.
brandonpage
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM! Test failures are concerning though.
We are planning to build robust UI tests that will leverage AuthFlowTester to test various login flows etc
|
There are a couple of test failures in SalesforceSDKCore on CI. I don't think they are related to the change. |
(Apologies for the large PR)
Motivations:
Overview:
bootConfigRuntimeSelectortoSalesforceManagerSalesforceSDKManagerTests.mandSFUserAccountManagerTests.mAuthFlowTesterwas added which allows manual testing of the new functionality - it will become our go to sample app for login related changes (e.g. the upcoming refresh token migration support)Screenshots from new sample app: