Options/Examples:
- envoy-keycloak-oauth2 (GitHub example) -> OAuth (OpenID) example.
- envoy-keycloak-poc (GitHub example) OAuth (OpenID) example.
Options/Examples:
Assigned it just for review actual status, as it located in S&F Workboard.
Assigned it just for review actual status, as it located in S&F Workboard.
Assigned it just for review actual status, as it located in S&F Workboard.
Assigned it just for review, as it located in S&F Workboard.
Also we have a patch/branch with stable/old version (Python 2.7, Debian 9) where "thumbor community core" used as a dependency.
Hi @ori!
We are working with @hnowlan, who is responsible to get this deployed.
We fork "core" code source from Thumbor Community Core to Wikimedia Thumbor to reduce the number of dependencies that need to be maintained. (At the moment TC Core didn't support Python 3.7 and Thumbor 7).
We look into repository that already has some useful things for migration as it was configure for Debian Buster and Python 3+.
Also after migration we update packages and code sources to be relevant with new version of Debian Buster, Python 3.7 and Thumbor 7.
Hi @Krinkle , when we are working on migration Wikimedia Thumbor to Python 3.7 and Thumbor 7, we have a discussion and decide to fork required code from Thumbor Community Core to reduce the number of dependencies that need to be maintained.
@Aklapper Yep, you are right. Thank you!
After investigating of blocking an identity of user by Apereo CAS, we added a possibility to block user, when user trying to login. At the moment there is no possibility to force log out user from mediawiki when user was blocked in Apereo CAS as lack of user management. Apereo CAS don't have any flags/notifiers that could inform mediawiki that user are blocked. In simple way Apereo CAS just don't know what mean "blocked user". It's works with login flow, because when user trying to login, we request a data from user table to compare it. In this case we could modify request to check if user field "disabled" value is positive.