Spaces:
Running
Running
| with open("gateway.py", "r") as f: | |
| code = f.read() | |
| # Instead of relying on `LLAMA_API_KEY` vs `API_KEY` internally, I will just make it so that if INFERENCE_AUTH_MODE is optional, and it's an anonymous request, it skips `llama_auth_headers()` but we already tried that and it failed. | |
| # BUT WAIT. | |
| # When the user provided `Authorization: Bearer sk-gemini`, the gateway DID NOT FORWARD IT. | |
| # It used `llama_auth_headers()`, which evaluated to `{}`, because `API_KEY` was empty (due to `unset API_KEY` in start.sh). | |
| # Ah! | |
| # If `API_KEY` was empty, `llama_auth_headers()` evaluated to `{}`. | |
| # BUT wait! `get_is_authenticated` printed `is_authenticated=True` when it matched `VALID_API_KEYS`. | |
| # How did it match `VALID_API_KEYS`? | |
| # In `gateway.py`, `VALID_API_KEYS` is evaluated at startup. | |
| # `API_KEY` is evaluated at startup. | |
| # If `start.sh` unsets `API_KEY`, it is unset for BOTH `gateway.py` AND `llama-swap`. | |
| # So `VALID_API_KEYS` would be empty. | |
| # If `VALID_API_KEYS` is empty, `is_valid` is False. | |
| # But `sk-gemini` WORKED! | |
| # Why did `sk-gemini` work if `API_KEY` is unset? | |
| # IT ONLY WORKED BECAUSE I REVERTED MY FIX IN PATCH 31! | |
| # Wait! In `patch_auth_test31.py` I HARDCODED `sk-gemini` into `llama_auth_headers()`: | |
| # `return {"Authorization": f"Bearer sk-gemini"}` | |
| # AND I changed `start.sh` to: | |
| # `API_KEY= /usr/local/bin/llama-swap` | |
| # So `llama-swap` HAS an empty `API_KEY`. | |
| # BUT if `llama-swap` has an empty `API_KEY`, why does sending `Authorization: Bearer sk-gemini` work?? | |
| # Wait, maybe `API_KEY=` doesn't actually unset it properly for `llama-server`? | |
| # In `llama-swap`, it parses the environment. If it sees `API_KEY`, it requires it. | |
| # BUT what if the environment in the Hugging Face Space has `LLAMA_API_KEY` set to `sk-gemini`? | |
| # Let's write a script to just look at `os.environ` in `gateway.py`! | |