workspace get_by_domain isn't compatible with docker-compose networking

[dearlordylord]

Describe the bug

fief/fief/repositories/workspace.py

Line 24 in 6df2773

async def get_by_domain(self, domain: str) -> Workspace | None:

admin api call cannot identify any domain except the given with ROOT_DOMAIN/FIEF_DOMAIN on setup (i.e. localhost is recognized, but inner docker-compose domains are not)

To Reproduce

docker-compose.yml: (note: env secrets are generated for testing and are not my production secrets)

version: '2'

services:
  fief: # generate from the above ^
    image: ghcr.io/fief-dev/fief:latest
    ports:
      - '8000:8000'
    environment:
      - SECRET=XXX
      - FIEF_CLIENT_ID=XXX
      - FIEF_CLIENT_SECRET=XXX
      - ENCRYPTION_KEY=XXX=
      - FIEF_MAIN_ADMIN_API_KEY=ACAB
      - PORT=8000
      - ROOT_DOMAIN=localhost:8000
      - FIEF_DOMAIN=localhost:8000
      - [email protected]
      - [email protected]
      - CSRF_COOKIE_SECURE=False
      - SESSION_DATA_COOKIE_SECURE=False
      - USER_LOCALE_COOKIE_SECURE=False
      - LOGIN_HINT_COOKIE_SECURE=False
      - LOGIN_SESSION_COOKIE_SECURE=False
      - REGISTRATION_SESSION_COOKIE_SECURE=False
      - SESSION_COOKIE_SECURE=False
      - FIEF_ADMIN_SESSION_COOKIE_SECURE=False

  fiefsetup:
    image: curlimages/curl:latest
    depends_on:
      - fief
    restart: "no"
    environment:
      FIEF_API_KEY: "ACAB"
    entrypoint:
      - "/bin/sh"
      - "-c"
      - |
        curl \
        -X GET \
        -H "Authorization: Bearer ${FIEF_API_KEY}" \
        http://fief:8000/admin/api/users/ && echo "\n"

-> run -> get CANT_DETERMINE_VALID_WORKSPACE error

however, run the same curl command from the host machine with http://localhost:8000/admin/api/users/ and it finds the workspace

Expected behavior

I expect it to understand default workspace with whatever root domain it's accessed from

Configuration

self-hosted, as per https://docs.fief.dev/self-hosting/quickstart/ but FIEF_MAIN_ADMIN_API_KEY=ACAB added

Additional context

For context, the main point of why I'm doing this call from inside docker-compose is that I'd like to setup some default schema, namely a field for users, that I'd like to do through admin API automatically on docker setup

[fief-bailiff[bot]]

Hail, @Firfi 👋

I've noticed you shared secret values: SECRET, FIEF_CLIENT_ID, FIEF_CLIENT_SECRET, ENCRYPTION_KEY. Those are highly sensitive and you should keep them secret.

For your security, I've taken the liberty to replace them with dummy values.

[fief-bailiff[bot]]

Hail, @Firfi 👋 Welcome to Fief's kingdom!

Our team will get back to you very soon to help.

In the meantime, take a minute to star our repository ⭐️

Farewell!

[dearlordylord]

Hail, @Firfi 👋

I've noticed you shared secret values: SECRET, FIEF_CLIENT_ID, FIEF_CLIENT_SECRET, ENCRYPTION_KEY. Those are highly sensitive and you should keep them secret.

For your security, I've taken the liberty to replace them with dummy values.

they were really all right to share and I was aware, but all right.

[dearlordylord]

network_mode: host solves the issue but isn't desirable

[frankie567]

they were really all right to share and I was aware, but all right.

It's a bot, so not very clever ya know 🙃

---

Regarding your issue, it's expected that Fief is not able to recognize your workspace with the internal hostname fief:8000: it's only able to recognize the one that sets in its configuration.

Now, the good thing is that it relies on the Host header to determine the workspace. So, with curl, it's quite easy to manually set it:

        curl \
        -X GET \
        -H "Authorization: Bearer ${FIEF_API_KEY}" \
        -H "Host: localhost:8000" \
        http://fief:8000/admin/api/users/ && echo "\n"

[dearlordylord]

This is indeed much better than network: host. Thank you @frankie567 !

[ocontant]

First of all, thank you for the great work on this project. An open source SaaS user management platform is very welcome!

I wanted to contribute a feedback on the issue Firfi faced. I just spent a few hours myself, figuring why I had this error message.
I spent more time under the hood, and I should have search the Github project earlier.

The root cause on my misadventure would point to:
I didn't notice information in the documentation (Quickstart, Production Deployment) that state a requirement to use the fief domain value to connect to the service instance.

The Quickstart make a reference to localhost. I fell in the trap to fall in assumption. Especially that most of the time when working with local instances, we usually refer to localhost, which creates a cognitive handicap to figure out the dependency cause.

My first instinct was to think that some service didn't start properly, causing unknown issues leading to this error. I suspected a database connection issue and went to test if fief-server had connectivity with postgres engine. From there, I went through a rabbit hole. The fief-server docker image is strip bare and doesn't include the basic like ps, lsof, netstat, and of course psql. Which is great for security in production, but not so much to troubleshoot. Perhaps, it could be nice to have a non-production image build, that include tools to troubleshoot issues. We could have a simple image name tag between DEV/PROD referenced by a variable in the CI/CD pipelines to differentiate which image to deploy in different environments.

Documentation improvement opportunity
In the docker-compose documentation, there's no example of how to connect to the fief-server instance and one would assume it is the same way as with Quickstart documentation.

Error messages would benefits from being clearer for end-user
I didn't find the error message to be helpful. Google search had no reference for it. (Project is still young and indexing probably not mature).

The enduser should receive a clearer message that explain why it is unable to complete the request. In this case, if a user access the platform from the wrong domain, the message should state it clearly and point to the value of the variable FIEF_DOMAIN and ideally include a URL to documentation.

The generic error was confusing for me, didn't point me in the right direction (workspace doesn't exist, must be the database).

Thank you again for your contribution and dedication to help us all !

[frankie567]

I recognize that those host/domain detection issues are quite hard to understand and debug.

That's mostly why I'm currently restructuring the whole code so one server = one workspace. This way, it won't care anymore about the domain you're calling it with. Hopefully, getting started will be much more easier -> https://github.com/orgs/fief-dev/discussions/322

[ocontant]

Bonjour Frankie,

I finally moved to another open source project Authentik, as the code and capability are more mature.

I know building and maintaining an Open Source project is a lot of work and dedication. Competing in the same space without differentiation might be counter productive.

It would be interesting to check Authentik, and see if you can find a specialized niche where your project would fit nicely. I would think a solution with a minimal footprint, or focused on abstracting oauth integration by providing generic libraries that automate the process.

From my experience with dev teams, most aren't aware of OWASP best practices and struggle to implement secured authentication. And most of the time, they end up implementing authentication at the basic without advanced or deep Cyber Security expertise and notions. I saw a few libraries to integrate oauth authentication, but they are all too low level and doesn't bring the level of abstraction to easily integrate a secure oauth implementation.

A good abstraction could be about choosing which RFC pattern to implement and simply calling functions that does all the magic behind the scene correctly and securely, without having to handle too much the logic of the pattern. Managing sessions should be passing cache server connection object and database connection object, along if you are using cookie or header for JWT.

A minimalist oauth server, along a set of universal library to implement oauth RFC standard could be a sweet thing to have.
Implementing oauth should be ideally a 5 liners code, instead of hundred lines.

I will still keep an eye on your project though :)