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

VPN-5681 - remove iOS VPN profile when logging out or resetting #8329

Merged
merged 11 commits into from
Oct 24, 2023

Conversation

mcleinman
Copy link
Collaborator

Description

For several reasons (to make "reset and quit" cleaner, to clearly cut someone off after their subscription ends or they log out) we want to remove the VPN config from iOS System Settings. This does that.

We may want to add this functionality to non-iOS platforms, but I'm leaving that for the future.

Reference

https://mozilla-hub.atlassian.net/browse/VPN-5681
This also fulfills https://mozilla-hub.atlassian.net/browse/VPN-4216

Checklist

  • My code follows the style guidelines for this project
  • I have not added any packages that contain high risk or unknown licenses (GPL, LGPL, MPL, etc. consult with DevOps if in question)
  • I have performed a self review of my own code
  • I have commented my code PARTICULARLY in hard to understand areas
  • I have added thorough tests where needed

src/mozillavpn.cpp Outdated Show resolved Hide resolved
src/connectionmanager.cpp Show resolved Hide resolved
Copy link
Contributor

@MattLichtenstein MattLichtenstein left a comment

Choose a reason for hiding this comment

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

long overdue safety net here, nice job!

I think we'll also want to delete the tunnel any time we arrive in App::State::StateInitialize or App::UserState::UserNotAuthenticated. The most notable case I'm thinking of is when a device is deleted from another device and sets those states in MozillaVPN::reset()

src/mozillavpn.cpp Outdated Show resolved Hide resolved
@mcleinman
Copy link
Collaborator Author

long overdue safety net here, nice job!

I think we'll also want to delete the tunnel any time we arrive in App::State::StateInitialize or App::UserState::UserNotAuthenticated. The most notable case I'm thinking of is when a device is deleted from another device and sets those states in MozillaVPN::reset()

We start the app inStateInitialize, right? If that's the case, wouldn't connecting StateInitialize to removing the config end up with some bad side effects? (We could mitigate by only destroying it when we move into StateInitialize from another state, but that seems like an antipattern, and is fragile if we ever change the app to start in StatePreInit (and then go into StateInitialize or something like that).

@MattLichtenstein
Copy link
Contributor

We start the app inStateInitialize, right? If that's the case, wouldn't connecting StateInitialize to removing the config end up with some bad side effects?

haha yea definitely don't want to remove the config on every app launch. what about App::UserState::UserNotAuthenticated? that seems appropriately related to when we want to remove the config. I wonder if we unauthenticate before quitting on a reset and quit... doubt it though. maybe there is no one size fits all here and we just need to remove the config on a couple of different occasions

@Gela
Copy link

Gela commented Oct 19, 2023

Can we add a functional test for this change? Not sure if there's a way to test toggling on the VPN from systems setting but I think we can write a test for the other scenario VPN cannot be turned on on a first attempt after a reset and quit action

@mcleinman
Copy link
Collaborator Author

We start the app inStateInitialize, right? If that's the case, wouldn't connecting StateInitialize to removing the config end up with some bad side effects?

haha yea definitely don't want to remove the config on every app launch. what about App::UserState::UserNotAuthenticated? that seems appropriately related to when we want to remove the config. I wonder if we unauthenticate before quitting on a reset and quit... doubt it though. maybe there is no one size fits all here and we just need to remove the config on a couple of different occasions

Just looked at this a bit, and it seems like every use of UserState::UserNotAuthenticated leads to logging out - it seems unneeded here, but if you want to be extra defensive I can add a listener for the userStateChanged signal in ConnectionManager and run the "remove profile" code there.

gleanDebugTag:settingsHolder->gleanDebugTagActive()
? settingsHolder->gleanDebugTag().toNSString()
: @""
serverIpv6Gateway:config.m_serverIpv6Gateway.toNSString()
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

this was a linter change when merging main back in

@@ -47,7 +47,7 @@ class TunnelManager {
}
}

static func withTunnel(_ f: (_ tunnel: NETunnelProviderManager) throws -> Any) -> Any? {
@discardableResult static func withTunnel(_ f: (_ tunnel: NETunnelProviderManager) throws -> Any) -> Any? {
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

This allows us to ignore the result, which gives some cleaner code where we were using this.

@mcleinman
Copy link
Collaborator Author

Can we add a functional test for this change? Not sure if there's a way to test toggling on the VPN from systems setting but I think we can write a test for the other scenario VPN cannot be turned on on a first attempt after a reset and quit action

Good call, working on test now.

@@ -189,6 +193,14 @@ module.exports = {
`Command failed: ${json.error}`);
},

// This is used when hitting the "Reset and Quit" button
Copy link

Choose a reason for hiding this comment

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

Can you expand on this comment? e.g. why are we accepting any result

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Thanks. Done - let me know if you think we need some more here.

}
},

async awaitConnectionOkay() {
Copy link

Choose a reason for hiding this comment

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

Can you add a comment explaining what this helper does?

And possibly come up with a more descriptive name? Something like waitForVPNToActivateSuccessfully()

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Thanks. Done and done - let me know if you think we need some more here.

tests/functional/helper.js Outdated Show resolved Hide resolved
Copy link

@Gela Gela left a comment

Choose a reason for hiding this comment

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

Wooo! Thanks for figuring out a way to add a test for this too 👌🏽

Copy link
Contributor

@MattLichtenstein MattLichtenstein left a comment

Choose a reason for hiding this comment

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

nice job!

question though: our functional test suite doesn't currently run on mobile clients, and these changes are iOS specific. is there any benefit to the added functional test?

@mcleinman
Copy link
Collaborator Author

question though: our functional test suite doesn't currently run on mobile clients, and these changes are iOS specific. is there any benefit to the added functional test?

Correct - this is something I mentioned when Gela and I paired on this yesterday. This doesn't actually run on iOS, but in my opinion the benefits are:

  • At some point hopefully we'll run functional tests there, and then we'll have this test ready to go.
  • It helps us stay true to our "always add tests" mission.

@Gela
Copy link

Gela commented Oct 24, 2023

@MattLichtenstein In addition to what Matt C said, we are also testing the "Reset and Quit" functionality on Desktop in general which I believe wasn't being done previously.

@mcleinman mcleinman merged commit 35578de into main Oct 24, 2023
85 checks passed
@mcleinman mcleinman deleted the vpn-5681-clear-ios-vpn-setup branch October 24, 2023 18:35
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.

3 participants