This patch adds a notification for updates for macos clients when they
are on an old version.
This is how it looks:
<img width="497" alt="image"
src="https://github.com/user-attachments/assets/829044fd-e8bc-4b47-b64d-67b8ef72adb0">
The orange dot is shown regardless of the notification being dismissed.
If the notification is dismissed by the "Dismiss this version" button,
until there's no new version there won't be notifications.
Updates are check at the start of firezone and every 6 hours after. This
is saved in `UserDefaults`.
Permissions for notifications needs to be allowed so that it's show,
this should be done by the `requestAuthorization`
Also, when an update is available a new `Update available...` option
appears in the menu
<img width="230" alt="image"
src="https://github.com/user-attachments/assets/16d7fea8-3cf5-4711-9d42-5c49faffe6c8">
This option, same as the notification takes you to the appstore.
---------
Signed-off-by: Jamil <jamilbk@users.noreply.github.com>
Co-authored-by: Jamil <jamilbk@users.noreply.github.com>
When the addressDescription looks like a URI, we highlight it with
markdown and set its click handler to open the URL when clicked. We were
also making it bold, which seems to break macOS's menubar width
calculation, causing the field to truncate (typically after `https://`)
instead of expanding the container to contain it.
By removing the bold formatting, the container is properly sized, fixing
the display issue.
# Before
<img width="553" alt="Screenshot 2024-09-07 at 10 44 37 AM"
src="https://github.com/user-attachments/assets/4596bf54-918d-4a59-81d6-a18e436da5ad">
# After
<img width="569" alt="Screenshot 2024-09-07 at 10 45 38 AM"
src="https://github.com/user-attachments/assets/0400731f-e189-4416-a670-d5c3b314d71b">
With this PR we made internet resource disabled by default.
Since no other resource is disalable and internet resource behavior is
particular we remove all client code to make non internet resource
disalable.
Also, since the portal never makes the internet resource that can't be
disabled we remove the whole code path to handle that.
Additionally, some other smaller refactors across the UI wrt internet
resource
Fix#6509
---------
Signed-off-by: conectado <gabrielalejandro7@gmail.com>
Co-authored-by: conectado <conectado@conectados-MacBook-Air.local>
Co-authored-by: Thomas Eizinger <thomas@eizinger.io>
On Apple, we try to be smart about triggering connlib's `reset()` in
order to keep from triggering endless update loops. This can happen
because connlib itself triggers path monitoring updates through
onUpdateRoutes and such.
Before, we only kept track of whether our primary interface changed in
order to consider the path updated. Now, we also track IPv4/IPv6
connectivity and the network's available gateways (read: routers) to
trigger changes. This fixes the case where our interface loses or gains
IPv4 / IPv6 connectivity, or the router address changes.
Fixes#6515
---------
Signed-off-by: Jamil <jamilbk@users.noreply.github.com>
Co-authored-by: Thomas Eizinger <thomas@eizinger.io>
This publishes the 1.3.0 clients and gateways so that Internet Resources
will work.
The feature is still disabled for the Stripe plans until we publish the
launch post. Select customers have the feature enabled.
Closes#2667
[Refs](https://github.com/firezone/firezone/pull/6299#discussion_r1724108733)
The problem right now, after #6325 we send the internet resource up to
the clients. The clients expect a certain format for the resources and
panic if it isn't followed.
Particularly, in the case of no `address` or no `name`.
To fix this, we add a name and an address for the internet resource when
it is converted to the callback type.
Setting the `name` at that point actually makes a lot of sense since it
homogenizes the name across all platforms. But the internet resource
having an address makes no sense.
So in a next PR, when I do the last UI changes I plan to make `address`
optional for all resources on the clients and specialize the display of
the internet resource.
For now I wanted to get this in so that we don't ever panic on the
internet resource existing. (This was tested on all platforms and it
works)
Currently, `connlib` can only handle "simple" DNS wildcards where `*`
matches any number of subdomains, including zero and `?` matches a
single subdomain.
With this PR, we expand `connlib'`s capabilities to allow for a much
more complex matching of domains that more closely resembles glob
patterns:
- `**` matches any number of subdomains. This supersedes the previous
`*` operator.
- `*` matches a single subdomain. This supersedes the previous `?`
operator.
- `?` matches a single character. This wasn't possible before.
- Additionally, any of these can be combined. Previously, only `*` or
`?` was allowed and they were only accepted at the front of the domain
name pattern.
Resolves: #5056.
---------
Signed-off-by: Thomas Eizinger <thomas@eizinger.io>
Work for #6074 equivalent to #6166 for MacOS
MacOs view:
<img width="547" alt="image"
src="https://github.com/user-attachments/assets/f465183e-247b-49b5-a916-3ecc5f0a02f4">
iOS(ipad) view:
Other than implementing the resource disabling, this PR also refactor
the IPC between the network extension and the app so that it's some form
of structured IPC instead of relying on it being deserializable to
string to match the message.
One big difference with Android is that we don't introduce the concept
of a `ResourceView` for swift, the main reason for this is that on iOS
the resources are bound to the view instead of just being a parameter
for creating the view. So if we modify the `disabled` property it'd
update the UI unnecessarily, also it'd update the `Store` value for the
resource and then we need to copy that over again to the view. Making it
easier to go out of sync.
Connection roaming within `connlib` has changed a fair-bit since we
introduced the `reconnect` function. The new implementation is basically
a hard-reset of all state within `connlib`. Renaming this function
across all layers makes this more obvious.
Resolves: #6038.
On macOS and iOS, the TunnelManager instance stays active across
sessions. This contains a Resource cache used to fetch Resources from
the tunnel process.
This cache wasn't cleared across sessions, so the first time the
callback fired the Resources shown were the ones from the last session.
After `1s`, they were correctly set to the current session's Resources
due to the `beginUpdatingResources` timer.
We were already clearing the stored Hash of the Resource cache on
disconnect, but not the Resource cache itself. This patch fixes that bug
by re-initializing the cache when the tunnel session is `disconnected`.
The [HTTP 1.1 RFC](https://datatracker.ietf.org/doc/html/rfc2616) states
that HTTP headers should be US-ASCII. This is not the case when the
macOS Client is run from a host that has a non-English language selected
as its system default due to the way we build the user agent.
This PR fixes that by normalizing how we build the user agent by more
granularly selecting which fields compose it, and not just relying on
OS-provided version strings that may contain non-ASCII characters.
fixes https://github.com/firezone/firezone/issues/5467
---------
Signed-off-by: Jamil <jamilbk@users.noreply.github.com>
Fixes#5500
Unfortunately showing the menubar menu _only_ on re-launch is
non-trivial due to the way "re-launches" are processed in macOS.
We can handle them with the `applicationDidBecomeActive` override in
`AppDelegate`, but then this will be triggered whenever we sign in, open
Settings, or open About window because we activate the app then as well
in order to bring the Window to the foreground.
There's no good to way to determine who asked us to activate either.
Instead, we show the Welcome window (FirstTimeView on macOS), and in
there is a new button to show the app menu to use as a fallback for
users who need an alternative way to open the menu with a busy menubar.
<img width="1012" alt="Screenshot 2024-06-23 at 5 14 57 PM"
src="https://github.com/firezone/firezone/assets/167144/1a7dde08-1e83-4dc8-9516-e0390f29c941">
When the menu was clicked, the system would show it without activating
the app. This meant that other actions launched from the menu like `Sign
in` could sometimes happen without their respective window coming to the
foreground.
To fix it, we need more control over how the menu is displayed. So we
add a click handler and open the menu manually. Note that to do this, we
need to ensure `statusItem.menu = nil` otherwise the system will default
to showing the menu for us, and not firing our handler.
fixes#4818
