Simplified project to be more a PoC

.github/workflows/docker.yml

@@ -28,7 +28,7 @@ jobs:
         name: Build and push Docker image
         uses: docker/build-push-action@v2
         with:
-          context: ./proxy
+          context: ./
           push: true
           tags: ${{ steps.meta.outputs.tags }}
           labels: ${{ steps.meta.outputs.labels }}

.gitignore

@@ -1,7 +1 @@
-/db
 __pycache__
-terraform.tfstate*
-.terraform*
-
-
-dist/

Dockerfile

@@ -0,0 +1,13 @@
+FROM golang:1.22-bullseye as build
+WORKDIR /build
+COPY go.mod go.sum /build/
+RUN go mod download
+COPY cmd cmd
+COPY internal internal
+RUN go build -o fitm ./cmd/fitm/main.go
+
+FROM mitmproxy/mitmproxy:10.2.2
+WORKDIR /app
+COPY fitm.py .
+COPY --from=build /build/fitm .
+CMD ["./fitm", "run"]

README.md

@@ -18,73 +18,22 @@ I wanted to create a way to share access to services in a controlled manner, wit
 
 - HTTP proxy
 - HTTPS proxy (using self-signed CA Certificate)
-- Multiple cookie buckets
-- Token based user authentication
-- User permissions for specific buckets
-- Admin API to manage buckets and users
+- Persists cookies in disk.
 
-## Quick start
+## Quick start using Docker Compose
 
-First, get the binary from [the lastest release](https://github.com/acroca/fitm/releases/latest).
-
-Here there are some initial commands to get the service running and usable:
-
-```sh
-./fitm init # Prepares the ~/.config/fitm
-./fitm up # Runs the proxy
-```
-
-Once fitm is running, we need to install and trust the generated certificate from $HOME/.config/fitm/dotmitmproxy/mitmproxy-ca-cert.pem
-
-After installing the certificate, prepare fitm to be usable:
-
-```sh
-# Currently fitm ships with vault using this root token. We'll use it for the following commands from the CLI
-export VAULT_TOKEN=myroot
-
-# Creates a bucket in fitm
-./fitm buckets create --id mybucket
-
-# Creates a user in fitm
-./fitm users create --id myuser
-
-# Grants access, so the user has access to the bucket
-./fitm acl grant --user-id myuser --bucket-id mybucket
-
-# Creates a token for that user and bucket.
-./fitm users token --id myuser --bucket-ids mybucket
-```
-
-At this point fitm is ready to use. Configure the HTTP Proxy in your browser to `localhost:8080` and use `mybucket` as username, and the token as a password to authenticate yourself.
-
-Fitm ships with an embedded browser (powered by [Playwright](https://github.com/microsoft/playwright)). To use it:
-```sh
-./fitm browser install
-
-./fitm browser open --bucket-id mybucket --token mytoken
-```
+TODO
 
 ## How does this work
 
 The main component of FITM is the HTTP/HTTPS proxy, and that's done using [mitmproxy](https://mitmproxy.org/). This is an awesome tool that creates a man-in-the-middle proxy (essentially the HTTP/HTTPS proxy itself) with a really good plugin system, which we use to implement the cookies logic.
 
 The mitmproxy plugin takes ownership of cookies, storing them and re-injecting on the way back to the server, so the browser doesn't see them.
 
-The cookie storage is organized in buckets. FITM exposes an admin API to create buckets, and when the user authenticates with the proxy they specify which bucket to use. For the storage it uses a key-value system in [vault](https://www.vaultproject.io/).
-
-Users have to authenticate with the proxy in order to use it, and for that we use tokens. Tokens are provided on the admin API when managing users.
-
-Permissions at the moment are specific to users on buckets and it's impossible for a user to access a bucket without the right permission. This is implemented using vault policies.
-
 ## HTTPS support
 
 FITM uses [mitmproxy](https://mitmproxy.org/) under the hood. In order for mitmproxy to tunnel HTTPS requests,the user
 has to install the CA Certificate generated by mitmproxy. When using the provided docker compose file, the generated
 certificate can be found here: `$HOME/.config/fitm/dotmitmproxy/mitmproxy-ca-cert.pem`
 
 More info about how certificates work in mitmproxy [here](https://docs.mitmproxy.org/stable/concepts-certificates/)
-
-## Future ideas
-
-1. It'd be good to have different roles for each bucket, and with certain constraints. For example, and admin on a bucket would be able to navigate freely to any website, but a `user` of the bucket might not have access to change the password on certain websites. This could be part of the bucket configuration where the admin adds restrictions for certain roles.
-2. User authentication should be improved. At the moment it uses tokens that are sent to the API when signing up a new user. This is too centralized. We could use any other authentication mechanism, but keeping in mind that proxyauth only allows username-password authentication. Maybe it's worth exploring other client-side authentication mechanisms for http proxies.