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

[JWT] App startup #1473

Open
wants to merge 17 commits into
base: internal_dump_method
Choose a base branch
from

Conversation

nan-li
Copy link
Contributor

@nan-li nan-li commented Aug 22, 2024

Description

One Line Summary

Handles basic-level app startup for Identity Verification - on new install and minor migrations on upgrades.

Details

Internal JWT Config management and listeners

  • One of the primary complexities is handling the state when an app is first installed or updated, but JWT is unknown. Once this value is received, it can be cached and future runs will be simple.
  • Make OSUserJwtConfig object to handle auth required status, etc.
  • User manager owns an instance of the OSUserJwtConfig and passes it to sub-components like Operation Repo and Executors who will basically be "paused" until they know if auth is required or not.
  • Operations can enqueue while the SDK is in an "unknown" state, they will just be blocked from sending.
  • Once remote params returns, the SDK learns if auth is required, and this value will be cached for the future. The OSUserJwtConfig fires listeners waiting on this value. If components learn that auth is on, they will process their queues and remove operations that are not valid. Then, the components will start operating normally.
  • There are lots of print()s to help debug, these will be removed eventually.

Request objects updated to consider JWT

  • User request instances already have a prepareForExecution() method that indicates if this request can be sent yet. For example, does the onesignal ID exist to make this request.
  • Piggyback off this existing method to check for auth and block sending this request if auth is required but invalid, or auth is unknown, etc.
  • We still keep the onesignal ID property on all requests as a way to know if the user has actually been created on the server and to check for the post-create cool-off period. When the request is sent, it will use either the onesignal ID or the external ID based on JWT on/off.
  • Requests Updated:
    • OSRequestCreateUser
    • OSRequestFetchUser
    • OSRequestAddAliases
    • OSRequestRemoveAlias
    • OSRequestUpdateProperties
  • Requests Not Allowed with Identity Verification:
    • OSRequestFetchIdentityBySubscription: This is dropped and the push subscription is included in any upcoming UserCreate calls.
    • OSRequestIdentifyUser: This is translated into a UserCreate.

What has been tested in this PR

  • New install with Identity Verification on, and call login with correct JWT, add tag + email, login to another user with correct JWT, and add tag + email
  • New install with Identity Verification turned off
  • Updating a token using [OneSignal updateUserJwt:"externalUserId" withToken:"token"]
  • Migration from a previous version
  • Upgrading from player model
  • Please see Manual Testing below for more details

What is not included in this PR

  • Any subscriptions related changes needed including Push Subscription updates, fetch IAM, Live Activities, or any request outside of the User module
  • Error handling - 401 responses, firing invalid listeners, retrying
  • Logging into new users with valid JWT if the previous user has still not successfully logged in, future logins are blocked
  • Logout
  • There are existing tangled dependencies that are not ideal, and this PR includes more that could be refactored better.

Motivation

Support Identity Verification

Testing

Unit testing

🚧 WIP

Manual Testing

How to Test:

  1. The Dev App is already pointing at staging with the bundle ID of com.onesignal.example.staging. Update the app ID to either 168... to test Identity Verification off, and 013... to test Identity Verification on. This is documented somewhere and please reach out for the keys and IDs.
  2. Use the "Get Tags" button on the Dev App to print information for testing
  3. Fill in an EID and token and use the Login button or Update button to login or update token.
New install - Identity Verification is off - no login is called
  1. New install, see that no requests go through
  2. Remote params returns and mock a response of "off"
  3. Internal listeners fire and the anonymous user is created with the push subscription
  4. Send tags works, update push sub works
  5. Next cold start, Identity Verification is uncached, "off" is the starting state and things proceed as normal. No listeners fire.
New install - Identity Verification is ON - then login is called
  1. New install, see that no requests go through
  2. Remote params returns and mock a response of "on"
  3. Internal listeners fire, no requests go through
  4. Call login with a valid token
  5. Create User is sent with the push subscription, and succeeds
  6. Response is received and hydrated, send tags works
  7. Fetch IAM and update push subscription does not work, it returns 401
  8. Next cold start, Identity Verification is uncached, "on" is the starting state and things proceed as normal. No listeners fire. Fetch user by EID to hydrate works, session count is sent.
Upgrade from main - Identity Verification is ON
  1. On main, turn off connection, do a new install and call:
[OneSignal login:@"nanaug23a"];
[OneSignal.User addTagWithKey:@"from" value:@"main"];
[OneSignal.User addEmail:@"test@domain.com"];
  1. See that no requests go through due to connection
  2. Update app to this branch and open app
  3. The operations are uncached but not requests go through due to unknown auth
  4. Remote params returns and mock a response of "on"
  5. Internal listeners fire, no requests go through due to missing JWT token
  6. Call [OneSignal updateUserJwt:@"nanaug23a" withToken:@"validToken"] for the external ID that was logged into.
  7. Create User is sent with the push subscription, the tags is sent and the create email is sent. They are successful.
Upgrade from player model - Identity Verification is ON

This is the test process I did:

  1. On player-model-main, do a new install and I did not set external ID.
  2. The player is created. Check the player ID and push token in the dashboard. Kill app.
  3. Update app to this branch and open app
  4. The cached data is read but no user requests are made. Get IAM is automatically sent.
  5. Remote params returns and mock a response of "on". The OSRequestFetchIdentityBySubscription that was previously generated is dropped.
  6. Nothing happens.
  7. Then login with a JWT but forget to include the push subscription ID
  8. Create User is sent with the local push subscription read from cache (this was the player) and includes the player ID and push token, but receive a 401 due to missing push subscription ID in claims.
  9. Update the jwt token with the subscription ID
  10. Create User is re-sent successfully. Fetch user happens.

