-
Notifications
You must be signed in to change notification settings - Fork 422
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Kinto does not start when auth policy is not available #2866
Comments
Could you please share the stacktrace? I'd like to understand what code path leads to a call to authentication on startup! |
kinto_1 | Traceback (most recent call last): |
The reason why we fetch issuer information during init is because we expose its information (endpoints etc.) in the root URL response. A possible fix to that would consist in offering the possibility for plugins (like openid here) to register their metadata lazily. Instead of calling config.add_api_capability(
"openid",
description="OpenID connect support.",
url="http://kinto.readthedocs.io/en/stable/api/1.x/authentication.html",
providers=providers_infos,
) we could have: def get_infos(config):
# fetch issuer infos
return infos
config.add_lazy_api_capability("openid", get_infos) And in the root URL code, when the content of a capability is a function we just call it before serving the response. |
I create a docker-compose file with Keycloak as the Identity Provider and Keycloak. As Keycloak takes some time to start, Kinto does not start and exists with this message:
<class 'json.decoder.JSONDecodeError'>: Expecting value: line 1 column 1 (char 0)
Im pretty sure this is as the issuer does not provide a valid json file. In Previous versions of docker-compose it was possible to make the kinto container depended. But this is no longer recommended.
"There's been a move away from specifying container dependencies in compose. They're only valid at startup time and don't work when dependent containers are restarted at run time. Instead, each container should include mechanism to retry to reconnect to dependent services when the connection is dropped. Many libraries to connect to databases or REST API services have configurable built-in retries. I'd look into that. It is needed for production code anyway."
What is the best way to handle this ?
The text was updated successfully, but these errors were encountered: