Raise a UserNotFound exception when the query on get_user() does not match any users

[stratosgear]

It seems that if the search of users based on a query string return no users, the code assumes that there will always be some results and it "chokes" when none are found.

[koufopoulosf]

Hi @stratosgear,

Is there any chance that you've tried fastapi-keycloak with the latest version of Keycloak (19.0.3 at the moment) ?

If so, have you been able to create a user successfully (without errors)? It seems that this library is no longer maintained...

@JonasScholl @yannicschroeer,

Would you consider updating the fastapi-keycloak library to sync with the latest version of keycloak?

That would be much appreciated! 🙏

[stratosgear]

Oh boy... I was never able to make anything newer than 16.1 ever work! Our setup is kind tricky, having the Keycloak server running as docker service in a docker swarm with everything behind a Traefik proxy.

And ever since the Keycloak people migrated to that Quarkus thingie we cannot upgrade, since the new docker images do not work without some serious reconfigurations. Looking forward for an opportunity to upgrade but what we have right now is working! :(

If you have any pointers for a stack setup like the above, I'll take it... :)

[koufopoulosf]

Hello @stratosgear,

Thank you very much for your reply.

Oh boy... I was never able to make anything newer than 16.1 ever work! Our setup is kind tricky, having the Keycloak server running as docker service in a docker swarm with everything behind a Traefik proxy.

May I ask what was the issue that prevented you from upgrading to newer versions? I mean, was it because of keycloak itself? Because I think the keycloak documentation is pretty straightforward.

Looking forward for an opportunity to upgrade but what we have right now is working! :(

The problem is, Keycloak is still facing various CVE issues, so I wouldn't want to risk it by not using the latest version of it.

If you have any pointers for a stack setup like the above, I'll take it... :)

I've made an installation using the latest version of keycloak (19.0.3) along with nginx (without docker) - it's not a serious setup as I'm still in the process of understanding how keycloak works - so I don't have much experience with it, yet. I'm not sure if you're interested in such setup, are you?

I really don't see any reason as to why new projects should be based on the old keycloak versions.

[stratosgear]

I cannot speak for the developer/owners here but this project was started on Dec 2021. Keycloak 16.1 was recent at that time. Versions > 17 were started in 2022.

I also do not know the general consensus about Keycloak versions >17 but I find it hard to upgrade so I am dissatisfied. Therefore I understand not everybody jumping on the latest version. We would the maintainers rush to support all of the latest major Keycloak releases ( 3 major semantic version releases this year alone (and the year is not over yet))

Apologies, but your criticism on why "new" projects being based on old keycloak versions is not warranted, in this case.

[koufopoulosf]

I cannot speak for the developer/owners here but this project was started on Dec 2021. Keycloak 16.1 was recent at that time. Versions > 17 were started in 2022.

I also do not know the general consensus about Keycloak versions >17 but I find it hard to upgrade so I am dissatisfied. Therefore I understand not everybody jumping on the latest version. We would the maintainers rush to support all of the latest major Keycloak releases ( 3 major semantic version releases this year alone (and the year is not over yet))

Apologies, but your criticism on why "new" projects being based on old keycloak versions is not warranted, in this case.

Sure, I get it. However I wouldn't wanna stay on any version of keycloak that faces CVEs.

[yannicschroeer]

It’s a pain in the… with the keycloak releases. We are open to contributions but may not keep up with the garbage they call release-cycles and API stability