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
This ensure that we run prettier across all supported filetypes to check
for any formatting / style inconsistencies. Previously, it was only run
for files in the website/ directory using a deprecated pre-commit
plugin.
The benefit to keeping this in our pre-commit config is that devs can
optionally run these checks locally with `pre-commit run --config
.github/pre-commit-config.yaml`.
---------
Signed-off-by: Jamil <jamilbk@users.noreply.github.com>
Co-authored-by: Thomas Eizinger <thomas@eizinger.io>
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
Why:
* When using the Portal UI, it can be difficult to find a given Policy
as only 10 are shown on the page at a time. It was also difficult to
determine which Resources a Group had access to and vice versa what
Groups were allowed to access a given Resource. This change allows
searching by either Resource or Group to filter what Policies are shown.
Closes: #5624
