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:
* The portal currently shows API clients in the Actors index list. Each
Actor in the list has a link to their own 'show' page. Prior to this
commit, selecting an API client from the list would result an error.
While API clients are technically an Actor, they aren't quite the same
as all other Actors because they are only used to configure the portal
for a given account. Because of this, they don't have the same
information to show as all other Actors. This commit sets the 'show' URL
for API clients to the 'settings' page to show the proper info for the
API client.
Fixes: #7370
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
- Added semi-transparent shadow to the button so that it's more visible
when text is overlapping it. Padding did not look well because it
required scrollbar to be moved inside the parent container and it looked
very ugly
- Replaced custom phx hook with a new native Tailwind component
Closes#5973
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:
* A handful of 'show' pages were throwing errors for entities created
using the API. The reason was due to the fact that the
`created_by_actor` was not being preloaded and when the details on the
show page were being rendered. This commit updates the various pages to
preload the `created_by_actor` to allow for both API created entities
and UI created entities.
- Updated revoke button colors and icons.
- Updated the 'Created By' to use a helper function to get an email
address rather than using the provider_identifier which may be a random
string depending on the type of provider the identity was created under.
- Added a link to the actor that created the API token
### Screenshot of updated view
<img width="1168" alt="Screenshot 2024-10-07 at 1 11 43 PM"
src="https://github.com/user-attachments/assets/80444815-f045-49db-b570-dc9dc58c33d2">
Closes#6269
Bumps [flowbite](https://github.com/themesberg/flowbite) from 2.5.1 to
2.5.2.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a
href="https://github.com/themesberg/flowbite/releases">flowbite's
releases</a>.</em></p>
<blockquote>
<h2>v2.5.2</h2>
<ul>
<li>release new <a
href="https://flowbite.com/docs/plugins/wysiwyg/">WYSIWYG text
editor</a> component</li>
</ul>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="5c8df35e2b"><code>5c8df35</code></a>
docs(readme): add wysiwyg to readme</li>
<li><a
href="26cb313102"><code>26cb313</code></a>
Merge pull request <a
href="https://redirect.github.com/themesberg/flowbite/issues/971">#971</a>
from themesberg/wysiwyg</li>
<li><a
href="933b112fef"><code>933b112</code></a>
chore(wysiwyg) update to <code>v2.5.2</code></li>
<li><a
href="7aa2a6b366"><code>7aa2a6b</code></a>
feat(wysiwyg): finish the component</li>
<li><a
href="e799dc286e"><code>e799dc2</code></a>
feat(wysiwyg): add toggle buttons</li>
<li><a
href="30f5133ec3"><code>30f5133</code></a>
feat(wysiwyg): add next and prev cell navigation butoons</li>
<li><a
href="6e4cb24cf8"><code>6e4cb24</code></a>
feat(wysiwyg): set styles for currently selected cells</li>
<li><a
href="3d3261d3af"><code>3d3261d</code></a>
feat(wysiwyg): delete table feature and organise buttons</li>
<li><a
href="8270c05898"><code>8270c05</code></a>
feat(wysiwyg): add column and row behaviour actions</li>
<li><a
href="145f5617fb"><code>145f561</code></a>
docs(wysiwyg): write js behaviour docs</li>
<li>Additional commits viewable in <a
href="https://github.com/themesberg/flowbite/compare/v2.5.1...v2.5.2">compare
view</a></li>
</ul>
</details>
<br />
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
Dependabot will resolve any conflicts with this PR as long as you don't
alter it yourself. You can also trigger a rebase manually by commenting
`@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after
your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge
and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating
it. You can achieve the same result by closing it manually
- `@dependabot show <dependency name> ignore conditions` will show all
of the ignore conditions of the specified dependency
- `@dependabot ignore this major version` will close this PR and stop
Dependabot creating any more for this major version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop
Dependabot creating any more for this minor version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop
Dependabot creating any more for this dependency (unless you reopen the
PR or upgrade to it yourself)
</details>
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
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">
