Spaces:
Running
Running
| import re | |
| with open("gateway.py", "r") as f: | |
| code = f.read() | |
| # Restore the correct auth header, if we look at `llama_auth_headers` we want to explicitly make sure it forwards the Authorization header. | |
| # Wait, if we use API_KEY from os.environ, and if it's set in the Hugging Face space secrets, it will be the one defined globally. | |
| # But `gateway.py` isn't using the incoming user's key? | |
| # OH! | |
| # The request comes in from the *user*. The user sends `Authorization: Bearer <their_key>`. | |
| # Does `gateway.py` forward *their* key? | |
| # No! `gateway.py` generates `llama_auth_headers()` which uses `LLAMA_API_KEY` (or `API_KEY`) from the *server environment*! | |
| # ```python | |
| # def llama_auth_headers() -> dict[str, str]: | |
| # key = LLAMA_API_KEY or API_KEY | |
| # return {"Authorization": f"Bearer {key}"} if key else {} | |
| # ``` | |
| # It's *supposed* to use the server's API key to communicate with `llama-swap`, which validates it against the *server's* environment variable `API_KEY`. | |
| # This is correct. The gateway proxies the request to `llama-swap` on localhost:8080. | |
| # So `gateway.py` gets the request, authenticates the user using its own logic (matching the headers against `VALID_API_KEYS`). | |
| # Then it makes a request to `localhost:8080/v1/chat/completions`. | |
| # `llama-swap` is running on port 8080. It reads the `API_KEY` environment variable directly. | |
| # BUT wait! We did `env -u API_KEY /usr/local/bin/llama-swap ...` in `start.sh` so `llama-swap` doesn't know about `API_KEY`! | |
| # Let me look at the last commit I did. I removed `env -u API_KEY`. So `llama-swap` *does* know about `API_KEY`. | |
| # AND I updated `llama_auth_headers()` to use `API_KEY`. | |
| # Wait, if `llama-swap` knows about `API_KEY`, it expects `Authorization: Bearer <API_KEY>`. | |
| # `llama_auth_headers()` sends `{"Authorization": f"Bearer {API_KEY}"}`. | |
| # BUT `llama-swap` is STILL saying `unauthorized: Invalid API Key`! | |