- [x] Introduce api_client actor type and code to create and
authenticate using it's token
- [x] Unify Tokens usage for Relays and Gateways
- [x] Unify Tokens usage for magic links
Closes#2367
Ref #2696
- [x] make sure that session cookie for client is stored separately from
session cookie for the portal (will close#2647 and #2032)
- [x] #2622
- [ ] #2501
- [ ] show identity tokens and allow rotating/deleting them (#2138)
- [ ] #2042
- [ ] use Tokens context for Relays and Gateways to remove duplication
- [x] #2823
- [ ] Expire LiveView sockets when subject is expired
- [ ] Service Accounts UI is ambiguous now because of token identity and
actual token shown
- [ ] Limit subject permissions based on token type
Closes#2924. Now we extend the lifetime for client tokens, but not for
browsers.
* Sort clients list by `last_seen_at` desc. This handles the `online?`
case too. Before, they were sorted by `asc` which made it hard to see
which recent clients were connected
* Scope the client log filename by account slug and actor name so it's
easier to find.
This PR changes the protocol and adds support for DNS subdomains, now
when a DNS resource is added all its subdomains are automatically
tunneled too. Later we will add support for `*.domain` or `?.domain` but
currently there is an Apple split tunnel implementation limitation which
is too labor-intensive to fix right away.
Fixes#2661
Co-authored-by: Andrew Dryga <andrew@dryga.com>
Why:
* As sites are created, the default behavior right now is to route
traffic through whichever path is easiest/fastest. This commit adds the
ability to allow the admin to choose a routing policy for a given site.
The idea is to allow users to explicitly name them so they are easier to
identify in the UI.
@thomaseizinger we will need to add an optional `FIREZONE_NAME`
environment variable for the relays and send it along with other
attributes when you connect to a WebSocket.
Why:
* After further discussion around the Client DNS settings, it was
decided that keeping both `type` and `address` would be easier to help
with validation and parsing. At the moment, only IP DNS servers are
accepted, but placeholders for `DNS over TLS` and `DNS over HTTPS` have
been created.
Fixes#2213
This will allow us to fetch the actual Firezone version that's in use
from within the language runtimes themselves without resorting to an
external mechanism to do so. This is useful in connlib for example when
selecting the Portal API to use with `X-Firezone-API-Version`, and
useful in log printing.
Since platforms enforce semantic version, I propose the convention:
`1.20231001.34` where MAJOR is `1` for Firezone 1.0, MINOR is our API
version, and PATCH is the release of that API version that is published
on the repo.
Given this system, publishing a release would consist of:
1. Edit `Makefile` to set the patch and minor versions appropriately
depending on whether there are breaking portal API changes.
2. `make version`
3. `git add .; git commit; git push` -- this opens a PR with the new
version numbers. In this PR we can discuss whether to stop-ship or go.
4. PR merged, release is drafted and deployed to staging with the new
tag and version numbers
5. build artifacts are uploaded to drafted release, everything is tagged
and versioned appropriately without having to introduce another commit
6. If all looks good, publish release
Why:
* The previous Account DNS Settings page was only a static page. This
commit enables the form on the page to actually save and update the DNS
settings for a given account.
Renaming it back to clients to reflect service accounts and headless
clients use cases in the terminology. Such a rename will be very painful
on live data so better if we do it early on.
---------
Co-authored-by: Jamil Bou Kheir <jamilbk@users.noreply.github.com>
This is a result of our discussion with @conectado, this PR will add a
new message type which will allow reusing existing connections to the
gateway to access a new resource. We will also change the LB strategy to
be aware of the current device connection so that we will not pick a
different one if we have a connected gateway that can serve a new
resource.
---------
Co-authored-by: conectado <gabrielalejandro7@gmail.com>
Looks like for some reason the id/1 callback doesn't subscribe the channel process any more (only the socket itself), so we are doing that explicitly now.
TODO:
- [x] Cluster formation for all API and web nodes
- [x] Injest Docker logs to Stackdriver
- [x] Fix assets building for prod
To finish later:
- [ ] Structured logging:
https://issuetracker.google.com/issues/285950891
- [ ] Better networking policy (eg. use public postmark ranges and deny
all unwanted egress)
- [ ] OpenTelemetry collector for Google Stackdriver
- [ ] LoggerJSON.Plug integration
---------
Signed-off-by: Andrew Dryga <andrew@dryga.com>
Co-authored-by: Jamil <jamilbk@users.noreply.github.com>
