Access denied on API due to hardcoded authorization URL

[cpbinovo]

I can't submit jobs to the API via the frontend (version 1.6.3) when I run this locally.

It appears the openapi/specification.yml file currently has a hardcoded authorization URL and it seems deleting the entire authentication block from the file fixes that problem.

I believe the solution to this should be to make values configurable via environment variables.
I'm currently trying to figure out how to make this a configurable setting in order to run this internally, by utilizing jinja2 templating.

[langdal]

The auth server can be disabled by specifying AUTH_API_KEY=none instead of using an auth server.

Example of running a non-authenticating server using docker:

docker run --rm -it -p 9090:9090 --env AUTH_API_KEY=none --env CORS_ORIGIN=".*" process-optimizer-api

[cpbinovo]

Thanks for the fast reply!

The frontend still says that it's unauthorized when setting that env var. So It appears that's not the case anymore?

[langdal]

It should still work - I have done a test today using the master branch of api and frontend

API:

docker build -t process-optimizer-api --build-arg GITHUB_REF_NAME=$(git describe --always) .
docker run --rm -it -p 9090:9090 --env AUTH_API_KEY=none --env CORS_ORIGIN=".*" process-optimizer-api

Frontend:

npm ci
npm run bootstrap
npm run dev:app

How are you starting the frontend in your example?

[cpbinovo]

ah okay I see where I'm going wrong, I am using version 1.6.3 of the frontend and that one does not send "apikey=none" in the url parameters, but main does!

I made the assumption that frontend version 1.6.3 was the "correct" version as its the last version with a version number tagged and also tagged latest but that is incompatible with the latest version of the API.
Changing the tag on the frontend to main works, but I then assume I have to consider that version unstable or is it okay to use in production?

also thanks for looking into it, much appreciated!

[cpbinovo]

I've added a pull request to fix up the docker compose file #79

[langdal]

Great!

Regarding the versioning of the frontend, there currently is no tagged version of the frontend. This is a regression introduced when we refactored the repository and split up the frontend into library components and a sample app using those libraries. See BoostV/process-optimizer-frontend#323

For now you can track the tag @boostv/process-optimizer-frontend-ui and pull the frontend image based on the commit sha of that tag.