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

bug: OnboardingService no longer supports activation #944

Closed
XavierChanth opened this issue Nov 21, 2024 · 11 comments
Closed

bug: OnboardingService no longer supports activation #944

XavierChanth opened this issue Nov 21, 2024 · 11 comments
Assignees

Comments

@XavierChanth
Copy link
Member

  • When calling OnboardingService.onboard with the cramSecret, it just onboards a random atSign from the keychain
  • When calling OnboardingService.authenticate with the cramSecret, it tries to pull an atSign from the keychain and throws with an uncaught exception
@gkc
Copy link
Contributor

gkc commented Nov 22, 2024

Walking through these issues with @sitaram-kalluri and @murali-shris & me transcribing our findings

  • When calling OnboardingService.onboard with the cramSecret, it just onboards a random atSign from the keychain

Yes - if setAtsign has not been called previously then this will happen. The immediate fix for this is to call setAtsign beforehand in your application code.

However clearly this is a bug and needs to be fixed. In general the use of the _atSign instance variable needs to be reviewed as well as all of the method parameters

  • When calling OnboardingService.authenticate with the cramSecret, it tries to pull an atSign from the keychain and throws with an uncaught exception

Yes we can see how that happens if the atSign previously hasn't been onboarded - i.e. no entry for it in the keychain. To avoid the issue, need to ensure you don't call authenticate in this situation (no entry in keychain, no keys supplied, only cram key supplied) but call onboard instead (with the caveat that you must call setAtsign before calling onboard)

@sitaram-kalluri @murali-shris can you verify the above with some demo app please? i.e.

  1. Reproduce the problems Xavier encountered
  2. Show how taking the steps outlined above successfully mitigate the issue

@XavierChanth I am assuming that your primary need here is to onboard and/or authenticate ... in both cases you need to use the onboard method which, if the atSign has already been onboarded (keychain entry exists) will try to authenticate, and if the atSign has not yet been onboarded, will onboard.

@sitaram-kalluri
Copy link
Member

sitaram-kalluri commented Nov 22, 2024

Adding to the above, the only time we wanted to call OnboardingService.authenticate is when we have atKeys file generated for an atSign and wanted to authenticate an atSign by supplying the atKeys file. In this case, set optional parameter jsonData with the atKeys file content.

@gkc
Copy link
Contributor

gkc commented Nov 22, 2024

Thanks @sitaram-kalluri

Once you've verified the mitigation for the issue Xavier is facing right now, please create a ticket to tidy up OnboardingService - first its method documentation, then parameter validations (e.g. in authenticate it looks like cramSecret and jsonData are mutually exclusive). Don't do anything more broad on implementation changes for now please; there need to be a design discussion with Xavier to agree the way forward.

@sitaram-kalluri
Copy link
Member

Thanks @sitaram-kalluri

Once you've verified the mitigation for the issue Xavier is facing right now, please create a ticket to tidy up OnboardingService - first its method documentation, then parameter validations (e.g. in authenticate it looks like cramSecret and jsonData are mutually exclusive). Don't do anything more broad on implementation changes for now please; there need to be a design discussion with Xavier to agree the way forward.

Sure, Gary.

@XavierChanth
Copy link
Member Author

XavierChanth commented Nov 22, 2024

Yes - if setAtsign has not been called previously then this will happen. The immediate fix for this is to call setAtsign beforehand in your application code.

The internal _atSign variable is used to store the currently onboarded atSign. If onboard fails, then _atsign should remain unchanged. The expected behavior is that when I call onboard. The atsign stored in the AtOnboardingRequest is the one used for onboarding.

This will cause breakages in changePrimaryAtsign if that fails. It won't affect NoPorts, but it will affect other apps.

@sitaram-kalluri
Copy link
Member

Thanks @sitaram-kalluri

Once you've verified the mitigation for the issue Xavier is facing right now, please create a ticket to tidy up OnboardingService - first its method documentation, then parameter validations (e.g. in authenticate it looks like cramSecret and jsonData are mutually exclusive). Don't do anything more broad on implementation changes for now please; there need to be a design discussion with Xavier to agree the way forward.

@gkc and @XavierChanth : Verified the fix suggested above and able to onboard an atSign successfully when setAtSign is invoked before calling the OnboardingService.onboard method. Also, if an atSign is onboarded successfully and keys are stored in the keychain manager, then calling onboard will authenticate the atSign successfully.

@XavierChanth
Copy link
Member Author

Adding to the above, the only time we wanted to call OnboardingService.authenticate is when we have atKeys file generated for an atSign and wanted to authenticate an atSign by supplying the atKeys file. In this case, set optional parameter jsonData with the atKeys file content.

Yes, but this is not what the rest of the code in at_onboarding_flutter was using that method to do. All of the existing activation code is calling authenticate with the cramkey.

@XavierChanth
Copy link
Member Author

XavierChanth commented Nov 22, 2024

Thanks @sitaram-kalluri

Once you've verified the mitigation for the issue Xavier is facing right now, please create a ticket to tidy up OnboardingService - first its method documentation, then parameter validations (e.g. in authenticate it looks like cramSecret and jsonData are mutually exclusive). Don't do anything more broad on implementation changes for now please; there need to be a design discussion with Xavier to agree the way forward.

The only proper way forward is to remove all the layers, including the OnboardingService, and replace it all with a proper utility class that provides a progress stream for the UI. Each one of the layers I found checks atServerStatus on its own before doing anything. The code as it is today, makes 3 or 4 api calls to the same thing before it does any work.

My previous recommendation about adding generic Keychain management to at_auth removes the need for the OnboardingService to exist.

@sitaram-kalluri
Copy link
Member

Created a clean ticket : #946

@gkc
Copy link
Contributor

gkc commented Nov 22, 2024

Yes all of this is a complete mess and has a bad case of code rot

@XavierChanth
Copy link
Member Author

I will uptake the same fixes I made to NoPorts back into this package once NoPorts is released

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

4 participants