The playground does not respect the service port

[gmartin-flexe]

When using the docker image for openfga in a docker compose setup, I tried setting the host port of the service to 8082 to avoid a collision. API calls I made worked fine, and the playground UI also loaded. However, the playground UI's requests to the server are still using 8080, which caused it to fail to load or create a store.

1. Run docker run -p 8082:8080 -p 8081:8081 -p 3000:3000 openfga/openfga run (or use 8082:8082 if you want)
2. Navigate to http://localhost:3000 in a browser
3. Click 'New Store' button.
4. Enter a name
5. Click Create

Expected: a new store Actual: nothing visually; console shows a network request failed

OpenFGA version or commit

1.3.1

Store data

N/A

Other data

• How are you running OpenFGA: Docker
• What datastore are you using?: In memory
• Are you running OpenFGA with any configuration overrides or with any of the flags mentioned in ./openfga run --help?: just overriding host port
• Do you have any logs or traces that could help us debug the problem? Not really; this is trivial to reproduce.

[miparnisari]

Hi @gmartin-flexe, the playground uses the --http-addr flag to figure out where to send the requests.

So you can do this: docker run -p 8082:SOME-PORT -p 8081:8081 -p 3000:3000 openfga/openfga run --http-addr 0.0.0.0:SOME-PORT

So for example: docker run -p 8082:8082 -p 8081:8081 -p 3000:3000 openfga/openfga run --http-addr 0.0.0.0:8082

[UncleFirefox]

Have the exact same issue... From docker-compose I'm trying to do command: ['run', '--http-addr', '0.0.0.0:8082'] but it does not seem to work, am I doing something wrong?

[rhamzeh]

@UncleFirefox what's the error you are getting?

Make sure in the Playground to create a store before saving the model.

[UncleFirefox]

@rhamzeh the playground UI still goes to port 8080 I can't change the UI to point somewhere else, couldn't we have an environment variable to tell the playground ui where openFga is?

[gabrielbussolo]

couldn't we have an environment variable to tell the playground ui where openFga is?

@UncleFirefox mostly of the flags carry a ENV associated with it on the case of the server port for the flag --http-addr you can use the env variable OPENFGA_HTTP_ADDR

example: you can use the compose provided by the docs, and edit the port as @miparnisari suggested but using the env variable.

version: '3.8'

networks:
  openfga:

services:
  postgres:
    image: postgres:14
    container_name: postgres
    networks:
      - openfga
    ports:
      - "5432:5432"
    environment:
      - POSTGRES_USER=postgres
      - POSTGRES_PASSWORD=password
    healthcheck:
      test: [ "CMD-SHELL", "pg_isready -U postgres" ]
      interval: 5s
      timeout: 5s
      retries: 5

  migrate:
    depends_on:
      postgres:
        condition: service_healthy
    image: openfga/openfga:latest
    container_name: migrate
    command: migrate
    environment:
      - OPENFGA_DATASTORE_ENGINE=postgres
      - OPENFGA_DATASTORE_URI=postgres://postgres:password@postgres:5432/postgres?sslmode=disable
    networks:
      - openfga

  openfga:
    depends_on:
      migrate:
        condition: service_completed_successfully
    image: openfga/openfga:latest
    container_name: openfga
    environment:
      - OPENFGA_DATASTORE_ENGINE=postgres
      - OPENFGA_DATASTORE_URI=postgres://postgres:password@postgres:5432/postgres?sslmode=disable
      - OPENFGA_LOG_FORMAT=json
+     - OPENFGA_HTTP_ADDR=0.0.0.0:8090
    command: run
    networks:
      - openfga
    ports:
      # Needed for the http server
-      - "8080:8080"
+      - "8090:8090"
      # Needed for the grpc server (if used)
      - "8081:8081"
      # Needed for the playground (Do not enable in prod!)
      - "3000:3000"

[github-actions[bot]]

It appears this issue has been stale for at least 14 days 🗓️. If no action is taken the maintainer team may consider closing the issue. Please reach out if you need feedback or follow up actions from the maintainer team.

[UncleFirefox]

Hi, yeah, that could work locally, what I'm interested in is the following:

I'm facing a challenge with OpenFGA in our cloud infrastructure. The current configuration setup, using OPENFGA_HTTP_ADDR for both binding and advertising the address in the UI, is causing issues in our environment.

In our cloud setup, the pod lacks a public address and isn't aware of its domain name. This creates difficulties when binding to an address that should be advertised to the UI.

I'm seeking your insights on proposing two separate fields: OPENFGA_SERVER_ADDR for binding and OPENFGA_UI_ADDR for UI advertising.

What do you think? That could help being able to deploy inside our infra. As our production openfga setup and tuples get more and more complicated, the help of playground would be really appreciated.

Thank you!

Regards,

Albert

[github-actions[bot]]

It appears this issue has been stale for at least 14 days 🗓️. If no action is taken the maintainer team may consider closing the issue. Please reach out if you need feedback or follow up actions from the maintainer team.

[miparnisari]

@UncleFirefox if I understood correctly, you want the ability to keep the OpenFGA server private but expose the playground to the world, which is impossible because playground is currently configured to listen on localhost. Is that correct? If so, do you mind opening a new issue?

[rhamzeh]

@UncleFirefox we strongly recommend against exposing the playground to a network OpenFGA is not exposed to, as the Playground has no security mechanisms built-in.

At the moment, Playground will only work if it is hosted at http://localhost:3000, any other URL will fail. The Playground is not open source (see: https://openfga.dev/docs/getting-started/setup-openfga/playground), it's just an iframe around Okta's FGA Playground. We do have plans in the future to rebuild the Playground as a fully OSS app that you can host yourself, but that's very low in our list of priorities.

What I would recommend is using our VS Code extension + the CLI to manage your model, they offer the same syntax highlighting and validation as the Playground, allow for better access controls and much better testing (see: https://github.com/openfga/cli/?tab=readme-ov-file#run-tests-on-an-authorization-model) and are where most of our tooling work is focused in the near future.

[UncleFirefox]

Hey @rhamzeh thanks for the heads up! The only doubt I got about the vscode + cli approach is to be able to connect to openfga when it's actually deployed behind the infrastructure (k8s cluster, etc).

We're looking for ways to be more productive in staging environments when we have problems like 403s we don't expect in our APIs so the only solution for now is to try dump the entire store into a backup through cli and then restore it locally? Playground seemed like a good idea into our staging environments because it exposes a frontend you can quickly reason about should a problem occur.

Currently we ended up having to expose custom endpoints protected by special tuples which allow us to read/write from deployed openfga stores in those environments... Is there any better alternative we're missing out?