Looks like it broke the staging WS connections. Getting a failure of
Liveview socket connection on `app.firez.one`:
```
insertId: 1o7nymzg12jh1k5
jsonPayload:
cos.googleapis.com/container_id: 89b4633e81432e43dfbaa3957324fd5ead3f2362737bac84648a8f839b6eb16c
cos.googleapis.com/container_name: klt-web-cpap
cos.googleapis.com/stream: stdout
message:
domain:
- elixir
erl_level: error
logging.googleapis.com/sourceLocation:
file: lib/phoenix/socket/transport.ex
function: Elixir.Phoenix.Socket.Transport.check_origin/5
line: 344
message: |+
Could not check origin for Phoenix.Socket transport.
Origin of the request: https://app.firez.one
This happens when you are attempting a socket connection to
a different host than the one configured in your config/
files. For example, in development the host is configured
to "localhost" but you may be trying to access it from
"127.0.0.1". To fix this issue, you may either:
1. update [url: [host: ...]] to your actual host in the
config file for your current environment (recommended)
2. pass the :check_origin option when configuring your
endpoint or when configuring the transport in your
UserSocket module, explicitly outlining which origins
are allowed:
check_origin: ["https://example.com",
"//another.com:888", "//other.com"]
severity: ERROR
time: '2023-08-26T21:24:36.002Z'
time: '2023-08-26T21:24:36.002628434Z'
logName: projects/firezone-staging/logs/cos_containers
receiveTimestamp: '2023-08-26T21:24:36.402398476Z'
resource:
labels:
instance_id: '8218473336234347240'
project_id: firezone-staging
zone: us-east1-d
type: gce_instance
timestamp: '2023-08-26T21:24:36.002628434Z'
```
The Sign Up page will allow users to create new organization accounts.
During sign-up, a randomly generated slug will be created for the
account and "magic link" will be set as the first identity provider to
allow the user to login to the newly created account.
---------
Co-authored-by: Jamil <jamilbk@users.noreply.github.com>
* Refactor sharedPreferences to only save the AccountId
* Update TeamId -> AccountId to match naming elsewhere
* Update JWT -> Token to avoid confusion; this token is **not** a valid
JWT and should be treated as an opaque token
* Update FFI `connect` to accept an optional file descriptor (int32) as
a first argument. This seemed to be the most straightforward way to pass
it to the tunnel stack. Retrieving it via callback is another option,
but retrieving return vars with the `jni` was more complex. We could
have used a similar approach that we did in the Apple client
(enumerating all fd's in the `new()` function until we found ours) but
this approach is [explicitly
documented/recommended](https://developer.android.com/reference/android/net/VpnService.Builder#establish())
by the Android docs so I figured it's not likely to break.
Additionally, there was a thread safety bug in the recent JNI callback
implementation that consistently crashed the VM with `JNI DETECTED ERROR
IN APPLICATION: use of invalid jobject...`. The fix was to use
`GlobalRef` which has the explicit purpose of outliving the `JNIEnv`
lifetime so that no `static` lifetimes need to be used.
---------
Signed-off-by: Jamil <jamilbk@users.noreply.github.com>
Co-authored-by: Pratik Velani <pratikvelani@gmail.com>
Co-authored-by: Gabi <gabrielalejandro7@gmail.com>
Fixes a small bug where `client_platform` wasn't being added to the
redirect_params in the magic link auth flow, so the token form input was
never shown.
Also adds a `hidden` type input that omits the `class=` attribute and
`div` wrapper.
Feel free to build off this or close and open a more thorough fix if
this is not the desired approach.
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>
Why:
* Policies are needed to make sure devices are allowed to connect to a
given resource.
---------
Signed-off-by: bmanifold <bmanifold@users.noreply.github.com>
Co-authored-by: Andrew Dryga <andrew@dryga.com>
Why:
* The previous Actor and Device Liveviews had used static views and data
as a starting point for fleshing out the web UI. This commit builds on
that and replaces (most) of the static data with data from the database,
as well as updating the static Liveview templates to use components
where possible.
Why:
* The previous Resource Liveviews had used static views and data as a
starting point for fleshing out the web UI. This commit builds on that
and replaces (most) of the static data with data from the database, as
well as updating the static Liveview templates to use components where
possible.
Note: These changes are only meant to involve the Resource views
(index/new/show/edit). More changes to other resources will follow(i.e.
Users, Devices, etc...)
Why:
* The `show` pages for all of the Firezone resources (i.e. Gateways,
Resources, Devices, etc...) were all very similar but were explicitly
defined in individual tables with their styling also explicitly defined
in each table. This commit creates a `vertical_table` component and a
`vertical_table_row` component to allow the styling to be defined once
and then consistently applied to each `show` page.
Why:
* The previous Gateway Liveviews had used static views and data as a
starting point for fleshing out the web UI. This commit builds on that
and replaces (most) of the static data with data from the database, as
well as updating the static Liveview templates to use components where
possible.
Note: These changes are only meant to involve the Gateway views
(index/show/edit). More changes to other resources will follow(i.e.
Resource, Users, Devices, etc...)
---------
Signed-off-by: bmanifold <bmanifold@users.noreply.github.com>
Co-authored-by: Andrew Dryga <andrew@dryga.com>
**Update CONTRIBUTING.md**
Why:
* The CONTRIBUTING.md doc seems to have fallen slightly out of date with
how Firezone now works. This commit updates the doc to provide a
quick start guide for getting all of the various Firezone components
up and running as quick as possible. The doc then links to the more
specific `Elixir` and `Rust` README.md files in the respective
directories to help developers who would like to contribute.
**Update docker-compose vault health check**
Why:
* The current Vault health check listed in the docker-compose file does
not seem to be working when using `localhost` in the `wget` command.
Updating the URL to use `127.0.0.1` seems to have fixed it.
---------
Signed-off-by: bmanifold <bmanifold@users.noreply.github.com>
Co-authored-by: Jamil <jamilbk@users.noreply.github.com>
Did some research on status page providers to manage incidents.
statuspage.io seems to be easy to use and cost-effective, fairly popular
and provides a good amount of flexibility to customize emails,
notifications, etc.
Super easy to set up and use but am not married to it if anyone feels
strongly about using another incident management service.
https://firezone.statuspage.io
## Demo:
<img width="235" alt="Screenshot 2023-06-27 at 8 07 29 AM"
src="https://github.com/firezone/firezone/assets/167144/8ad12b9b-7345-4a5d-bf43-c8af798d85f9">
@AndrewDryga ~~Was still hitting some redirect issues so I'll wait for
those to be resolved before continuing on building more views.~~ Edit:
After some sleep and coffee, I figured it out. Nice work on the sign in
form!
I went ahead and scoped existing dashboard links with `@account` and
fixed a dark mode issue -- you may want to cherry-pick those commits.
I'll add these to authenticated routes and integrate into what you have
so far.
As I was going through last night exploring your route approach I
thought of some edge cases; can discuss next week. I think the main one
that came to mind was that we probably want to differentiate between
login flows initiated directly in the browser (this is an admin logging
into the dashboard) vs login flows initiated from a client app (these
will terminate with a final redirect to respective `dest` whitelisted
URL). Maybe it makes sense to segregate these flows?
If a regular user tries login directly from the browser maybe we want to
show them something like "Please login from your Firezone application
instead" as they should only be able to initiate logins from a client
application. Or maybe there's simply no possibility to end up at the
final Android App Link or `firezone://` URI with a login initiated
directly from the browser?
Did some research when picking a package manager for the website and
settled on `pnpm` for the following reasons:
- CLI-compatible with `npm`
- Typically faster than even `yarn` especially on Apple silicon
- Security: Pnpm uses a different dependency resolution algorithm and
different folder structure of node_modules that prevents illegal access
to packages by other packages.
I think I caught all the places, but I may be missing something, so if
this isn't a good idea we can revert back.
This PR also cleans up the actions workflows to remove dead code.
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>
