Updates the Resource's pagination cursor such that the default cursor
(with no HTTP params applied) uses `{:resources, :asc, :name}` as the
default, which correctly updates all Resources live tables to sort by
`name`.
The reason this is updated at the Query layer is because I wanted to
achieve this without populating URL params by default, and still
allowing the sort icon to properly reflect the default sort order upon
page load, which it does.
My initial attempt went down the path of updating `assign_live_table/3`
to take a `default_order_by` option. That didn't work because upon page
load we `handle_params` which resets the ordering immediately based on
the URL params.
Rather than update the UI code to track even more state in order to use
`default_order_by` when the `order_by` param is not specified, I opted
to updated the Query module instead which the UI uses.
Fixes#7842
Why:
* An IdP sync can fail for different reasons and because of this we
previously put a threshold on when to send the first 'IdP sync failed'
email, which was set at 10 failed sync attempts. One thing that was
accidentally overlooked was that on one specific failure type (i.e. 401
- Unauthorized) the Firezone sync was automatically disabled and not
tried from that point forward. Unfortunately, that meant an email did
not get sent out because the threshold was not met. This PR resolves
that by making sure the 401 error will send out an email immediately,
while keeping the 10 failed sync threshold for all other errors.
Closes: #7725
Why:
* Currently, when using the API, a user has no way of easily identifying
what identities they are pulling back as the response only includes the
`provider_identifier` which for most of our AuthProviders is an ID for
the IdP and not an email address. Along with that, when adding users to
an OIDC provider within Firezone, there is no check for whether or not
an identity has already been added with a given email address. By
creating a separate email column on the `auth_identities` table, it will
be very straight forward to know whether an email address exists for a
given identity, return it in an API response and allow the admin of a
Firezone account to track users (Identities) by email rather than IdP
identifier.
Fixes#7392
Why:
* The API endpoint for updating Resources was using
`Resources.fetch_resource_by_id_or_persistent_id`, however that function
was fetching all Resources, which included deleted Resources. In order
to prevent an API user from attempting to update a Resource that is
deleted, a new function was added to fetch active Resources only.
Fixes: #7492
Hi @firezone/engineering , this is the following of
https://github.com/firezone/firezone/pull/6649
I forgot that people can be member of multiple OUs, this PR aims to add
support for this.
Imagine I have this OU architecture in my google workspace:
```mermaid
flowchart TD
A[Employees] --> B[Engineering]
A --> C[HR]
B --> D[Devs]
B --> E[Ops]
D --> F{me}
```
Currently in Firezone, I will only be a member of the Firezone Group
`OU: Devs`.
With this PR: I will be a member of `OU: Devs`, `OU: Engineering` and
`OU: Employees`
Co-authored-by: Antoine <antoinelabarussias@gmail.com>
Why:
* Recently we had an issue where a customer's payment info was
incorrectly entered, which caused the payment to not go through. When
something like this happens Stripe will send an update event with a
pending_update section (which we do not use currently). When the
customer fixes the payment info, and payment goes through we get another
update event with the correct subscription info, however, the previous
update (with the pending section) then gets expired and a
`pending_update_expired` event is sent to us. We had been inadvertantly
catching the event and updating the specified account with the info in
the event (which happened to be the previous state of the subscription)
Fixes: #7352
Why:
* Two of the email templates using an `<a>` tag were not properly
interpolating a view variable. This happened when the templates were
moved from the `web` app using `.heex` files to the `domain` app using
`.eex` files.
Fixes#7294
Why:
* The Firezone website is hosting the component versions at the moment
and due to how Vercel works, occassionally a request will
timeout when being made to the /api/versions endpoint. This had been
throwing an error in the elixir logs and triggering an alert, but
because there is always a default set of component version values in
the elixir app there isn't really a need for an error/alert. With
that in mind the log level will be set to `warning` rather than
`error`.
Closes#7233
In order for the firezone terraform provider to work properly, the
Resources and Policies need to be able to be referenced by their
`persistent_id`, specifically in the portal API.
This PR implements the new idempotent control protocol for the gateway.
We retain backwards-compatibility with old clients to allow admins to
perform a disruption-free update to the latest version.
With this new control protocol, we are moving the responsibility of
exchanging the proxy IPs we assigned to DNS resources to a p2p protocol
between client and gateway. As a result, wildcard DNS resources only get
authorized on the first access. Accessing a new domain within the same
resource will thus no longer require a roundtrip to the portal.
Overall, users will see a greatly decreased connection setup latency. On
top of that, the new protocol will allow us to more easily implement
packet buffering which will be another UX boost for Firezone.
TODOs:
- [x] Switch to sending messages instead of replies
- [ ] Do not hide pre-filtered resources and render them with an error
instead (in case we will want to expose that on a client later)
- [x] Figure out how to generate PSK so that it stays across WS
connections
Why:
* Without some type of notification, users do not realize that new
Gateway versions have been released and thus do not seem to be upgrading
their deployed Gateways.
Why:
* Instead of sending a notification to users when an identity provider
in their account fails to sync 1 time, we've now decided to wait until
the sync failures have reached 10 times to account for various anomalies
that might occur with any given identity providers API.
Why:
* Our current Okta sync job has no throttle, which has caused an issue
with customers that have other applications hitting their Okta API by
going over their API rate limits. By throttling the requests per second
and by lowering the frequency of how often the job runs we should
hopefully aleviate any Okta API rate limiting issues. This will come at
the expense of syncs taking longer and not happening as often, however,
this tradeoff seems worthwhile to ensure Firezone isn't hindering a
customers use of their Okta API.
Closes: #6748
---------
Signed-off-by: Brian Manifold <bmanifold@users.noreply.github.com>
Co-authored-by: Jamil <jamilbk@users.noreply.github.com>
Now you can "edit" any fields on the policy, when one of fields that
govern the access is changed (resource, actor group or conditions) a new
policy will be created and an old one is deleted. This will be
broadcasted to the clients right away to minimize downtime. New policy
will have it's own flows to prevent confusion while auditing. To make
experience better for external systems we added `persistent_id` that
will be the same across all versions of a given policy.
Resources work in a similar fashion but when they are replaced we will
also replace all corresponding policies.
An additional nice effect of this approach is that we also got
configuration audit log for resources and policies.
Fixes#2504
This adds a feature that will email all admins in a Firezone Account
when sync errors occur with their Identity Provider.
In order to avoid spamming admins with sync error emails, the error
emails are only sent once every 24 hours. One exception to that is when
there is a successful sync the `sync_error_emailed_at` field is reset,
which means in theory if an identity provider was flip flopping between
successful and unsuccessful syncs the admins would be emailed more than
once in a 24 hours period.
### Sample Email Message
<img width="589" alt="idp-sync-error-message"
src="https://github.com/user-attachments/assets/d7128c7c-c10d-4d02-8283-059e2f1f5db5">
This PR reverts commit that moves out IPv6 address to a separate
subdomain (deploying that will cause a prod downtime) and simply removes
the check that causes redirect loops.
They will be sent in the API for connlib 1.3 and above.
I think in future we can make a whole menu section called "Internet
Security" which will be a specialized UI for the new resource type (and
now show it in Resources list) to improve the user experience around it.
Closes#5852
---------
Signed-off-by: Andrew Dryga <andrew@dryga.com>
Co-authored-by: Jamil <jamilbk@users.noreply.github.com>
Why:
* Currently, when searching on the Client index page in the portal, the
only field being searched is the Client name. This commit adds the
ability to search either the Client name or the Actor name.
Closes: #5738
