# ForkWithFlags.UI
[](https://github.com/tylerbarker/fork_with_flags_ui/actions?query=branch%3Amaster)
[](https://github.com/tylerbarker/fork_with_flags_ui/actions/workflows/quality.yml?query=branch%3Amaster)
[](https://hex.pm/packages/fork_with_flags_ui)
A Web dashboard for the [ForkWithFlags](https://github.com/tylerbarker/fork_with_flags) Elixir package. Forked from [FunWithFlags.UI](https://github.com/tompave/fun_with_flags_ui) in order to integrate with the original package fork.
## A note on the fork
This is a temporary fork of [tompave](https://github.com/tompave)'s excellent [fun_with_flags_ui](https://github.com/tompave/fun_with_flags_ui) library.
I in no way take credit for, or attribute myself to, this library. All that goes to [tompave](https://github.com/tompave), whom I'm happy to hand this work back over to if and whenever the time comes.
Thanks ✌️
## Switching from fun_with_flags_ui
See the [fork_with_flags README](https://github.com/tylerbarker/fork_with_flags#readme).
## How to run
`ForkWithFlags.UI` is just a plug and it can be run in a number of ways.
It's primarily meant to be embedded in a host Plug application, either Phoenix or another Plug app.
### Mounted in Phoenix
The router plug can be mounted inside the Phoenix router with [`Phoenix.Router.forward/4`](https://hexdocs.pm/phoenix/Phoenix.Router.html#forward/4).
```elixir
defmodule MyPhoenixAppWeb.Router do
use MyPhoenixAppWeb, :router
pipeline :mounted_apps do
plug :accepts, ["html"]
plug :put_secure_browser_headers
end
scope path: "/feature-flags" do
pipe_through :mounted_apps
forward "/", ForkWithFlags.UI.Router, namespace: "feature-flags"
end
end
```
Note: There is no need to add `:protect_from_forgery` to the `:mounted_apps` pipeline because this package already implements CSRF protection. In order to enable it, your host application must use the `Plug.Session` plug, which is usually configured in the endpoint module in Phoenix.
### Mounted in another Plug application
Since it's just a plug, it can also be mounted into any other Plug application using [`Plug.Router.forward/2`](https://hexdocs.pm/plug/Plug.Router.html#forward/2).
```elixir
defmodule Another.App do
use Plug.Router
forward "/feature-flags", to: ForkWithFlags.UI.Router, init_opts: [namespace: "feature-flags"]
end
```
Note: If your plug router uses `Plug.CSRFProtection`, `ForkWithFlags.UI.Router` should be added before your CSRF protection plug because it already implements its own CSRF protection. If you declare `ForkWithFlags.UI.Router` after, your CSRF plug will likely block GET requests for the JS assets of the dashboard.
### Standalone
Again, because it's just a plug, it can be run standalone in [different](https://hexdocs.pm/plug/readme.html#supervised-handlers) [ways](https://hexdocs.pm/plug/Plug.Adapters.Cowboy.html#http/3).
If you clone the repository, the library comes with two convenience functions to accomplish this:
```elixir
# Simple, let Cowboy sort out the supervision tree:
{:ok, pid} = ForkWithFlags.UI.run_standalone()
# Uses some explicit supervision configuration:
{:ok, pid} = ForkWithFlags.UI.run_supervised()
```
These functions come in handy for local development, and are _not_ necessary when embedding the Plug into a host application.
Please note that even though the `ForkWithFlags.UI` module implements the `Application` behavior and comes with a proper `start/2` callback, this is not enabled by design and, in fact, the Mixfile doesn't declare an entry module.
If you really need to run it standalone in a reliable manner, you are encouraged to write your own supervision setup.
### Security
For obvious reasons, you don't want to make this web control panel publicly accessible.
The library itself doesn't provide any auth functionality because, as a Plug, it is easier to wrap it into the authentication and authorization logic of the host application.
The easiest thing to do is to protect it with HTTP Basic Auth, provided by Plug itself.
For example, in Phoenix:
```diff
defmodule MyPhoenixAppWeb.Router do
use MyPhoenixAppWeb, :router
+ import Plug.BasicAuth
pipeline :mounted_apps do
plug :accepts, ["html"]
plug :put_secure_browser_headers
+ plug :basic_auth, username: "foo", password: "bar"
end
scope path: "/feature-flags" do
pipe_through :mounted_apps
forward "/", ForkWithFlags.UI.Router, namespace: "feature-flags"
end
end
```
## Caveats
While the base `fork_with_flags` library is quite relaxed in terms of valid flag names, group names and actor identifers, this web dashboard extension applies some more restrictive rules.
The reason is that all `fork_with_flags` cares about is that some flag and group names can be represented as an Elixir Atom, while actor IDs are just strings. Since you can use that API in your code, the library will only check that the parameters have the right type.
Things change on the web, however. Think about the binary `"Ook? Ook!"`. In code, it can be accepted as a valid flag name:
```elixir
{:ok, true} = ForkWithFlags.enable(:"Ook? Ook!", for_group: :"weird, huh?")
```
On the web, however, the question mark makes working with URLs a bit tricky: in `http://localhost:8080/flags/Ook?%20Ook!`, the flag name will be `Ook` and the rest will be a query string.
For this reason this library enforces some stricter rules when creating flags and groups. Blank values are not allowed, `?` neither, and flag names must match `/^w+$/`.
## Installation
The package can be installed by adding `fork_with_flags_ui` to your list of dependencies in `mix.exs`.
It requires [`fork_with_flags`](https://hex.pm/packages/fork_with_flags), see its [installation documentation](https://github.com/tylerbarker/fork_with_flags#installation) for more details.
```elixir
def deps do
[{:fork_with_flags_ui, "~> 0.8"}]
end
```
