Streamline initialization of AppContext objects without singletons,
especially because some are interconnected.
Rethink ProfileProcessor to be the only gateway of profile processing
for:
- Include
- Save
- Connect
Provide closures with access to the IAPManager for eligibility checks.
Finally, take a ProfileProcessor parameter in:
- ProfileManager (for isIncluded and willSave)
- ExtendedTunnel (for willConnect)
so that it's used implicitly without having to put it into the SwiftUI
environment.
Other than that:
- Move AppError to CommonLibrary
- Skip decoding of attributes from Core Data because they are already
part of the profile
- Perform profiles removal in a single publisher, in
reloadRemoteProfiles() after importing remote profiles
- Only force a new lastUpdate/fingerprint if profile is saved locally,
DO NOT alter them if imported from remote repository because this would
cause a re-save on iCloud
- Profiles were purged twice on launch in the main macOS app
Add profile attribute `isAvailableForTV` and set specific behavior to:
- Observe shared profiles and delete locally when unshared
- Only keep locally those profiles with the TV attribute enabled
- Add toggle in UI
Additions to the domain:
- Update rather than replace existing Core Data profile
- Attach ProfileAttributes to Profile.userInfo
- Store one-off `fingerprint` UUID on each save
With the above in place, fix and improve ProfileManager to:
- Use `fingerprint` to compare local/remote profiles in history and thus
avoid local re-import of shared profiles
- Use `deletingRemotely` to delete local profiles when removed from the
remote repository (default false)
- Use `isIncluded` filter to exclude certain profiles from the local
repository (default nil)
The dismissal action waited until the current connection was
disconnected.
Consider that AppContext makes the explicit .connect() redundant,
reconnection is already happening after saving a profile while
connected.
- [x] tvOS: When profile selector appears, if it's closed without
selecting any profile, it instantly reopens
- [x] Set initial focus in OpenVPN credentials
Define two styles for interactive login:
- Modal (iOS/macOS) - Form inside NavigationStack
- Inline (tvOS) - VStack
Requires OpenVPN credentials view to be container-agnostic.
Play with focus to improve the overall TV experience.
Rather than defining a new enum, tie ModuleType to ModuleHandler names
from PassepartoutKit.
Also a way to reuse ModuleType.localizedDescription on both Module and
ModuleBuilder implementations.
Start with the profile tab. Left to do: search and settings.
Fixes and refactoring:
- Listen to changes in current profile in ExtendedTunnel
- Externalize style from TunnelToggleButton and ConnectionStatusText
(renamed from View)
- Add ThemeCountryText for convenience
- Move InteractiveView to AppUI for use in TV, with
OpenVPNCredentialsView
- Move non-UI entities to AppLibrary (IAP, ExtendedTunnel,
ProfileProcessor)
- Take API out of CommonLibrary (tunnel extension does not need it)
- Reorganize theme views/modifiers into separate files
The biggest issue is the hidden and scattered use of both Tunnel and
ConnectionObserver. Only use the latter, and rename it to ExtendedTunnel
for being now a full wrapper around Tunnel (e.g. for .connectionStatus).
In general, restrict the use of EnvironmentObject to:
- Theme
- IAPManager
- ProfileProcessor
- ProviderManager
Always be explicit about:
- ProfileManager
- ExtendedTunnel
Contextually, move some UI entities to the base AppUI target.
#779 was happening because environment objects were set on contentView,
which is not the _outmost_ root view. This clarifies why the Theme
object was not being found in ThemeLockScreenModifier.
Also, do not hardcode LogoView as lock view.
- Refactor AppUI initialization in all platforms (sort of template
method pattern)
- Make AppMenu specific to macOS by wrapping it into a folder for
consistency
- Add SizeClassProviding for repeated checks on hsClass/vsClass
Fixes#659
Encode OpenVPN password + OTP in tunnel rather than in the app.
Encoding them upfront in the app ends up persisting the profile with the
combined password. Update the library with a new OTP field in
OpenVPN.Credentials, so that the password encoding is performed [on the
fly in the
tunnel](https://github.com/passepartoutvpn/passepartoutkit-source/pull/398).
Similar to how provider modules are generated.
This is likely a regression caused by migrating to NEProfileRepository,
because starting a connection causes the profile to be saved to NE with
the encoded password. Later, the profile is restored from NE and
therefore contains the encoded password.
- Let the user close the window, the app will just remain alive in the
status bar
- Accordingly, replace "Confirm quit" preference with the option to stay
alive in the status bar
- Add "About..." item
Split AppUI into AppUI and AppUIMain to allow for a new, simplified
AppUITV target tailored for the Apple TV.
As a PoC, present a view with a list of the shared profiles.
Add a status menu via SwiftUI MenuBarExtra where to:
- Show/hide app
- Launch on login via "Login Item" target
- Toggle profiles on/off
Only weird that the login item is not added to the list of "Open at
Login", but to "Allow in the Background", see
https://github.com/pilotmoon/Scroll-Reverser/issues/165
Requires some refactoring to bring AppContext initialization to the
AppDelegate.
Fixes#617Fixes#482Fixes#696Fixes#505
Countries are filtered through the latest servers list. If a country is
chosen, the countries picker only lists the currently selected country,
because there are no servers from other countries.
Update the library to prefetch the available countries per category.
At module creation time, choose whether to use a provider or import a
configuration file. After the import, the provider picker is hidden for
mutual exclusion.
For clarity, refactor the configuration part of OpenVPNView into a
ConfigurationView subview.
Also, improve filters by constraining related fields:
- Pick countries from the filtered category
- Pick presets from those available in the currently filtered servers
Closes#705
- iOS: Add category name to clarify servers context
- iOS: Show "No servers" when list is empty
- macOS: Show "Connect" in server selector when presenting from home
- Add last update to issue report
- Refactor provider strings
First of all, add country flags assets. Then, present provider server
selector:
- From installed profile view, specifically from a button with the flag
of the current country
- From profile context menu
- On toggle profile when no server is selected
Closes#711
A NavigationLink in VPNProviderContentModifier raised a few questions
about the navigation approach in module views. It turned out that having
a Binding to a local ObservedObject (ProfileEditor) is a recipe for
disaster.
Therefore:
- We don't need a binding to the editor module (the draft), because by
doing so we end up _observing_ the same changes from two properties, the
binding and the editor. This seems to drive SwiftUI crazy and freezes
the app once we navigate from the module to another view (e.g. in
OpenVPN the credentials or the provider server). Use the module binding
as a shortcut, but do not assign the binding to the view to avoid
unnecessary observation.
- Keep .navigationDestination() in the module view, and pass a known
destination to VPNProviderContentModifier. This will save the modifier
from creating a nested NavigationLink destination. The
VPNProviderServerView is now openly instantiated by the module view when
such destination is triggered by the NavigationLink in the modifier.
- Do not implicitly dismiss VPNProviderServerView on selection, let the
presenter take care. In order to do so, we add a .navigationPath
environment key through which the module view can modify the current
navigation stack.
- Move disclosable menu from installed profile view to
ThemeDisclosableMenu
- Drop unnecessary configurationType modifier parameter
- Reorg view-related module extensions to separate files
- Reuse .flow fields instead of single blocks
- Show specific error on missing provider server selection
- Drop logic behind connection button tasks, let the library handle
concurrency
- Drop AppContext observation of saved profiles for reconnection, let
save() actively decide
- NETunnelStrategy and NETunnelManagerRepository are now a single entity
- Avoid flickering when toggling same profile
Currently, NEProfileRepository decodes profiles from ALL NE managers on
any update. This is undesirable considering that:
- Profiles are only _added_ by the app
- Externally, profiles can only be _removed_
Therefore:
- Observe the initial managers to decode the initial profiles from them
- Publish values manually on save/delete (to ProfileManager eventually)
- Observe the subsequent updates for when a profile is removed
externally, i.e. its ID doesn't appear in managers
Fixes#741
Resolve some flickering and state inconsistency due to overextended
observation of VPNProviderManager. Narrow down its scope to
VPNProviderServerView.
The downside of that, for now, is that servers are loaded "lazily late",
but this flow will make region selection from home easier.
Finally, show filters in popover on iPad.
Improve rendering and work around some SwiftUI bugs, e.g. with .menu
Picker on iOS (use .navigationLink instead).
Here goes the hierarchy bottom-up:
- ProviderPicker: a Picker wrapper built around ProviderManager
- ProviderContentModifier: adds a ProviderPicker on top and replaces the
content with a set of provider selectors when a provider is selected
- VPNProviderContentModifier: wrapper for ProviderContentModifier that
adds a VPN server selector
- OpenVPNView: provides a view of specific OpenVPN settings, and adds a
credentials selector to the provider/server selectors provided by
VPNProviderContentModifier
When e.g. a OpenVPNModule is created without a configuration and a
provider/server is then selected, the ProfileProcessor class serializes
the profile with the provider configuration injected. When the module is
re-edited, we can see the provider server configuration in the module
after selecting "None" as provider.
Instead, validate the provider modules in ProfileProcessor, but generate the provider configuration on the fly in the tunnel.
Update library to allow optional VPN configurations. This in turn allows
a module to be used with a provider, where the configuration is
generated on the fly.
- [x] NE managers were not deleted when unable to be decoded to a
profile
- [x] Keychain items were not deleted on profile removal
- [x] Perform clean-up on app launch
- [x] Perform clean-up on app active
Prematurely merged as #727 then reverted, this is the complete PR.
Initial integration of providers via API:
- Generic views and modifiers for provider/server selection
- Add in OpenVPNView
- Prepare in WireGuardView
Also:
- Introduce ProfileProcessor, move IAP processing there
- Move .asModuleView() to ModuleViewModifier for proper animation
- Use .themeModal() rather than .sheet()
Mainly:
- Aggregate shared/mock entities in less scattered files
- Review package dependencies
Also:
- Decouple ProfileRepository from Core Data Repository in UtilsLibrary
(filters done by ProfileManager)
Profiles are being maintained in two places:
- Core Data
- NetworkExtension
Core Data is redundant for local profiles, so make NetworkExtension the
only source of truth.
Remote profiles were never deleted. Now, when removing a profile:
- The profile is deleted from the local store
- The profile is deleted from the remote store
- Other synced devices receive the update and delete the profile from
their remote store
- However, they retain a local copy of the profile
- The copy doesn't appear as "Shared on iCloud" anymore
Also, fix SwiftUI not refreshing when remote profiles are updated. There
was no objectWillChange nor Published around
ProfileManager.allRemoteProfiles, and ProfileRowView was not treating it
as ObservedObject.
Closes#673
Follow the same approach as #636, because if no profiles are formerly
installed the first import will trigger a VPN permission alert. Weird
things may happen in that case if profiles are imported in parallel.
Keep two separate stores to accomplish per-profile sharing:
- Local store, where to push updates manually (save/remove/search)
- Remote iCloud store, where to pull updates from
A profile can be added/removed to/from the iCloud store so that other
devices can push/pull updates to it.
Consequently, updates to the iCloud store will NEVER cause a profile
deletion. Once removed, the profile will stay locally.
Fixes#586Fixes#555
Davide