Affected code checklist

  • Notifications
    • Display
    • Open
    • Push Processing
    • Confirm Deliveries
  • Outcomes
  • Sessions
  • In-App Messaging
  • REST API requests
  • Public API changes

Checklist

Overview

  • I have filled out all REQUIRED sections above
  • PR does one thing
  • Any Public API changes are explained in the PR details and conform to existing APIs

Testing

  • I have included test coverage for these changes, or explained why they are not needed
  • All automated tests pass, or I explained why that is not possible
  • I have personally tested this on my device, or explained why that is not possible

Final pass

  • Code is as readable as possible.
  • I have reviewed this PR myself, ensuring it meets each checklist item

This change is Reviewable

@nan-li nan-li mentioned this pull request Aug 22, 2024
18 tasks
@emawby emawby self-requested a review August 22, 2024 18:22
@emawby emawby self-assigned this Aug 22, 2024
@nan-li nan-li force-pushed the identity_verification_app_startup branch 4 times, most recently from 6fe9b03 to 4827f36 Compare August 22, 2024 19:56
@nan-li nan-li force-pushed the internal_dump_method branch 2 times, most recently from 186c65d to 35677bc Compare August 22, 2024 23:26
@nan-li nan-li force-pushed the identity_verification_app_startup branch from 4827f36 to a012272 Compare August 23, 2024 15:41
* Add text fields and buttons for testing
* Use staging
* remove app clips
* Make Client more verbose with headers
* Make OSUserJwtConfig object to handle auth status etc
* User manager owns an instance of the JWT Config
* Add `OSUD_USE_IDENTITY_VERIFICATION` flag to OneSignalCommonDefines
public updateUserJwt method
* User request instances already have a `prepareForExecution()` method that indicates if this request can be sent yet. For example, does the onesignal ID exist to make this request.
* Use this existing method to check for auth and block sending this request if auth is required but invalid, or auth is unknown, etc.

* OSRequestFetchUser will have onesignalId as a property, regardless of JWT on or off. The aliasLabel and aliasId pair is already expected to be onesignal ID, so make it explicit.
* Keeping the onesignal ID can be used to know if the user has actually been created on the server and to check for the post-create cool-off period. The request will be translated to use the onesignal ID or the external ID based on JWT on/off.

Requests Updated:
* OSRequestCreateUser
* OSRequestFetchUser
* OSRequestAddAliases
* OSRequestRemoveAlias
* OSRequestUpdateProperties

Requests Not Allowed with Identity Verification:
* OSRequestFetchIdentityBySubscription
* OSRequestIdentifyUser
* Identity Model Store Listener will ignore it so no Deltas will be enqueued
* As a refresher, the Identity Model Repo holds all Identity Models present during an app run, which can include past users that have pending updates, while the Identity Model Store contains only the current user's Identity Model.
* Let the OSIdentityModelRepo be the listener for changes to JWT token updates, and it needs to pass on that information to the User Manager who manages the JWT Config and fires other listeners of token changes.
Updates to:
* OSPropertyOperationExecutor
* OSIdentityOperationExecutor
* OSUserExecutor
Updates to OSSubscriptionOperationExecutor is still to be done.
* Refactor from a static shared instance to a instance managed by User Manager
* Operation Repo does not flush while Identity Verification is unknown
* Currently it is not going to process Deltas based on JWT. Executors will.
Comment on lines 41 to 52
/// Needs `onesignal_id` without JWT on or `external_id` with valid JWT to send this request
func prepareForExecution(newRecordsState: OSNewRecordsState) -> Bool {
if let onesignalId = identityModel.onesignalId,
newRecordsState.canAccess(onesignalId),
let appId = OneSignalConfigManager.getAppId()
{
self.addJWTHeader(identityModel: identityModel)
self.path = "apps/\(appId)/users/by/\(OS_ONESIGNAL_ID)/\(onesignalId)/identity"
return true
} else {
let alias = getAlias(identityModel: identityModel)
guard
let onesignalId = identityModel.onesignalId,
newRecordsState.canAccess(onesignalId),
let aliasIdToUse = alias.id,
let appId = OneSignalConfigManager.getAppId(),
addJWTHeaderIsValid(identityModel: identityModel)
else {
return false
}
Copy link
Contributor Author

Choose a reason for hiding this comment

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

consider removing the repetition, OSUserRequest can be a class instead of protocol or there can be another helper that prepare calls

Copy link
Contributor

@emawby emawby left a comment

Choose a reason for hiding this comment

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

discussed changes to the requests to not duplicate code in prepareForExecution

@nan-li
Copy link
Contributor Author

nan-li commented Aug 27, 2024

Updated: tested player model migration and seems to work as well.

* Set most things to not require auth / JWT off.
* Multiple requests are making the same user-related requirement checks.
* Put this into a helper function.
* Since each request sets its own path at execution time with an appropriate app ID and alias, the app ID and alias are two separate checks.
@nan-li nan-li requested a review from emawby August 29, 2024 18:18
@nan-li
Copy link
Contributor Author

nan-li commented Aug 29, 2024

Badge tests still flaky: OneSignalNotificationsTests.testDontclearBadgesWhenAppBecomesActive()

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

Successfully merging this pull request may close these issues.

2 participants