This PR introduces a String getTaskName() default method to
the ScheduledTask interface and adjusts call sites to use the
implementation derived task name where possible.
Previously, ScheduledTask names were passed around separately, which
lead to unhelpful debug messages.
We now give ScheduledTask implementations control over their task-name
which allows for more flexible naming.
Enlist call StoreSyncEvent.fire(...) to after transaction to ensure realm is present in database.
Ensure that Realm is already committed before updating sync via UserStorageSyncManager
Align Sync task name generation for cancellation to support SyncFederationTest
Only log a message if sync task was actually canceled.
Signed-off-by: Thomas Darimont <thomas.darimont@googlemail.com>
Closes#26460
Signed-off-by: Václav Muzikář <vmuzikar@redhat.com>
Signed-off-by: Alexander Schwartz <aschwart@redhat.com>
Co-authored-by: Alexander Schwartz <aschwart@redhat.com>
Closes#22922
Signed-off-by: Alexander Schwartz <aschwart@redhat.com>
Signed-off-by: Pedro Ruivo <pruivo@redhat.com>
Co-authored-by: Pedro Ruivo <pruivo@redhat.com>
Closes#25077
Signed-off-by: Michal Hajas <mhajas@redhat.com>
Signed-off-by: Alexander Schwartz <aschwart@redhat.com>
Co-authored-by: Pedro Ruivo <pruivo@redhat.com>
Co-authored-by: Alexander Schwartz <aschwart@redhat.com>
closes#22372
Co-authored-by: Erik Jan de Wit <erikjan.dewit@gmail.com>
Co-authored-by: Pedro Igor <pigor.craveiro@gmail.com>
Co-authored-by: Michal Hajas <mhajas@redhat.com>
The problem is again the wrap(...) function.
In case the user is not found, then null is
returned. This can happen when a federated user
is deleted on the federation side but Keycloak
is not informed about it. In that case, the
session is still present but no UserModel can
be created.
Without this patch the stream contains null
values. Some downstream users can not cope well
with that.
The adjustment of the function getUserSessionsCount(...)
is slightly more expensive in execution, but
returns the correct number.
Closes#22428
Co-authored-by: Martin Krüger <mkrueger@mkru.de>
* Review comments to add a test, update the API description and adjust the map storage.
Closes#19348
Co-authored-by: Alexander Schwartz <aschwart@redhat.com>
* keycloak-20847 Find an appropriate key based on the given KID and JWA. Prefers matching on both inputs but will match on partials if found. Or return the first key if a match is not found.
Mark Key as fallback if it is the singular client certificate to be used for signed JWT authentication.
* Update js/apps/admin-ui/public/locales/en/clients.json
Co-authored-by: Marek Posolda <mposolda@gmail.com>
* Updating boolean variable name based on suggestions by Marek.
* Adding integration test specifically for the JWT parameters for regression #20847.
---------
Co-authored-by: Marek Posolda <mposolda@gmail.com>
With Hibernate ORM 6, pagination started to be unreliable: When
setting the max results only if the first row was 0 has randomly
affected other threads where first row was greater than 0. The
latter thread sometimes produced query which did *not* account
for the offset (cf. threads `-t1` and `-t2` below, while `-t2`
missed the `offset ? rows` part whic `-t3` has).
This has been fixed by setting the first row offset unconditionally.
Closes: #20202Closes: #16570
```
2023-06-02 10:19:03.855000 TRACE [org.keycloak.models.sessions.infinispan.initializer.SessionInitializerWorker] (blocking-thread-node-2-p8-t1) Running computation for segment 0 with worker 0
2023-06-02 10:19:03.856000 TRACE [org.keycloak.models.sessions.infinispan.initializer.OfflinePersistentUserSessionLoader] (blocking-thread-node-2-p8-t1) Loading sessions for segment=0 lastSessionId=00000000-0000-0000-0000-000000000000 first=0
2023-06-02 10:19:03.856000 DEBUG [org.keycloak.models.jpa.PaginationUtils] (blocking-thread-node-2-p8-t1) Set max to 64 in org.hibernate.query.sqm.internal.QuerySqmImpl@2fb60f8b
2023-06-02 10:19:03.856000 DEBUG [org.keycloak.models.jpa.PaginationUtils] (blocking-thread-node-2-p8-t1) After pagination: 0, 64
2023-06-02 10:19:03.857000 TRACE [org.keycloak.models.sessions.infinispan.initializer.SessionInitializerWorker] (blocking-thread-node-2-p8-t2) Running computation for segment 1 with worker 1
2023-06-02 10:19:03.857000 TRACE [org.keycloak.models.sessions.infinispan.initializer.OfflinePersistentUserSessionLoader] (blocking-thread-node-2-p8-t2) Loading sessions for segment=1 lastSessionId=00000000-0000-0000-0000-000000000000 first=64
2023-06-02 10:19:03.857000 TRACE [org.keycloak.models.sessions.infinispan.initializer.SessionInitializerWorker] (blocking-thread-node-2-p8-t3) Running computation for segment 2 with worker 2
2023-06-02 10:19:03.857000 DEBUG [org.keycloak.models.jpa.PaginationUtils] (blocking-thread-node-2-p8-t2) Set first to 64 in org.hibernate.query.sqm.internal.QuerySqmImpl@71464e9f
2023-06-02 10:19:03.857000 DEBUG [org.keycloak.models.jpa.PaginationUtils] (blocking-thread-node-2-p8-t2) Set max to 64 in org.hibernate.query.sqm.internal.QuerySqmImpl@71464e9f
2023-06-02 10:19:03.857000 DEBUG [org.keycloak.models.jpa.PaginationUtils] (blocking-thread-node-2-p8-t2) After pagination: 64, 64
2023-06-02 10:19:03.857000 TRACE [org.keycloak.models.sessions.infinispan.initializer.OfflinePersistentUserSessionLoader] (blocking-thread-node-2-p8-t3) Loading sessions for segment=2 lastSessionId=00000000-0000-0000-0000-000000000000 first=128
10:19:03,859 DEBUG [org.hibernate.SQL] (blocking-thread-node-2-p8-t1)
select
p1_0.OFFLINE_FLAG,
p1_0.USER_SESSION_ID,
p1_0.CREATED_ON,
p1_0.DATA,
p1_0.LAST_SESSION_REFRESH,
p1_0.REALM_ID,
p1_0.USER_ID
from
OFFLINE_USER_SESSION p1_0,
REALM r1_0
where
r1_0.ID=p1_0.REALM_ID
and p1_0.OFFLINE_FLAG=?
and p1_0.USER_SESSION_ID>?
order by
p1_0.USER_SESSION_ID fetch first ? rows only
10:19:03,859 DEBUG [org.hibernate.SQL] (blocking-thread-node-2-p8-t2)
select
p1_0.OFFLINE_FLAG,
p1_0.USER_SESSION_ID,
p1_0.CREATED_ON,
p1_0.DATA,
p1_0.LAST_SESSION_REFRESH,
p1_0.REALM_ID,
p1_0.USER_ID
from
OFFLINE_USER_SESSION p1_0,
REALM r1_0
where
r1_0.ID=p1_0.REALM_ID
and p1_0.OFFLINE_FLAG=?
and p1_0.USER_SESSION_ID>?
order by
p1_0.USER_SESSION_ID fetch first ? rows only
2023-06-02 10:19:03.860000 TRACE [org.hibernate.orm.jdbc.bind] (blocking-thread-node-2-p8-t1) binding parameter [1] as [VARCHAR] - [1]
2023-06-02 10:19:03.860000 TRACE [org.hibernate.orm.jdbc.bind] (blocking-thread-node-2-p8-t1) binding parameter [2] as [VARCHAR] - [00000000-0000-0000-0000-000000000000]
2023-06-02 10:19:03.860000 TRACE [org.hibernate.orm.jdbc.bind] (blocking-thread-node-2-p8-t1) binding parameter [3] as [INTEGER] - [64]
10:19:03,860 DEBUG [org.hibernate.SQL] (blocking-thread-node-2-p8-t3)
select
p1_0.OFFLINE_FLAG,
p1_0.USER_SESSION_ID,
p1_0.CREATED_ON,
p1_0.DATA,
p1_0.LAST_SESSION_REFRESH,
p1_0.REALM_ID,
p1_0.USER_ID
from
OFFLINE_USER_SESSION p1_0,
REALM r1_0
where
r1_0.ID=p1_0.REALM_ID
and p1_0.OFFLINE_FLAG=?
and p1_0.USER_SESSION_ID>?
order by
p1_0.USER_SESSION_ID offset ? rows fetch first ? rows only
2023-06-02 10:19:03.861000 TRACE [org.hibernate.orm.jdbc.bind] (blocking-thread-node-2-p8-t3) binding parameter [3] as [INTEGER] - [128]
2023-06-02 10:19:03.861000 TRACE [org.hibernate.orm.jdbc.bind] (blocking-thread-node-2-p8-t3) binding parameter [4] as [INTEGER] - [64]
```
Co-authored-by: mkanis <mkanis@redhat.com>
