This PR lays the ground work for making all the liveview pages more
uniform in how they are laid out by creating and updating some of the
liveview components.
Why:
* The signup page was failing to allow signups due to a change in one of
the domain functions. This happened due to the UI not having tests for
the sign up page. The sign up page has been updated to use the new
domain function signature and has also had some tests added to hopefully
prevent regressions.
Co-authored-by: Jamil <jamilbk@users.noreply.github.com>
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.
Getting some weird behavior with AppLinks. They don't seem to work upon
first use and require a few tries to function correctly.
Edit: Found the issue: Android Studio doesn't like when the Manifest
contains variables for AppLinks. I added a note in the Manifest.
@conectado To test Applinks are working correctly, you can use the App
Link Assistant:
<img width="930" alt="Screenshot 2023-09-28 at 11 15 11 PM"
src="https://github.com/firezone/firezone/assets/167144/e4bd4674-d562-44ec-bdb8-3a5f97250b84">
Then from there you can click "Test App Links":
<img width="683" alt="Screenshot 2023-09-28 at 11 15 30 PM"
src="https://github.com/firezone/firezone/assets/167144/f3dc8e0d-f58a-4a4b-9855-62472096dc9e">
Thanks to @devsnaked for the fix. Opening this to get the changes merged
more quickly.
Supersedes #2072
---------
Signed-off-by: Maximilly Moreira Gonçalves <max.ocw@gmail.com>
Co-authored-by: Maximilly Moreira <max.ocw@gmail.com>
Adds `active_path` to determine whether or not to highlight a sidebar
item.
~~Leaving as draft for now to allow @devsnaked to contribute. Edit: Will
use this PR as the base for @devsnaked's upcoming changes~~
Edit: fixes#2065
Why:
* The current account settings page shows the user profile info and
billing information. The billing system is not currently implemented and
can be hidden for the time being. As for the user profile information,
it was decided that it would probably be better to send the user to the
'Actors' show page for the currently logged in user.
<img width="1148" alt="new-account-settings-page"
src="https://github.com/firezone/firezone/assets/2646332/6aaabad0-038e-4b4c-8cfb-e2d669b54b53">
Why:
* Previously the New/Edit forms for Resources were not able to actually
create or update Resources. This commit enables those forms to create
and update a Resource.
---------
Co-authored-by: Andrew Dryga <andrew@dryga.com>
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>
Why:
* The new and edit policy pages had previously only been pulling live
data from the DB, but had not been able to use the forms to create or
update policies. This commit allows the forms to function as intended.
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>
