Menu
▾
▴
unity-idm-discuss — Unity discussion and support
You can subscribe to this list here.
| 2014 |
Jan
(3) |
Feb
(1) |
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
(2) |
Aug
(2) |
Sep
|
Oct
(3) |
Nov
|
Dec
(1) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2015 |
Jan
(20) |
Feb
(3) |
Mar
|
Apr
|
May
|
Jun
(15) |
Jul
(1) |
Aug
(7) |
Sep
(13) |
Oct
(2) |
Nov
(10) |
Dec
(1) |
| 2016 |
Jan
|
Feb
(2) |
Mar
|
Apr
(2) |
May
(1) |
Jun
|
Jul
(1) |
Aug
(2) |
Sep
(11) |
Oct
(7) |
Nov
(6) |
Dec
(11) |
| 2017 |
Jan
(10) |
Feb
(5) |
Mar
(27) |
Apr
(34) |
May
(25) |
Jun
(14) |
Jul
(7) |
Aug
(17) |
Sep
(11) |
Oct
(6) |
Nov
(14) |
Dec
(10) |
| 2018 |
Jan
(8) |
Feb
(19) |
Mar
(40) |
Apr
(9) |
May
(16) |
Jun
(23) |
Jul
(31) |
Aug
(7) |
Sep
(9) |
Oct
(6) |
Nov
(14) |
Dec
(19) |
| 2019 |
Jan
(4) |
Feb
(6) |
Mar
(1) |
Apr
(2) |
May
(6) |
Jun
(3) |
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
(19) |
Dec
(14) |
| 2020 |
Jan
(10) |
Feb
(24) |
Mar
(49) |
Apr
(26) |
May
(12) |
Jun
(4) |
Jul
(13) |
Aug
(32) |
Sep
(13) |
Oct
(10) |
Nov
(4) |
Dec
(16) |
| 2021 |
Jan
(2) |
Feb
(8) |
Mar
(15) |
Apr
(19) |
May
(5) |
Jun
(13) |
Jul
(6) |
Aug
(38) |
Sep
(11) |
Oct
(18) |
Nov
(11) |
Dec
(13) |
| 2022 |
Jan
(10) |
Feb
(21) |
Mar
(28) |
Apr
(3) |
May
(7) |
Jun
(9) |
Jul
(14) |
Aug
(13) |
Sep
(8) |
Oct
(29) |
Nov
(1) |
Dec
(21) |
| 2023 |
Jan
(19) |
Feb
(9) |
Mar
|
Apr
(10) |
May
(7) |
Jun
(10) |
Jul
(14) |
Aug
(17) |
Sep
(1) |
Oct
(9) |
Nov
(5) |
Dec
(14) |
| 2024 |
Jan
(12) |
Feb
(2) |
Mar
(8) |
Apr
(1) |
May
(6) |
Jun
(6) |
Jul
(24) |
Aug
(15) |
Sep
(1) |
Oct
(6) |
Nov
(20) |
Dec
(14) |
| 2025 |
Jan
(12) |
Feb
(2) |
Mar
(10) |
Apr
(11) |
May
(13) |
Jun
(1) |
Jul
(2) |
Aug
(2) |
Sep
(8) |
Oct
|
Nov
|
Dec
|
|
From: Krzysztof B. <kb...@un...> - 2024-10-20 12:05:13
|
Dear Subscribers,
I'm happy to share that a new patch release 4.0.2 is available.
In this patch we were focused on improving the following problems:
* *Mail subsystem*: several problems were reported, which were
resulting from updates of external dependencies.
* *Performance* in case of big user directories, related to
invitations and registration handling.
* Editing of *image* type *attributes.*
All relevant links are available here:
https://unity-idm.eu/releases/release-4-0-2/
Best regards,
Krzysztof
|
|
From: Sander A. <sa....@fz...> - 2024-09-25 10:16:08
|
Hello Roman, I'm very sorry for the very long delay. If unity does automated management of the policy, I would expect that a new version, creates an enquiry, which is attached to all users, who filled up the policy so far, e.g. by adding them to a group. I would expect this for all versions and not only for the first update. I would also expect that the "sys:policy-agreement-state" attribute is updated. If there is also no automated way for this, which would be also fine, this needs to be written clearly in the manual and administrators must create the enquiry after policy updates by themselves. Please et me know if something is unclear. Best regards, Sander On Tue, 2024-08-20 at 11:51 +0200, Roman Krysiński wrote: > Hello Sander, > > After discussion w/ the team, we believe there might be still > misunderstanding of how Policy Documents works. > Before going into explanations I would like to understand first your > thinking in this regard. > > [Roman] > > As mentioned, if a user had an enquiry already completed, > revision > [Roman] > > update will not force the user to re-do the enquiry. > [Sander] > Ok but the behaviour is not that what I would expect when > I have policy > [Sander] > management. Could you please add this to the manual. It > sounds a bit > [Sander] > strange to me that you have an automated update rotine for > the first > [Sander] > policy revision but not for the later ones. > > Can you elaborate on what is the expected behavior? > And to what automation routine you are referring to? > > Thank you, > Roman > > wt., 6 sie 2024 o 11:47 Sander Apweiler <sa....@fz...> > napisał(a): > > Good morning Roman, > > so far we use the policies only in registration forms, not on the > > IdP > > level. Since we startet to use groups which have their own policies > > and > > updated the top level, we are using them in enquiries too. > > > > So far I do not see any reason for not using the IdP level. Are the > > information (date/time and Policy version) stored in attributes > > too? > > And in ehich file I need to configure the policies? > > > > Some other comments to your previous mail are inline. > > > > > > On Tue, 2024-08-06 at 11:18 +0200, Roman Krysiński wrote: > > > Good morning Sander, > > > > > > Last but not least for "the third side effect" you've pointed out > > > - > > > would it work for you to configure this policy on IdP level? In > > > such > > > a case it wouldn't be even needed to create enquiries each time > > > policy revision changes to force users to accept it. > > > > > > Best regards, > > > Roman > > > > > > wt., 6 sie 2024 o 11:09 Roman Krysiński <ro...@un...> > > > napisał(a): > > > > Good morning Sander, > > > > > > > > Let me summarize features around "Policy documents" and I hope > > > > that > > > > will clarify cases you've pointed out in previous email. > > > > > > > > Policy documents, that can be defined in "Settings > Policy > > > > documents" console view, itself do not bring > > > > enforcement capabilities. > > > > They can be used in conjunction with registration and enquiry > > > > forms > > > > as well as on IdP level. > > > > * Used on registration form is useful to enforce a specific > > > > policy > > > > during user creation, and then record this fact in the system > > > > (as > > > > you pointed out in sys:policy-agreement-state attribute) > > > > * When a policy is used at the IdP level (Vaadin-based IdPs > > > > contain > > > > a “Policy Agreements” tab where this can be configured), the > > > > user > > > > will be required to see and accept the policy after logging > > > > into > > > > such an IdP if the current system policy revision does not > > > > match > > > > the one recorded in the user’s sys:policy-agreement-state > > > > attribute. > > > > * Policy document can also be used in enquiry, it will be shown > > > > there only when current system policy revision does not match > > > > the > > > > one recorded in the user’s sys:policy-agreement-state > > > > attribute. In > > > > other words if the user has already accepted the current > > > > policy, > > > > enquiry will not show it. The fact that the user has completed > > > > specific enquiry is recorded in sys:FilledEnquires attribute. > > > > > > > > Note that changing the policy document revision does not > > > > influence > > > > on the sys:FilledEnquires, so if e.g. user has completed an > > > > enquiry > > > > of "User is requested, mandatory" type, which is configured > > > > with a > > > > policy, that revision has changed, then this enquiry will not > > > > be > > > > enforced once more. This can be done with new enquiry OR by > > > > configuring this in IdP level. > > > > > > > > > We encountered on Monday the situation where we changed the > > > > > revision of a policy from > > > > > version 2 to version 3 (no content changes) and the user did > > > > > not > > > > > get > > > > > the update enquiry because they had it already at the update > > > > > to > > > > > version 2. > > > > As mentioned, if a user had an enquiry already completed, > > > > revision > > > > update will not force the user to re-do the enquiry. > > Ok but the behaviour is not that what I would expect when I have > > policy > > management. Could you please add this to the manual. It sounds a > > bit > > strange to me that you have an automated update rotine for the > > first > > policy revision but not for the later ones. > > > > > > > > > We also saw that the update enquiry did not set or update the > > > > > value > > > > > of the sys:policy-agreement-state attribute > > > > Can you confirm that the enquiry request in question was > > > > accepted? > > > > If so, could you please provide more details on how to > > > > reproduce > > > > the problem? > > Yes. I added a screen shot. I also have some accounts, which has > > only > > the sys:FilledEnquieries attribute from the Update enquire but not > > the > > sys:policy-agreeement-state. > > > > Best regards, > > Sander > > > > > > > > > > > (...) a new user account, who agreed the latest version > > > > > during > > > > > the > > > > > registration, got an empty enquiry (no checkbox and policy, > > > > > but > > > > > on > > > > > cancel and submit buttons) at the first login > > > > As noted, the policy is not shown on enquiry form, when the > > > > user > > > > has already accepted it. > > > > I see your point however that this is not the best user > > > > experience, > > > > and there is room for improvement here. > > > > We will think about this use case and a better handling. > > > > > > > > In addition to the problem reported by Piotr with enquiry we've > > > > found three more items to address and targeted for the 4.0.1 > > > > patch: > > > > * Enquiry logout does not work > > > > * Enquiries are not enforced when logging to hope ui > > > > * Improve the layout of enquiry buttons > > > > > > > > Please let me know in case of any further questions. > > > > > > > > Best regards, > > > > Roman > > > > > > > > > > > > śr., 31 lip 2024 o 07:36 Sander Apweiler > > > > <sa....@fz...> napisał(a): > > > > > Good morning, > > > > > > > > > > the problems we found were based on unity 3.16.1. We > > > > > encountered > > > > > on > > > > > Monday the situation where we changed the revision of a > > > > > policy > > > > > from > > > > > version 2 to version 3 (no content changes) and the user did > > > > > not > > > > > get > > > > > the update enquiry because they had it already at the update > > > > > to > > > > > version > > > > > 2. We also saw that the update enquiry did not set or update > > > > > the > > > > > value > > > > > of the sys:policy-agreement-state attribute. And the third > > > > > side > > > > > effect > > > > > was that a new user account, who agreed the latest version > > > > > during > > > > > the > > > > > registration, got an empty enquiry (no checkbox and policy, > > > > > but > > > > > on > > > > > cancel and submit buttons) at the first login. Our plan was > > > > > to > > > > > verify > > > > > this on unity 4, before we report those issues. > > > > > > > > > > Best regards, > > > > > Sander > > > > > > > > > > > > > > > On Tue, 2024-07-30 at 15:05 +0200, Piotr Piernik wrote: > > > > > > Dear Sander > > > > > > Generally If the policy has changed with the revision > > > > > > number > > > > > > increase, > > > > > > it should appear to users automatically. > > > > > > Could you please provide more details in which scenario it > > > > > > won't > > > > > > work? > > > > > > > > > > > > > > > > > > > > > > > > Best regards > > > > > > Piotr > > > > > > > > > > > > W dniu 30.07.2024 o 12:36, Sander Apweiler pisze: > > > > > > > Dear Piotr, > > > > > > > nice to hear you found the reason. Can you answer my > > > > > > > second > > > > > > > question as > > > > > > > well? We found some issues regarding policies in our > > > > > > > 3.16.1 > > > > > > > instances > > > > > > > and we are not sure if the problems based on our > > > > > > > misconfiguration > > > > > > > or > > > > > > > unity. > > > > > > > > > > > > > > Best regards, > > > > > > > Sander > > > > > > > > > > > > > > > > > > > > > On Tue, 2024-07-30 at 12:20 +0200, Piotr Piernik wrote: > > > > > > > > > > > > > > > > Dear Sander > > > > > > > > We have problem in policy document editor - saves > > > > > > > > optional > > > > > > > > policy > > > > > > > > documents as mandatory and vice versa. > > > > > > > > We will fix it in 4.0.1 patch. > > > > > > > > > > > > > > > > Best regards > > > > > > > > Piotr > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > W dniu 30.07.2024 o 07:13, Sander Apweiler pisze: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Good morning Krzysztof, > > > > > > > > > good morning Roman, > > > > > > > > > > > > > > > > > > we found another bug in unity 4. We created a > > > > > > > > > mandatory > > > > > > > > > policy > > > > > > > > > (see > > > > > > > > > 1st > > > > > > > > > screenshot) and added it to the registration form > > > > > > > > > (see > > > > > > > > > 2nd > > > > > > > > > screenshot). > > > > > > > > > This policy should be mandatory but I can register > > > > > > > > > without > > > > > > > > > confirmation > > > > > > > > > of the policy. > > > > > > > > > > > > > > > > > > Another question regarding policies because I do not > > > > > > > > > remember > > > > > > > > > and > > > > > > > > > the > > > > > > > > > manual is not that clear in this point. When I create > > > > > > > > > a > > > > > > > > > new > > > > > > > > > version > > > > > > > > > of > > > > > > > > > a policy, is the confirmation of the new version > > > > > > > > > shown to > > > > > > > > > all > > > > > > > > > users > > > > > > > > > or > > > > > > > > > do I need to create enquieries manually? > > > > > > > > > > > > > > > > > > Best regards, > > > > > > > > > Sander > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > Unity-idm-discuss mailing list > > > > > > > > > Uni...@li... > > > > > > > > > https://lists.sourceforge.net/lists/listinfo/unity-idm-discuss > > > > > > > > > > > > > > > > > > > > > > > > -- Large-Scale Data Science Juelich Supercomputing Centre phone: +49 2461 61 8847 fax: +49 2461 61 6656 email: sa....@fz... ----------------------------------------------------------------------- ----------------------------------------------------------------------- Forschungszentrum Jülich GmbH 52425 Jülich Sitz der Gesellschaft: Jülich Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDir Stefan Müller Geschäftsführung: Prof. Dr. Astrid Lambrecht (Vorsitzende), Karsten Beneke (stellv. Vorsitzender), Prof. Dr. Ir. Pieter Jansens ----------------------------------------------------------------------- ----------------------------------------------------------------------- |
|
From: Krzysztof B. <kb...@un...> - 2024-08-21 12:01:21
|
Dear Subscribers, Unity 4.0.1 patch was released. In this patch release we were focused on improving various problems found in major 4.0.0 release. It contains over a dozen of fixes improving the overall stability. For more details and download links see https://unity-idm.eu/releases/release-4-0-1/ Best regards, Krzysztof |
|
From: Krzysztof B. <kb...@un...> - 2024-08-21 09:27:27
|
Hi Sander, W dniu 19.08.2024 o 10:22, Sander Apweiler pisze: > Good morning Krzystof, > good morning Roman, > > > We are setting up a new unity instance as proxy for services offered by > our institute. This should give users always the same look and feel in > the login. The main account source is a local OP, but it is also > connected to a few selected external OPs. > > Another condition is that users shall have only one account. For this > reason we are using the email address as a second identifier, beside > the sub of OIDC. As far as I understood we must use the "REQUIRE_MATCH" > policy if both identifiers must match. Can you confirm this? When we > are using the "REQUIRE_MATCH" user must create an account, e.g. via No > account? Sign up! link in the UI before they login to unity in the > normal login flow. Can you confirm this, too? When we use the > "CREATE_OR_MATCH" policy unity recognises that users are not registered > in the system, if the users login for the first time, but unity would > start merging users only by the email from different OPs. Since email > addresses are reused in time, we do not want to have a implicit merge > by email address only. I'm not 100% sure if I understood all the details here, but roughly all of the above sounds correct to me. > In 9 years of operating those kind of proxies, we made the experience, > the users do not follow the No Account? Sign Up link, if they see the > big WAYF and can select their home organisation. Also service providers > do not want to have this additional step of clicking on the > registration button before users can start using the service. > Do you see any possibilities to have the identity mapping like > REQUIRE_MATCH but display the registration/associate buttons, if the > user is not known in the system? Yes, use the MATCH policy. If there will be no match, Unity can show an option to register after failed login (you have to setup a registration form for unknown users: you may also enable an option to associate remotely authenticated user with an existing account (there is a checkbox on authenticator). The registration form that you will link can be prefilled with data coming from remote IdP, as well as you have access to it in form's automation rules. HTH, Krzysztof |
|
From: Roman K. <ro...@un...> - 2024-08-20 09:52:00
|
Hello Sander, After discussion w/ the team, we believe there might be still misunderstanding of how Policy Documents works. Before going into explanations I would like to understand first your thinking in this regard. [Roman] > > As mentioned, if a user had an enquiry already completed, revision [Roman] > > update will not force the user to re-do the enquiry. [Sander] > Ok but the behaviour is not that what I would expect when I have policy [Sander] > management. Could you please add this to the manual. It sounds a bit [Sander] > strange to me that you have an automated update rotine for the first [Sander] > policy revision but not for the later ones. Can you elaborate on what is the expected behavior? And to what automation routine you are referring to? Thank you, Roman wt., 6 sie 2024 o 11:47 Sander Apweiler <sa....@fz...> napisał(a): > Good morning Roman, > so far we use the policies only in registration forms, not on the IdP > level. Since we startet to use groups which have their own policies and > updated the top level, we are using them in enquiries too. > > So far I do not see any reason for not using the IdP level. Are the > information (date/time and Policy version) stored in attributes too? > And in ehich file I need to configure the policies? > > Some other comments to your previous mail are inline. > > > On Tue, 2024-08-06 at 11:18 +0200, Roman Krysiński wrote: > > Good morning Sander, > > > > Last but not least for "the third side effect" you've pointed out - > > would it work for you to configure this policy on IdP level? In such > > a case it wouldn't be even needed to create enquiries each time > > policy revision changes to force users to accept it. > > > > Best regards, > > Roman > > > > wt., 6 sie 2024 o 11:09 Roman Krysiński <ro...@un...> > > napisał(a): > > > Good morning Sander, > > > > > > Let me summarize features around "Policy documents" and I hope that > > > will clarify cases you've pointed out in previous email. > > > > > > Policy documents, that can be defined in "Settings > Policy > > > documents" console view, itself do not bring > > > enforcement capabilities. > > > They can be used in conjunction with registration and enquiry forms > > > as well as on IdP level. > > > * Used on registration form is useful to enforce a specific policy > > > during user creation, and then record this fact in the system (as > > > you pointed out in sys:policy-agreement-state attribute) > > > * When a policy is used at the IdP level (Vaadin-based IdPs contain > > > a “Policy Agreements” tab where this can be configured), the user > > > will be required to see and accept the policy after logging into > > > such an IdP if the current system policy revision does not match > > > the one recorded in the user’s sys:policy-agreement-state > > > attribute. > > > * Policy document can also be used in enquiry, it will be shown > > > there only when current system policy revision does not match the > > > one recorded in the user’s sys:policy-agreement-state attribute. In > > > other words if the user has already accepted the current policy, > > > enquiry will not show it. The fact that the user has completed > > > specific enquiry is recorded in sys:FilledEnquires attribute. > > > > > > Note that changing the policy document revision does not influence > > > on the sys:FilledEnquires, so if e.g. user has completed an enquiry > > > of "User is requested, mandatory" type, which is configured with a > > > policy, that revision has changed, then this enquiry will not be > > > enforced once more. This can be done with new enquiry OR by > > > configuring this in IdP level. > > > > > > > We encountered on Monday the situation where we changed the > > > > revision of a policy from > > > > version 2 to version 3 (no content changes) and the user did not > > > > get > > > > the update enquiry because they had it already at the update to > > > > version 2. > > > As mentioned, if a user had an enquiry already completed, revision > > > update will not force the user to re-do the enquiry. > Ok but the behaviour is not that what I would expect when I have policy > management. Could you please add this to the manual. It sounds a bit > strange to me that you have an automated update rotine for the first > policy revision but not for the later ones. > > > > > > > We also saw that the update enquiry did not set or update the > > > > value > > > > of the sys:policy-agreement-state attribute > > > Can you confirm that the enquiry request in question was accepted? > > > If so, could you please provide more details on how to reproduce > > > the problem? > Yes. I added a screen shot. I also have some accounts, which has only > the sys:FilledEnquieries attribute from the Update enquire but not the > sys:policy-agreeement-state. > > Best regards, > Sander > > > > > > > > (...) a new user account, who agreed the latest version during > > > > the > > > > registration, got an empty enquiry (no checkbox and policy, but > > > > on > > > > cancel and submit buttons) at the first login > > > As noted, the policy is not shown on enquiry form, when the user > > > has already accepted it. > > > I see your point however that this is not the best user experience, > > > and there is room for improvement here. > > > We will think about this use case and a better handling. > > > > > > In addition to the problem reported by Piotr with enquiry we've > > > found three more items to address and targeted for the 4.0.1 patch: > > > * Enquiry logout does not work > > > * Enquiries are not enforced when logging to hope ui > > > * Improve the layout of enquiry buttons > > > > > > Please let me know in case of any further questions. > > > > > > Best regards, > > > Roman > > > > > > > > > śr., 31 lip 2024 o 07:36 Sander Apweiler > > > <sa....@fz...> napisał(a): > > > > Good morning, > > > > > > > > the problems we found were based on unity 3.16.1. We encountered > > > > on > > > > Monday the situation where we changed the revision of a policy > > > > from > > > > version 2 to version 3 (no content changes) and the user did not > > > > get > > > > the update enquiry because they had it already at the update to > > > > version > > > > 2. We also saw that the update enquiry did not set or update the > > > > value > > > > of the sys:policy-agreement-state attribute. And the third side > > > > effect > > > > was that a new user account, who agreed the latest version during > > > > the > > > > registration, got an empty enquiry (no checkbox and policy, but > > > > on > > > > cancel and submit buttons) at the first login. Our plan was to > > > > verify > > > > this on unity 4, before we report those issues. > > > > > > > > Best regards, > > > > Sander > > > > > > > > > > > > On Tue, 2024-07-30 at 15:05 +0200, Piotr Piernik wrote: > > > > > Dear Sander > > > > > Generally If the policy has changed with the revision number > > > > > increase, > > > > > it should appear to users automatically. > > > > > Could you please provide more details in which scenario it > > > > > won't > > > > > work? > > > > > > > > > > > > > > > > > > > > Best regards > > > > > Piotr > > > > > > > > > > W dniu 30.07.2024 o 12:36, Sander Apweiler pisze: > > > > > > Dear Piotr, > > > > > > nice to hear you found the reason. Can you answer my second > > > > > > question as > > > > > > well? We found some issues regarding policies in our 3.16.1 > > > > > > instances > > > > > > and we are not sure if the problems based on our > > > > > > misconfiguration > > > > > > or > > > > > > unity. > > > > > > > > > > > > Best regards, > > > > > > Sander > > > > > > > > > > > > > > > > > > On Tue, 2024-07-30 at 12:20 +0200, Piotr Piernik wrote: > > > > > > > > > > > > > > Dear Sander > > > > > > > We have problem in policy document editor - saves > > > > > > > optional > > > > > > > policy > > > > > > > documents as mandatory and vice versa. > > > > > > > We will fix it in 4.0.1 patch. > > > > > > > > > > > > > > Best regards > > > > > > > Piotr > > > > > > > > > > > > > > > > > > > > > > > > > > > > W dniu 30.07.2024 o 07:13, Sander Apweiler pisze: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Good morning Krzysztof, > > > > > > > > good morning Roman, > > > > > > > > > > > > > > > > we found another bug in unity 4. We created a mandatory > > > > > > > > policy > > > > > > > > (see > > > > > > > > 1st > > > > > > > > screenshot) and added it to the registration form (see > > > > > > > > 2nd > > > > > > > > screenshot). > > > > > > > > This policy should be mandatory but I can register > > > > > > > > without > > > > > > > > confirmation > > > > > > > > of the policy. > > > > > > > > > > > > > > > > Another question regarding policies because I do not > > > > > > > > remember > > > > > > > > and > > > > > > > > the > > > > > > > > manual is not that clear in this point. When I create a > > > > > > > > new > > > > > > > > version > > > > > > > > of > > > > > > > > a policy, is the confirmation of the new version shown to > > > > > > > > all > > > > > > > > users > > > > > > > > or > > > > > > > > do I need to create enquieries manually? > > > > > > > > > > > > > > > > Best regards, > > > > > > > > Sander > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > Unity-idm-discuss mailing list > > > > > > > > Uni...@li... > > > > > > > > > https://lists.sourceforge.net/lists/listinfo/unity-idm-discuss > > > > > > > > > > > > > > > > > > > > > -- > Large-Scale Data Science > Juelich Supercomputing Centre > > phone: +49 2461 61 8847 > fax: +49 2461 61 6656 > email: sa....@fz... > > ----------------------------------------------------------------------- > ----------------------------------------------------------------------- > Forschungszentrum Jülich GmbH > 52425 Jülich > Sitz der Gesellschaft: Jülich > Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498 > Vorsitzender des Aufsichtsrats: MinDir Stefan Müller > Geschäftsführung: Prof. Dr. Astrid Lambrecht (Vorsitzende), > Karsten Beneke (stellv. Vorsitzender), Prof. Dr. Ir. Pieter Jansens > ----------------------------------------------------------------------- > ----------------------------------------------------------------------- > > > _______________________________________________ > Unity-idm-discuss mailing list > Uni...@li... > https://lists.sourceforge.net/lists/listinfo/unity-idm-discuss > |
|
From: Sander A. <sa....@fz...> - 2024-08-19 08:22:18
|
Good morning Krzystof, good morning Roman, We are setting up a new unity instance as proxy for services offered by our institute. This should give users always the same look and feel in the login. The main account source is a local OP, but it is also connected to a few selected external OPs. Another condition is that users shall have only one account. For this reason we are using the email address as a second identifier, beside the sub of OIDC. As far as I understood we must use the "REQUIRE_MATCH" policy if both identifiers must match. Can you confirm this? When we are using the "REQUIRE_MATCH" user must create an account, e.g. via No account? Sign up! link in the UI before they login to unity in the normal login flow. Can you confirm this, too? When we use the "CREATE_OR_MATCH" policy unity recognises that users are not registered in the system, if the users login for the first time, but unity would start merging users only by the email from different OPs. Since email addresses are reused in time, we do not want to have a implicit merge by email address only. In 9 years of operating those kind of proxies, we made the experience, the users do not follow the No Account? Sign Up link, if they see the big WAYF and can select their home organisation. Also service providers do not want to have this additional step of clicking on the registration button before users can start using the service. Do you see any possibilities to have the identity mapping like REQUIRE_MATCH but display the registration/associate buttons, if the user is not known in the system? Best regards, Sander -- Large-Scale Data Science Juelich Supercomputing Centre phone: +49 2461 61 8847 fax: +49 2461 61 6656 email: sa....@fz... ----------------------------------------------------------------------- ----------------------------------------------------------------------- Forschungszentrum Jülich GmbH 52425 Jülich Sitz der Gesellschaft: Jülich Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDir Stefan Müller Geschäftsführung: Prof. Dr. Astrid Lambrecht (Vorsitzende), Karsten Beneke (stellv. Vorsitzender), Prof. Dr. Ir. Pieter Jansens ----------------------------------------------------------------------- ----------------------------------------------------------------------- |
|
From: Krzysztof B. <kb...@un...> - 2024-08-16 08:39:20
|
Hi Sander, W dniu 15.08.2024 o 08:11, Sander Apweiler pisze: > Good morning Krzysztof, > good morning Roman, > > We were ask by our users/providers of services if unity can support > back-channel logout [1]. As far as we can see this is not the case. Do > you have any plans about this? > Unfortunately not. It is on the radar, but currently quite far in the backlog (after general performance and MFA improvements). Best, Krzysztof |
|
From: Sander A. <sa....@fz...> - 2024-08-15 06:11:25
|
Good morning Krzysztof, good morning Roman, We were ask by our users/providers of services if unity can support back-channel logout [1]. As far as we can see this is not the case. Do you have any plans about this? Best regards, Sander [1]: https://openid.net/specs/openid-connect-backchannel-1_0.html -- Large-Scale Data Science Juelich Supercomputing Centre phone: +49 2461 61 8847 fax: +49 2461 61 6656 email: sa....@fz... ----------------------------------------------------------------------- ----------------------------------------------------------------------- Forschungszentrum Jülich GmbH 52425 Jülich Sitz der Gesellschaft: Jülich Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDir Stefan Müller Geschäftsführung: Prof. Dr. Astrid Lambrecht (Vorsitzende), Karsten Beneke (stellv. Vorsitzender), Prof. Dr. Ir. Pieter Jansens ----------------------------------------------------------------------- ----------------------------------------------------------------------- |
|
From: Roman K. <ro...@un...> - 2024-08-14 06:09:21
|
Good morning Sander, > Are the information (date/time and Policy version) stored in attributes too? Yes > And in ehich file I need to configure the policies? On the IdP level, in case of OAuth IdP take a look at OAuth 2 Authorization Server and OpenId Connect endpoints <https://www.unity-idm.eu/documentation/unity-4.0.0/manual.html> section of manual and properties w/ policyAgreements in name e.g. unity.oauth2.as.policyAgreements, unity.oauth2.as .policyAgreementsInfo etc. We are processing the rest of your input from this email thread, stay tuned. Thank you for your patience, Roman wt., 6 sie 2024 o 11:47 Sander Apweiler <sa....@fz...> napisał(a): > Good morning Roman, > so far we use the policies only in registration forms, not on the IdP > level. Since we startet to use groups which have their own policies and > updated the top level, we are using them in enquiries too. > > So far I do not see any reason for not using the IdP level. Are the > information (date/time and Policy version) stored in attributes too? > And in ehich file I need to configure the policies? > > Some other comments to your previous mail are inline. > > > On Tue, 2024-08-06 at 11:18 +0200, Roman Krysiński wrote: > > Good morning Sander, > > > > Last but not least for "the third side effect" you've pointed out - > > would it work for you to configure this policy on IdP level? In such > > a case it wouldn't be even needed to create enquiries each time > > policy revision changes to force users to accept it. > > > > Best regards, > > Roman > > > > wt., 6 sie 2024 o 11:09 Roman Krysiński <ro...@un...> > > napisał(a): > > > Good morning Sander, > > > > > > Let me summarize features around "Policy documents" and I hope that > > > will clarify cases you've pointed out in previous email. > > > > > > Policy documents, that can be defined in "Settings > Policy > > > documents" console view, itself do not bring > > > enforcement capabilities. > > > They can be used in conjunction with registration and enquiry forms > > > as well as on IdP level. > > > * Used on registration form is useful to enforce a specific policy > > > during user creation, and then record this fact in the system (as > > > you pointed out in sys:policy-agreement-state attribute) > > > * When a policy is used at the IdP level (Vaadin-based IdPs contain > > > a “Policy Agreements” tab where this can be configured), the user > > > will be required to see and accept the policy after logging into > > > such an IdP if the current system policy revision does not match > > > the one recorded in the user’s sys:policy-agreement-state > > > attribute. > > > * Policy document can also be used in enquiry, it will be shown > > > there only when current system policy revision does not match the > > > one recorded in the user’s sys:policy-agreement-state attribute. In > > > other words if the user has already accepted the current policy, > > > enquiry will not show it. The fact that the user has completed > > > specific enquiry is recorded in sys:FilledEnquires attribute. > > > > > > Note that changing the policy document revision does not influence > > > on the sys:FilledEnquires, so if e.g. user has completed an enquiry > > > of "User is requested, mandatory" type, which is configured with a > > > policy, that revision has changed, then this enquiry will not be > > > enforced once more. This can be done with new enquiry OR by > > > configuring this in IdP level. > > > > > > > We encountered on Monday the situation where we changed the > > > > revision of a policy from > > > > version 2 to version 3 (no content changes) and the user did not > > > > get > > > > the update enquiry because they had it already at the update to > > > > version 2. > > > As mentioned, if a user had an enquiry already completed, revision > > > update will not force the user to re-do the enquiry. > Ok but the behaviour is not that what I would expect when I have policy > management. Could you please add this to the manual. It sounds a bit > strange to me that you have an automated update rotine for the first > policy revision but not for the later ones. > > > > > > > We also saw that the update enquiry did not set or update the > > > > value > > > > of the sys:policy-agreement-state attribute > > > Can you confirm that the enquiry request in question was accepted? > > > If so, could you please provide more details on how to reproduce > > > the problem? > Yes. I added a screen shot. I also have some accounts, which has only > the sys:FilledEnquieries attribute from the Update enquire but not the > sys:policy-agreeement-state. > > Best regards, > Sander > > > > > > > > (...) a new user account, who agreed the latest version during > > > > the > > > > registration, got an empty enquiry (no checkbox and policy, but > > > > on > > > > cancel and submit buttons) at the first login > > > As noted, the policy is not shown on enquiry form, when the user > > > has already accepted it. > > > I see your point however that this is not the best user experience, > > > and there is room for improvement here. > > > We will think about this use case and a better handling. > > > > > > In addition to the problem reported by Piotr with enquiry we've > > > found three more items to address and targeted for the 4.0.1 patch: > > > * Enquiry logout does not work > > > * Enquiries are not enforced when logging to hope ui > > > * Improve the layout of enquiry buttons > > > > > > Please let me know in case of any further questions. > > > > > > Best regards, > > > Roman > > > > > > > > > śr., 31 lip 2024 o 07:36 Sander Apweiler > > > <sa....@fz...> napisał(a): > > > > Good morning, > > > > > > > > the problems we found were based on unity 3.16.1. We encountered > > > > on > > > > Monday the situation where we changed the revision of a policy > > > > from > > > > version 2 to version 3 (no content changes) and the user did not > > > > get > > > > the update enquiry because they had it already at the update to > > > > version > > > > 2. We also saw that the update enquiry did not set or update the > > > > value > > > > of the sys:policy-agreement-state attribute. And the third side > > > > effect > > > > was that a new user account, who agreed the latest version during > > > > the > > > > registration, got an empty enquiry (no checkbox and policy, but > > > > on > > > > cancel and submit buttons) at the first login. Our plan was to > > > > verify > > > > this on unity 4, before we report those issues. > > > > > > > > Best regards, > > > > Sander > > > > > > > > > > > > On Tue, 2024-07-30 at 15:05 +0200, Piotr Piernik wrote: > > > > > Dear Sander > > > > > Generally If the policy has changed with the revision number > > > > > increase, > > > > > it should appear to users automatically. > > > > > Could you please provide more details in which scenario it > > > > > won't > > > > > work? > > > > > > > > > > > > > > > > > > > > Best regards > > > > > Piotr > > > > > > > > > > W dniu 30.07.2024 o 12:36, Sander Apweiler pisze: > > > > > > Dear Piotr, > > > > > > nice to hear you found the reason. Can you answer my second > > > > > > question as > > > > > > well? We found some issues regarding policies in our 3.16.1 > > > > > > instances > > > > > > and we are not sure if the problems based on our > > > > > > misconfiguration > > > > > > or > > > > > > unity. > > > > > > > > > > > > Best regards, > > > > > > Sander > > > > > > > > > > > > > > > > > > On Tue, 2024-07-30 at 12:20 +0200, Piotr Piernik wrote: > > > > > > > > > > > > > > Dear Sander > > > > > > > We have problem in policy document editor - saves > > > > > > > optional > > > > > > > policy > > > > > > > documents as mandatory and vice versa. > > > > > > > We will fix it in 4.0.1 patch. > > > > > > > > > > > > > > Best regards > > > > > > > Piotr > > > > > > > > > > > > > > > > > > > > > > > > > > > > W dniu 30.07.2024 o 07:13, Sander Apweiler pisze: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Good morning Krzysztof, > > > > > > > > good morning Roman, > > > > > > > > > > > > > > > > we found another bug in unity 4. We created a mandatory > > > > > > > > policy > > > > > > > > (see > > > > > > > > 1st > > > > > > > > screenshot) and added it to the registration form (see > > > > > > > > 2nd > > > > > > > > screenshot). > > > > > > > > This policy should be mandatory but I can register > > > > > > > > without > > > > > > > > confirmation > > > > > > > > of the policy. > > > > > > > > > > > > > > > > Another question regarding policies because I do not > > > > > > > > remember > > > > > > > > and > > > > > > > > the > > > > > > > > manual is not that clear in this point. When I create a > > > > > > > > new > > > > > > > > version > > > > > > > > of > > > > > > > > a policy, is the confirmation of the new version shown to > > > > > > > > all > > > > > > > > users > > > > > > > > or > > > > > > > > do I need to create enquieries manually? > > > > > > > > > > > > > > > > Best regards, > > > > > > > > Sander > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > Unity-idm-discuss mailing list > > > > > > > > Uni...@li... > > > > > > > > > https://lists.sourceforge.net/lists/listinfo/unity-idm-discuss > > > > > > > > > > > > > > > > > > > > > -- > Large-Scale Data Science > Juelich Supercomputing Centre > > phone: +49 2461 61 8847 > fax: +49 2461 61 6656 > email: sa....@fz... > > ----------------------------------------------------------------------- > ----------------------------------------------------------------------- > Forschungszentrum Jülich GmbH > 52425 Jülich > Sitz der Gesellschaft: Jülich > Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498 > Vorsitzender des Aufsichtsrats: MinDir Stefan Müller > Geschäftsführung: Prof. Dr. Astrid Lambrecht (Vorsitzende), > Karsten Beneke (stellv. Vorsitzender), Prof. Dr. Ir. Pieter Jansens > ----------------------------------------------------------------------- > ----------------------------------------------------------------------- > > > _______________________________________________ > Unity-idm-discuss mailing list > Uni...@li... > https://lists.sourceforge.net/lists/listinfo/unity-idm-discuss > |
|
From: Krzysztof B. <kb...@un...> - 2024-08-13 09:42:53
|
Hi Sander, W dniu 12.08.2024 o 12:06, Sander Apweiler pisze: > Hi Krzysztof, > > most IdPs are only releasing the information about usage of the second > factor via authnContextClassRef if the service (in this case unity), > requested the usage. So the question is, does unity request the usage > of a second factor to the IdP if it is configured? No, however my main point is that I believe there is no option to configure that. Unity recently received dynamic activation of its 2nd factor, it can be triggered taking into account the information on mfa use by upstream IdP, but I believe there is no option to request specific auth context class ref. Best, Krzysztof |
|
From: Sander A. <sa....@fz...> - 2024-08-12 10:06:38
|
Hi Krzysztof, most IdPs are only releasing the information about usage of the second factor via authnContextClassRef if the service (in this case unity), requested the usage. So the question is, does unity request the usage of a second factor to the IdP if it is configured? Best regards, Sander On Mon, 2024-08-12 at 11:35 +0200, Krzysztof Benedyczak wrote: > Hi Sander, > > W dniu 8.08.2024 o 08:11, Sander Apweiler pisze: > > Good morning Krzysztof, > > good morning Roman, > > > > we start testing the dynamic second factor, where unity performs it > > only if it was not performed at the upstream IdP. The IdPs send > > this > > information only if it was requested by the SP. Does unity send > > this > > request, if the dynamic2f flow was performed? > > Can you please specify what request you are wondering about? Meaning > how > SP shall request this information? > > > Best, > Krzysztof > -- Large-Scale Data Science Juelich Supercomputing Centre phone: +49 2461 61 8847 fax: +49 2461 61 6656 email: sa....@fz... ----------------------------------------------------------------------- ----------------------------------------------------------------------- Forschungszentrum Jülich GmbH 52425 Jülich Sitz der Gesellschaft: Jülich Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDir Stefan Müller Geschäftsführung: Prof. Dr. Astrid Lambrecht (Vorsitzende), Karsten Beneke (stellv. Vorsitzender), Prof. Dr. Ir. Pieter Jansens ----------------------------------------------------------------------- ----------------------------------------------------------------------- |
|
From: Krzysztof B. <kb...@un...> - 2024-08-12 09:35:55
|
Hi Sander, W dniu 8.08.2024 o 08:11, Sander Apweiler pisze: > Good morning Krzysztof, > good morning Roman, > > we start testing the dynamic second factor, where unity performs it > only if it was not performed at the upstream IdP. The IdPs send this > information only if it was requested by the SP. Does unity send this > request, if the dynamic2f flow was performed? Can you please specify what request you are wondering about? Meaning how SP shall request this information? Best, Krzysztof |
|
From: Sander A. <sa....@fz...> - 2024-08-08 06:12:09
|
Good morning Krzysztof, good morning Roman, we start testing the dynamic second factor, where unity performs it only if it was not performed at the upstream IdP. The IdPs send this information only if it was requested by the SP. Does unity send this request, if the dynamic2f flow was performed? Best regards, Sander -- Large-Scale Data Science Juelich Supercomputing Centre phone: +49 2461 61 8847 fax: +49 2461 61 6656 email: sa....@fz... ----------------------------------------------------------------------- ----------------------------------------------------------------------- Forschungszentrum Jülich GmbH 52425 Jülich Sitz der Gesellschaft: Jülich Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDir Stefan Müller Geschäftsführung: Prof. Dr. Astrid Lambrecht (Vorsitzende), Karsten Beneke (stellv. Vorsitzender), Prof. Dr. Ir. Pieter Jansens ----------------------------------------------------------------------- ----------------------------------------------------------------------- |
|
From: Sander A. <sa....@fz...> - 2024-08-06 09:47:52
|
Good morning Roman, so far we use the policies only in registration forms, not on the IdP level. Since we startet to use groups which have their own policies and updated the top level, we are using them in enquiries too. So far I do not see any reason for not using the IdP level. Are the information (date/time and Policy version) stored in attributes too? And in ehich file I need to configure the policies? Some other comments to your previous mail are inline. On Tue, 2024-08-06 at 11:18 +0200, Roman Krysiński wrote: > Good morning Sander, > > Last but not least for "the third side effect" you've pointed out - > would it work for you to configure this policy on IdP level? In such > a case it wouldn't be even needed to create enquiries each time > policy revision changes to force users to accept it. > > Best regards, > Roman > > wt., 6 sie 2024 o 11:09 Roman Krysiński <ro...@un...> > napisał(a): > > Good morning Sander, > > > > Let me summarize features around "Policy documents" and I hope that > > will clarify cases you've pointed out in previous email. > > > > Policy documents, that can be defined in "Settings > Policy > > documents" console view, itself do not bring > > enforcement capabilities. > > They can be used in conjunction with registration and enquiry forms > > as well as on IdP level. > > * Used on registration form is useful to enforce a specific policy > > during user creation, and then record this fact in the system (as > > you pointed out in sys:policy-agreement-state attribute) > > * When a policy is used at the IdP level (Vaadin-based IdPs contain > > a “Policy Agreements” tab where this can be configured), the user > > will be required to see and accept the policy after logging into > > such an IdP if the current system policy revision does not match > > the one recorded in the user’s sys:policy-agreement-state > > attribute. > > * Policy document can also be used in enquiry, it will be shown > > there only when current system policy revision does not match the > > one recorded in the user’s sys:policy-agreement-state attribute. In > > other words if the user has already accepted the current policy, > > enquiry will not show it. The fact that the user has completed > > specific enquiry is recorded in sys:FilledEnquires attribute. > > > > Note that changing the policy document revision does not influence > > on the sys:FilledEnquires, so if e.g. user has completed an enquiry > > of "User is requested, mandatory" type, which is configured with a > > policy, that revision has changed, then this enquiry will not be > > enforced once more. This can be done with new enquiry OR by > > configuring this in IdP level. > > > > > We encountered on Monday the situation where we changed the > > > revision of a policy from > > > version 2 to version 3 (no content changes) and the user did not > > > get > > > the update enquiry because they had it already at the update to > > > version 2. > > As mentioned, if a user had an enquiry already completed, revision > > update will not force the user to re-do the enquiry. Ok but the behaviour is not that what I would expect when I have policy management. Could you please add this to the manual. It sounds a bit strange to me that you have an automated update rotine for the first policy revision but not for the later ones. > > > > > We also saw that the update enquiry did not set or update the > > > value > > > of the sys:policy-agreement-state attribute > > Can you confirm that the enquiry request in question was accepted? > > If so, could you please provide more details on how to reproduce > > the problem? Yes. I added a screen shot. I also have some accounts, which has only the sys:FilledEnquieries attribute from the Update enquire but not the sys:policy-agreeement-state. Best regards, Sander > > > > > (...) a new user account, who agreed the latest version during > > > the > > > registration, got an empty enquiry (no checkbox and policy, but > > > on > > > cancel and submit buttons) at the first login > > As noted, the policy is not shown on enquiry form, when the user > > has already accepted it. > > I see your point however that this is not the best user experience, > > and there is room for improvement here. > > We will think about this use case and a better handling. > > > > In addition to the problem reported by Piotr with enquiry we've > > found three more items to address and targeted for the 4.0.1 patch: > > * Enquiry logout does not work > > * Enquiries are not enforced when logging to hope ui > > * Improve the layout of enquiry buttons > > > > Please let me know in case of any further questions. > > > > Best regards, > > Roman > > > > > > śr., 31 lip 2024 o 07:36 Sander Apweiler > > <sa....@fz...> napisał(a): > > > Good morning, > > > > > > the problems we found were based on unity 3.16.1. We encountered > > > on > > > Monday the situation where we changed the revision of a policy > > > from > > > version 2 to version 3 (no content changes) and the user did not > > > get > > > the update enquiry because they had it already at the update to > > > version > > > 2. We also saw that the update enquiry did not set or update the > > > value > > > of the sys:policy-agreement-state attribute. And the third side > > > effect > > > was that a new user account, who agreed the latest version during > > > the > > > registration, got an empty enquiry (no checkbox and policy, but > > > on > > > cancel and submit buttons) at the first login. Our plan was to > > > verify > > > this on unity 4, before we report those issues. > > > > > > Best regards, > > > Sander > > > > > > > > > On Tue, 2024-07-30 at 15:05 +0200, Piotr Piernik wrote: > > > > Dear Sander > > > > Generally If the policy has changed with the revision number > > > > increase, > > > > it should appear to users automatically. > > > > Could you please provide more details in which scenario it > > > > won't > > > > work? > > > > > > > > > > > > > > > > Best regards > > > > Piotr > > > > > > > > W dniu 30.07.2024 o 12:36, Sander Apweiler pisze: > > > > > Dear Piotr, > > > > > nice to hear you found the reason. Can you answer my second > > > > > question as > > > > > well? We found some issues regarding policies in our 3.16.1 > > > > > instances > > > > > and we are not sure if the problems based on our > > > > > misconfiguration > > > > > or > > > > > unity. > > > > > > > > > > Best regards, > > > > > Sander > > > > > > > > > > > > > > > On Tue, 2024-07-30 at 12:20 +0200, Piotr Piernik wrote: > > > > > > > > > > > > Dear Sander > > > > > > We have problem in policy document editor - saves > > > > > > optional > > > > > > policy > > > > > > documents as mandatory and vice versa. > > > > > > We will fix it in 4.0.1 patch. > > > > > > > > > > > > Best regards > > > > > > Piotr > > > > > > > > > > > > > > > > > > > > > > > > W dniu 30.07.2024 o 07:13, Sander Apweiler pisze: > > > > > > > > > > > > > > > > > > > > > > > > > > Good morning Krzysztof, > > > > > > > good morning Roman, > > > > > > > > > > > > > > we found another bug in unity 4. We created a mandatory > > > > > > > policy > > > > > > > (see > > > > > > > 1st > > > > > > > screenshot) and added it to the registration form (see > > > > > > > 2nd > > > > > > > screenshot). > > > > > > > This policy should be mandatory but I can register > > > > > > > without > > > > > > > confirmation > > > > > > > of the policy. > > > > > > > > > > > > > > Another question regarding policies because I do not > > > > > > > remember > > > > > > > and > > > > > > > the > > > > > > > manual is not that clear in this point. When I create a > > > > > > > new > > > > > > > version > > > > > > > of > > > > > > > a policy, is the confirmation of the new version shown to > > > > > > > all > > > > > > > users > > > > > > > or > > > > > > > do I need to create enquieries manually? > > > > > > > > > > > > > > Best regards, > > > > > > > Sander > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > Unity-idm-discuss mailing list > > > > > > > Uni...@li... > > > > > > > https://lists.sourceforge.net/lists/listinfo/unity-idm-discuss > > > > > > > > > > > > > > > > -- Large-Scale Data Science Juelich Supercomputing Centre phone: +49 2461 61 8847 fax: +49 2461 61 6656 email: sa....@fz... ----------------------------------------------------------------------- ----------------------------------------------------------------------- Forschungszentrum Jülich GmbH 52425 Jülich Sitz der Gesellschaft: Jülich Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDir Stefan Müller Geschäftsführung: Prof. Dr. Astrid Lambrecht (Vorsitzende), Karsten Beneke (stellv. Vorsitzender), Prof. Dr. Ir. Pieter Jansens ----------------------------------------------------------------------- ----------------------------------------------------------------------- |
|
From: Roman K. <ro...@un...> - 2024-08-06 09:18:29
|
Good morning Sander, Last but not least for "the third side effect" you've pointed out - would it work for you to configure this policy on IdP level? In such a case it wouldn't be even needed to create enquiries each time policy revision changes to force users to accept it. Best regards, Roman wt., 6 sie 2024 o 11:09 Roman Krysiński <ro...@un...> napisał(a): > Good morning Sander, > > Let me summarize features around "Policy documents" and I hope that will > clarify cases you've pointed out in previous email. > > Policy documents, that can be defined in "Settings > Policy documents" > console view, itself do not bring enforcement capabilities. > They can be used in conjunction with registration and enquiry forms as > well as on IdP level. > * Used on registration form is useful to enforce a specific policy during > user creation, and then record this fact in the system (as you pointed out > in sys:policy-agreement-state attribute) > * When a policy is used at the IdP level (Vaadin-based IdPs contain a > “Policy Agreements” tab where this can be configured), the user will be > required to see and accept the policy after logging into such an IdP if the > current system policy revision does not match the one recorded in the > user’s sys:policy-agreement-state attribute. > * Policy document can also be used in enquiry, it will be shown there only > when current system policy revision does not match the one recorded in the > user’s sys:policy-agreement-state attribute. In other words if the user has > already accepted the current policy, enquiry will not show it. The fact > that the user has completed specific enquiry is recorded > in sys:FilledEnquires attribute. > > Note that changing the policy document revision does not influence on > the sys:FilledEnquires, so if e.g. user has completed an enquiry of "User > is requested, mandatory" type, which is configured with a policy, that > revision has changed, then this enquiry will not be enforced once more. > This can be done with new enquiry OR by configuring this in IdP level. > > > We encountered on Monday the situation where we changed the revision of > a policy from > > version 2 to version 3 (no content changes) and the user did not get > > the update enquiry because they had it already at the update to version > 2. > As mentioned, if a user had an enquiry already completed, revision update > will not force the user to re-do the enquiry. > > > We also saw that the update enquiry did not set or update the value > > of the sys:policy-agreement-state attribute > Can you confirm that the enquiry request in question was accepted? > If so, could you please provide more details on how to reproduce the > problem? > > > (...) a new user account, who agreed the latest version during the > > registration, got an empty enquiry (no checkbox and policy, but on > > cancel and submit buttons) at the first login > As noted, the policy is not shown on enquiry form, when the user has > already accepted it. > I see your point however that this is not the best user experience, and > there is room for improvement here. > We will think about this use case and a better handling. > > In addition to the problem reported by Piotr with enquiry we've found > three more items to address and targeted for the 4.0.1 patch: > * Enquiry logout does not work > * Enquiries are not enforced when logging to hope ui > * Improve the layout of enquiry buttons > > Please let me know in case of any further questions. > > Best regards, > Roman > > > śr., 31 lip 2024 o 07:36 Sander Apweiler <sa....@fz...> > napisał(a): > >> Good morning, >> >> the problems we found were based on unity 3.16.1. We encountered on >> Monday the situation where we changed the revision of a policy from >> version 2 to version 3 (no content changes) and the user did not get >> the update enquiry because they had it already at the update to version >> 2. We also saw that the update enquiry did not set or update the value >> of the sys:policy-agreement-state attribute. And the third side effect >> was that a new user account, who agreed the latest version during the >> registration, got an empty enquiry (no checkbox and policy, but on >> cancel and submit buttons) at the first login. Our plan was to verify >> this on unity 4, before we report those issues. >> >> Best regards, >> Sander >> >> >> On Tue, 2024-07-30 at 15:05 +0200, Piotr Piernik wrote: >> > Dear Sander >> > Generally If the policy has changed with the revision number >> > increase, >> > it should appear to users automatically. >> > Could you please provide more details in which scenario it won't >> > work? >> > >> > >> > >> > Best regards >> > Piotr >> > >> > W dniu 30.07.2024 o 12:36, Sander Apweiler pisze: >> > > Dear Piotr, >> > > nice to hear you found the reason. Can you answer my second >> > > question as >> > > well? We found some issues regarding policies in our 3.16.1 >> > > instances >> > > and we are not sure if the problems based on our misconfiguration >> > > or >> > > unity. >> > > >> > > Best regards, >> > > Sander >> > > >> > > >> > > On Tue, 2024-07-30 at 12:20 +0200, Piotr Piernik wrote: >> > > > >> > > > Dear Sander >> > > > We have problem in policy document editor - saves optional >> > > > policy >> > > > documents as mandatory and vice versa. >> > > > We will fix it in 4.0.1 patch. >> > > > >> > > > Best regards >> > > > Piotr >> > > > >> > > > >> > > > >> > > > W dniu 30.07.2024 o 07:13, Sander Apweiler pisze: >> > > > >> > > > >> > > > > >> > > > > Good morning Krzysztof, >> > > > > good morning Roman, >> > > > > >> > > > > we found another bug in unity 4. We created a mandatory policy >> > > > > (see >> > > > > 1st >> > > > > screenshot) and added it to the registration form (see 2nd >> > > > > screenshot). >> > > > > This policy should be mandatory but I can register without >> > > > > confirmation >> > > > > of the policy. >> > > > > >> > > > > Another question regarding policies because I do not remember >> > > > > and >> > > > > the >> > > > > manual is not that clear in this point. When I create a new >> > > > > version >> > > > > of >> > > > > a policy, is the confirmation of the new version shown to all >> > > > > users >> > > > > or >> > > > > do I need to create enquieries manually? >> > > > > >> > > > > Best regards, >> > > > > Sander >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > _______________________________________________ >> > > > > Unity-idm-discuss mailing list >> > > > > Uni...@li... >> > > > > https://lists.sourceforge.net/lists/listinfo/unity-idm-discuss >> > > > > >> > > > >> >> -- >> Large-Scale Data Science >> Juelich Supercomputing Centre >> >> phone: +49 2461 61 8847 >> fax: +49 2461 61 6656 >> email: sa....@fz... >> >> ----------------------------------------------------------------------- >> ----------------------------------------------------------------------- >> Forschungszentrum Jülich GmbH >> 52425 Jülich >> Sitz der Gesellschaft: Jülich >> Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498 >> Vorsitzender des Aufsichtsrats: MinDir Stefan Müller >> Geschäftsführung: Prof. Dr. Astrid Lambrecht (Vorsitzende), >> Karsten Beneke (stellv. Vorsitzender), Prof. Dr. Ir. Pieter Jansens >> ----------------------------------------------------------------------- >> ----------------------------------------------------------------------- >> >> >> _______________________________________________ >> Unity-idm-discuss mailing list >> Uni...@li... >> https://lists.sourceforge.net/lists/listinfo/unity-idm-discuss >> > |
|
From: Roman K. <ro...@un...> - 2024-08-06 09:10:06
|
Good morning Sander, Let me summarize features around "Policy documents" and I hope that will clarify cases you've pointed out in previous email. Policy documents, that can be defined in "Settings > Policy documents" console view, itself do not bring enforcement capabilities. They can be used in conjunction with registration and enquiry forms as well as on IdP level. * Used on registration form is useful to enforce a specific policy during user creation, and then record this fact in the system (as you pointed out in sys:policy-agreement-state attribute) * When a policy is used at the IdP level (Vaadin-based IdPs contain a “Policy Agreements” tab where this can be configured), the user will be required to see and accept the policy after logging into such an IdP if the current system policy revision does not match the one recorded in the user’s sys:policy-agreement-state attribute. * Policy document can also be used in enquiry, it will be shown there only when current system policy revision does not match the one recorded in the user’s sys:policy-agreement-state attribute. In other words if the user has already accepted the current policy, enquiry will not show it. The fact that the user has completed specific enquiry is recorded in sys:FilledEnquires attribute. Note that changing the policy document revision does not influence on the sys:FilledEnquires, so if e.g. user has completed an enquiry of "User is requested, mandatory" type, which is configured with a policy, that revision has changed, then this enquiry will not be enforced once more. This can be done with new enquiry OR by configuring this in IdP level. > We encountered on Monday the situation where we changed the revision of a policy from > version 2 to version 3 (no content changes) and the user did not get > the update enquiry because they had it already at the update to version 2. As mentioned, if a user had an enquiry already completed, revision update will not force the user to re-do the enquiry. > We also saw that the update enquiry did not set or update the value > of the sys:policy-agreement-state attribute Can you confirm that the enquiry request in question was accepted? If so, could you please provide more details on how to reproduce the problem? > (...) a new user account, who agreed the latest version during the > registration, got an empty enquiry (no checkbox and policy, but on > cancel and submit buttons) at the first login As noted, the policy is not shown on enquiry form, when the user has already accepted it. I see your point however that this is not the best user experience, and there is room for improvement here. We will think about this use case and a better handling. In addition to the problem reported by Piotr with enquiry we've found three more items to address and targeted for the 4.0.1 patch: * Enquiry logout does not work * Enquiries are not enforced when logging to hope ui * Improve the layout of enquiry buttons Please let me know in case of any further questions. Best regards, Roman śr., 31 lip 2024 o 07:36 Sander Apweiler <sa....@fz...> napisał(a): > Good morning, > > the problems we found were based on unity 3.16.1. We encountered on > Monday the situation where we changed the revision of a policy from > version 2 to version 3 (no content changes) and the user did not get > the update enquiry because they had it already at the update to version > 2. We also saw that the update enquiry did not set or update the value > of the sys:policy-agreement-state attribute. And the third side effect > was that a new user account, who agreed the latest version during the > registration, got an empty enquiry (no checkbox and policy, but on > cancel and submit buttons) at the first login. Our plan was to verify > this on unity 4, before we report those issues. > > Best regards, > Sander > > > On Tue, 2024-07-30 at 15:05 +0200, Piotr Piernik wrote: > > Dear Sander > > Generally If the policy has changed with the revision number > > increase, > > it should appear to users automatically. > > Could you please provide more details in which scenario it won't > > work? > > > > > > > > Best regards > > Piotr > > > > W dniu 30.07.2024 o 12:36, Sander Apweiler pisze: > > > Dear Piotr, > > > nice to hear you found the reason. Can you answer my second > > > question as > > > well? We found some issues regarding policies in our 3.16.1 > > > instances > > > and we are not sure if the problems based on our misconfiguration > > > or > > > unity. > > > > > > Best regards, > > > Sander > > > > > > > > > On Tue, 2024-07-30 at 12:20 +0200, Piotr Piernik wrote: > > > > > > > > Dear Sander > > > > We have problem in policy document editor - saves optional > > > > policy > > > > documents as mandatory and vice versa. > > > > We will fix it in 4.0.1 patch. > > > > > > > > Best regards > > > > Piotr > > > > > > > > > > > > > > > > W dniu 30.07.2024 o 07:13, Sander Apweiler pisze: > > > > > > > > > > > > > > > > > > Good morning Krzysztof, > > > > > good morning Roman, > > > > > > > > > > we found another bug in unity 4. We created a mandatory policy > > > > > (see > > > > > 1st > > > > > screenshot) and added it to the registration form (see 2nd > > > > > screenshot). > > > > > This policy should be mandatory but I can register without > > > > > confirmation > > > > > of the policy. > > > > > > > > > > Another question regarding policies because I do not remember > > > > > and > > > > > the > > > > > manual is not that clear in this point. When I create a new > > > > > version > > > > > of > > > > > a policy, is the confirmation of the new version shown to all > > > > > users > > > > > or > > > > > do I need to create enquieries manually? > > > > > > > > > > Best regards, > > > > > Sander > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Unity-idm-discuss mailing list > > > > > Uni...@li... > > > > > https://lists.sourceforge.net/lists/listinfo/unity-idm-discuss > > > > > > > > > > > -- > Large-Scale Data Science > Juelich Supercomputing Centre > > phone: +49 2461 61 8847 > fax: +49 2461 61 6656 > email: sa....@fz... > > ----------------------------------------------------------------------- > ----------------------------------------------------------------------- > Forschungszentrum Jülich GmbH > 52425 Jülich > Sitz der Gesellschaft: Jülich > Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498 > Vorsitzender des Aufsichtsrats: MinDir Stefan Müller > Geschäftsführung: Prof. Dr. Astrid Lambrecht (Vorsitzende), > Karsten Beneke (stellv. Vorsitzender), Prof. Dr. Ir. Pieter Jansens > ----------------------------------------------------------------------- > ----------------------------------------------------------------------- > > > _______________________________________________ > Unity-idm-discuss mailing list > Uni...@li... > https://lists.sourceforge.net/lists/listinfo/unity-idm-discuss > |
|
From: Krzysztof B. <kb...@un...> - 2024-08-01 11:37:25
|
Hi Sander, Thanks for this report - issue related to conflicting 3rd party libs, fix in progress. Best, Krzysztof W dniu 30.07.2024 o 10:26, Sander Apweiler pisze: > Hello again, > > we have also the issue that email notifications are failing on the > server. We use the same config and message templates like in the 3.16.1 > which is working on other servers. > > We got the following stacktrace. Do you have any idea about this? > > 2024-07-30T07:53:11,572 [ForkJoinPool-1-worker-4179] ERROR unity.server.notification.EmailFacility: E-mail notification failed > java.lang.ClassCastException: class com.sun.mail.handlers.text_plain cannot be cast to class javax.activation.DataContentHandler (com.sun.mail.handlers.text_plain and javax.activation.DataContentHandler are in unnamed module of loader 'app') > at javax.activation.MailcapCommandMap.getDataContentHandler(MailcapCommandMap.java:631) ~[javax.activation-api-1.2.0.jar:1.2.0] > at javax.activation.MailcapCommandMap.createDataContentHandler(MailcapCommandMap.java:585) ~[javax.activation-api-1.2.0.jar:1.2.0] > at javax.activation.DataHandler.getDataContentHandler(DataHandler.java:630) ~[javax.activation-api-1.2.0.jar:1.2.0] > at javax.activation.DataHandler.writeTo(DataHandler.java:329) ~[javax.activation-api-1.2.0.jar:1.2.0] > at javax.mail.internet.MimeUtility.getEncoding(MimeUtility.java:340) ~[javax.mail-1.6.2.jar:1.6.2] > at javax.mail.internet.MimeBodyPart.updateHeaders(MimeBodyPart.java:1575) ~[javax.mail-1.6.2.jar:1.6.2] > at javax.mail.internet.MimeMessage.updateHeaders(MimeMessage.java:2271) ~[javax.mail-1.6.2.jar:1.6.2] > at javax.mail.internet.MimeMessage.saveChanges(MimeMessage.java:2231) ~[javax.mail-1.6.2.jar:1.6.2] > at javax.mail.Transport.send(Transport.java:123) ~[javax.mail-1.6.2.jar:1.6.2] > at pl.edu.icm.unity.engine.notifications.email.EmailChannel.sendEmail(EmailChannel.java:110) ~[unity-server-engine-4.0.0.jar:?] > at pl.edu.icm.unity.engine.notifications.email.EmailChannel.lambda$sendNotification$0(EmailChannel.java:92) ~[unity-server-engine-4.0.0.jar:?] > at java.base/java.util.concurrent.ForkJoinTask$AdaptedRunnable.exec(ForkJoinTask.java:1382) [?:?] > at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:387) [?:?] > at java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1312) [?:?] > at java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1843) [?:?] > at java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1808) [?:?] > at java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:188) [?:?] > > The configuration of the message templates is attached. > > Best regards, > Sander > > > > _______________________________________________ > Unity-idm-discuss mailing list > Uni...@li... > https://lists.sourceforge.net/lists/listinfo/unity-idm-discuss |
|
From: Sander A. <sa....@fz...> - 2024-07-31 05:35:58
|
Good morning, the problems we found were based on unity 3.16.1. We encountered on Monday the situation where we changed the revision of a policy from version 2 to version 3 (no content changes) and the user did not get the update enquiry because they had it already at the update to version 2. We also saw that the update enquiry did not set or update the value of the sys:policy-agreement-state attribute. And the third side effect was that a new user account, who agreed the latest version during the registration, got an empty enquiry (no checkbox and policy, but on cancel and submit buttons) at the first login. Our plan was to verify this on unity 4, before we report those issues. Best regards, Sander On Tue, 2024-07-30 at 15:05 +0200, Piotr Piernik wrote: > Dear Sander > Generally If the policy has changed with the revision number > increase, > it should appear to users automatically. > Could you please provide more details in which scenario it won't > work? > > > > Best regards > Piotr > > W dniu 30.07.2024 o 12:36, Sander Apweiler pisze: > > Dear Piotr, > > nice to hear you found the reason. Can you answer my second > > question as > > well? We found some issues regarding policies in our 3.16.1 > > instances > > and we are not sure if the problems based on our misconfiguration > > or > > unity. > > > > Best regards, > > Sander > > > > > > On Tue, 2024-07-30 at 12:20 +0200, Piotr Piernik wrote: > > > > > > Dear Sander > > > We have problem in policy document editor - saves optional > > > policy > > > documents as mandatory and vice versa. > > > We will fix it in 4.0.1 patch. > > > > > > Best regards > > > Piotr > > > > > > > > > > > > W dniu 30.07.2024 o 07:13, Sander Apweiler pisze: > > > > > > > > > > > > > > Good morning Krzysztof, > > > > good morning Roman, > > > > > > > > we found another bug in unity 4. We created a mandatory policy > > > > (see > > > > 1st > > > > screenshot) and added it to the registration form (see 2nd > > > > screenshot). > > > > This policy should be mandatory but I can register without > > > > confirmation > > > > of the policy. > > > > > > > > Another question regarding policies because I do not remember > > > > and > > > > the > > > > manual is not that clear in this point. When I create a new > > > > version > > > > of > > > > a policy, is the confirmation of the new version shown to all > > > > users > > > > or > > > > do I need to create enquieries manually? > > > > > > > > Best regards, > > > > Sander > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Unity-idm-discuss mailing list > > > > Uni...@li... > > > > https://lists.sourceforge.net/lists/listinfo/unity-idm-discuss > > > > > > > -- Large-Scale Data Science Juelich Supercomputing Centre phone: +49 2461 61 8847 fax: +49 2461 61 6656 email: sa....@fz... ----------------------------------------------------------------------- ----------------------------------------------------------------------- Forschungszentrum Jülich GmbH 52425 Jülich Sitz der Gesellschaft: Jülich Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDir Stefan Müller Geschäftsführung: Prof. Dr. Astrid Lambrecht (Vorsitzende), Karsten Beneke (stellv. Vorsitzender), Prof. Dr. Ir. Pieter Jansens ----------------------------------------------------------------------- ----------------------------------------------------------------------- |
|
From: Piotr P. <pio...@gm...> - 2024-07-30 13:05:49
|
Dear Sander Generally If the policy has changed with the revision number increase, it should appear to users automatically. Could you please provide more details in which scenario it won't work? Best regards Piotr W dniu 30.07.2024 o 12:36, Sander Apweiler pisze: > Dear Piotr, > nice to hear you found the reason. Can you answer my second question as > well? We found some issues regarding policies in our 3.16.1 instances > and we are not sure if the problems based on our misconfiguration or > unity. > > Best regards, > Sander > > > On Tue, 2024-07-30 at 12:20 +0200, Piotr Piernik wrote: >> >> Dear Sander >> We have problem in policy document editor - saves optional policy >> documents as mandatory and vice versa. >> We will fix it in 4.0.1 patch. >> >> Best regards >> Piotr >> >> >> >> W dniu 30.07.2024 o 07:13, Sander Apweiler pisze: >> >> >>> >>> Good morning Krzysztof, >>> good morning Roman, >>> >>> we found another bug in unity 4. We created a mandatory policy (see >>> 1st >>> screenshot) and added it to the registration form (see 2nd >>> screenshot). >>> This policy should be mandatory but I can register without >>> confirmation >>> of the policy. >>> >>> Another question regarding policies because I do not remember and >>> the >>> manual is not that clear in this point. When I create a new version >>> of >>> a policy, is the confirmation of the new version shown to all users >>> or >>> do I need to create enquieries manually? >>> >>> Best regards, >>> Sander >>> >>> >>> >>> >>> _______________________________________________ >>> Unity-idm-discuss mailing list >>> Uni...@li... >>> https://lists.sourceforge.net/lists/listinfo/unity-idm-discuss >>> >> |
|
From: Piotr P. <pio...@gm...> - 2024-07-30 11:19:44
|
Dear Sander We are already working on it. Thank you for information. Best regards Piotr W dniu 30.07.2024 o 13:09, Sander Apweiler pisze: > Hello again, > we have another issue with the userhome. We make sure all accounts have > the attributes which should be displayed. But for new created accounts > the profile shows only error, while for old accounts the content is > shown. > > The log shows this stacktrace: > > 2024-07-30T10:58:43,582 [qtp1550177731-229427] DEBUG org.mariadb.jdbc.client.impl.StandardClient: execute query: set autocommit=1 > 2024-07-30T10:58:43,582 [qtp1550177731-229427] DEBUG org.mariadb.jdbc.message.server.OkPacket: System variable change: autocommit = ON > 2024-07-30T10:58:43,582 [qtp1550177731-229427] DEBUG com.vaadin.flow.server.auth.NavigationAccessControl: Checking access for view io.imunity.home.views.HomeErrorPage > 2024-07-30T10:58:43,582 [qtp1550177731-229427] DEBUG com.vaadin.flow.server.auth.AnnotatedViewAccessChecker: Access to view 'io.imunity.home.views.HomeErrorPage' with path '' is allowed > 2024-07-30T10:58:43,582 [qtp1550177731-229427] DEBUG com.vaadin.flow.server.auth.DefaultAccessCheckDecisionResolver: Access to view 'io.imunity.home.views.HomeErrorPage' with path '' allowed by 1 out of 1 navigation checkers (0 neutral). > 2024-07-30T10:58:43,582 [qtp1550177731-229427] DEBUG com.vaadin.flow.server.auth.NavigationAccessControl: Decision against 1 checker results: Access decision: ALLOW > 2024-07-30T10:58:43,582 [qtp1550177731-229427] ERROR unity.server.web.HomeErrorPage: Vaadin rendering error: > java.lang.ClassCastException: class io.imunity.vaadin.endpoint.common.plugins.attributes.ext.LayoutWithIcon cannot be cast to class com.vaadin.flow.component.HasLabel (io.imunity.vaadin.endpoint.common.plugins.attributes.ext.LayoutWithIcon and com.vaadin.flow.component.HasLabel are in unnamed module of loader 'app') > at io.imunity.vaadin.endpoint.common.plugins.attributes.AttributeViewer.lambda$createContents$1(AttributeViewer.java:79) ~[unity-server-vaadin-endpoint-common-4.0.0.jar:?] > at java.base/java.util.Optional.ifPresent(Optional.java:178) ~[?:?] > at io.imunity.vaadin.endpoint.common.plugins.attributes.AttributeViewer.createContents(AttributeViewer.java:79) ~[unity-server-vaadin-endpoint-common-4.0.0.jar:?] > at io.imunity.vaadin.endpoint.common.plugins.attributes.AttributeViewer.generate(AttributeViewer.java:62) ~[unity-server-vaadin-endpoint-common-4.0.0.jar:?] > at io.imunity.vaadin.endpoint.common.plugins.attributes.AttributeViewer.<init>(AttributeViewer.java:39) ~[unity-server-vaadin-endpoint-common-4.0.0.jar:?] > at io.imunity.home.views.profile.ProfileView.getAttributes(ProfileView.java:274) ~[unity-server-user-home-4.0.0.jar:?] > at io.imunity.home.views.profile.ProfileView.getAttributes(ProfileView.java:205) ~[unity-server-user-home-4.0.0.jar:?] > at io.imunity.home.views.profile.ProfileView.init(ProfileView.java:134) ~[unity-server-user-home-4.0.0.jar:?] > at io.imunity.home.views.profile.ProfileView.afterNavigation(ProfileView.java:118) ~[unity-server-user-home-4.0.0.jar:?] > at com.vaadin.flow.router.internal.AbstractNavigationStateRenderer.lambda$fireAfterNavigationListeners$3(AbstractNavigationStateRenderer.java:364) ~[flow-server-24.3.7.jar:24.3.7] > at java.base/java.util.ArrayList.forEach(ArrayList.java:1596) ~[?:?] > at com.vaadin.flow.router.internal.AbstractNavigationStateRenderer.fireAfterNavigationListeners(AbstractNavigationStateRenderer.java:364) ~[flow-server-24.3.7.jar:24.3.7] > at com.vaadin.flow.router.internal.AbstractNavigationStateRenderer.handle(AbstractNavigationStateRenderer.java:243) ~[flow-server-24.3.7.jar:24.3.7] > at com.vaadin.flow.component.internal.JavaScriptNavigationStateRenderer.handle(JavaScriptNavigationStateRenderer.java:78) ~[flow-server-24.3.7.jar:24.3.7] > at com.vaadin.flow.component.UI.handleNavigation(UI.java:1853) ~[flow-server-24.3.7.jar:24.3.7] > at com.vaadin.flow.component.UI.renderViewForRoute(UI.java:1816) ~[flow-server-24.3.7.jar:24.3.7] > at com.vaadin.flow.component.UI.connectClient(UI.java:1729) ~[flow-server-24.3.7.jar:24.3.7] > at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103) ~[?:?] > at java.base/java.lang.reflect.Method.invoke(Method.java:580) ~[?:?] > at com.vaadin.flow.server.communication.rpc.PublishedServerEventHandlerRpcHandler.invokeMethod(PublishedServerEventHandlerRpcHandler.java:227) ~[flow-server-24.3.7.jar:24.3.7] > at com.vaadin.flow.server.communication.rpc.PublishedServerEventHandlerRpcHandler.invokeMethod(PublishedServerEventHandlerRpcHandler.java:204) ~[flow-server-24.3.7.jar:24.3.7] > at com.vaadin.flow.server.communication.rpc.PublishedServerEventHandlerRpcHandler.invokeMethod(PublishedServerEventHandlerRpcHandler.java:150) ~[flow-server-24.3.7.jar:24.3.7] > at com.vaadin.flow.server.communication.rpc.PublishedServerEventHandlerRpcHandler.handleNode(PublishedServerEventHandlerRpcHandler.java:133) ~[flow-server-24.3.7.jar:24.3.7] > at com.vaadin.flow.server.communication.rpc.AbstractRpcInvocationHandler.handle(AbstractRpcInvocationHandler.java:74) ~[flow-server-24.3.7.jar:24.3.7] > at com.vaadin.flow.server.communication.ServerRpcHandler.handleInvocationData(ServerRpcHandler.java:466) ~[flow-server-24.3.7.jar:24.3.7] > at com.vaadin.flow.server.communication.ServerRpcHandler.lambda$handleInvocations$4(ServerRpcHandler.java:447) ~[flow-server-24.3.7.jar:24.3.7] > at java.base/java.util.ArrayList.forEach(ArrayList.java:1596) ~[?:?] > at com.vaadin.flow.server.communication.ServerRpcHandler.handleInvocations(ServerRpcHandler.java:447) ~[flow-server-24.3.7.jar:24.3.7] > at com.vaadin.flow.server.communication.ServerRpcHandler.handleRpc(ServerRpcHandler.java:324) ~[flow-server-24.3.7.jar:24.3.7] > at com.vaadin.flow.server.communication.UidlRequestHandler.synchronizedHandleRequest(UidlRequestHandler.java:114) ~[flow-server-24.3.7.jar:24.3.7] > at com.vaadin.flow.server.SynchronizedRequestHandler.handleRequest(SynchronizedRequestHandler.java:40) ~[flow-server-24.3.7.jar:24.3.7] > at com.vaadin.flow.server.VaadinService.handleRequest(VaadinService.java:1574) ~[flow-server-24.3.7.jar:24.3.7] > at com.vaadin.flow.server.VaadinServlet.service(VaadinServlet.java:398) ~[flow-server-24.3.7.jar:24.3.7] > at jakarta.servlet.http.HttpServlet.service(HttpServlet.java:614) ~[jakarta.servlet-api-6.0.0.jar:6.0.0] > at org.eclipse.jetty.ee10.servlet.ServletHolder.handle(ServletHolder.java:736) ~[jetty-ee10-servlet-12.0.7.jar:12.0.7] > at org.eclipse.jetty.ee10.servlet.ServletHandler$ChainEnd.doFilter(ServletHandler.java:1614) ~[jetty-ee10-servlet-12.0.7.jar:12.0.7] > at io.imunity.vaadin.endpoint.common.InvocationContextSetupFilter.doFilter(InvocationContextSetupFilter.java:67) ~[unity-server-vaadin-endpoint-common-4.0.0.jar:?] > at org.eclipse.jetty.ee10.servlet.FilterHolder.doFilter(FilterHolder.java:205) ~[jetty-ee10-servlet-12.0.7.jar:12.0.7] > at org.eclipse.jetty.ee10.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1586) ~[jetty-ee10-servlet-12.0.7.jar:12.0.7] > at io.imunity.vaadin.auth.server.ProxyAuthenticationFilter.doFilter(ProxyAuthenticationFilter.java:113) ~[unity-server-vaadin-authentication-4.0.0.jar:?] > at org.eclipse.jetty.ee10.servlet.FilterHolder.doFilter(FilterHolder.java:205) ~[jetty-ee10-servlet-12.0.7.jar:12.0.7] > at org.eclipse.jetty.ee10.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1586) ~[jetty-ee10-servlet-12.0.7.jar:12.0.7] > at io.imunity.vaadin.auth.server.AuthenticationFilter.gotoProtectedResource(AuthenticationFilter.java:300) ~[unity-server-vaadin-authentication-4.0.0.jar:?] > at io.imunity.vaadin.auth.server.AuthenticationFilter.handleBoundSession(AuthenticationFilter.java:171) ~[unity-server-vaadin-authentication-4.0.0.jar:?] > at io.imunity.vaadin.auth.server.AuthenticationFilter.doFilter(AuthenticationFilter.java:97) ~[unity-server-vaadin-authentication-4.0.0.jar:?] > at org.eclipse.jetty.ee10.servlet.FilterHolder.doFilter(FilterHolder.java:205) ~[jetty-ee10-servlet-12.0.7.jar:12.0.7] > at org.eclipse.jetty.ee10.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1586) ~[jetty-ee10-servlet-12.0.7.jar:12.0.7] > at io.imunity.vaadin.endpoint.common.RemoteRedirectedAuthnResponseProcessingFilter.doFilter(RemoteRedirectedAuthnResponseProcessingFilter.java:48) ~[unity-server-vaadin-endpoint-common-4.0.0.jar:?] > at org.eclipse.jetty.ee10.servlet.FilterHolder.doFilter(FilterHolder.java:205) ~[jetty-ee10-servlet-12.0.7.jar:12.0.7] > at org.eclipse.jetty.ee10.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1586) ~[jetty-ee10-servlet-12.0.7.jar:12.0.7] > at org.eclipse.jetty.ee10.servlet.ServletHandler$MappedServlet.handle(ServletHandler.java:1547) ~[jetty-ee10-servlet-12.0.7.jar:12.0.7] > at org.eclipse.jetty.ee10.servlet.ServletChannel.dispatch(ServletChannel.java:814) ~[jetty-ee10-servlet-12.0.7.jar:12.0.7] > at org.eclipse.jetty.ee10.servlet.ServletChannel.handle(ServletChannel.java:431) ~[jetty-ee10-servlet-12.0.7.jar:12.0.7] > at org.eclipse.jetty.ee10.servlet.ServletHandler.handle(ServletHandler.java:464) ~[jetty-ee10-servlet-12.0.7.jar:12.0.7] > at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:571) ~[jetty-security-12.0.7.jar:12.0.7] > at org.eclipse.jetty.ee10.servlet.SessionHandler.handle(SessionHandler.java:703) ~[jetty-ee10-servlet-12.0.7.jar:12.0.7] > at org.eclipse.jetty.server.handler.ContextHandler.handle(ContextHandler.java:765) ~[jetty-server-12.0.7.jar:12.0.7] > at pl.edu.icm.unity.engine.server.ClientIPSettingHandler.handle(ClientIPSettingHandler.java:67) ~[unity-server-engine-4.0.0.jar:?] > at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:181) ~[jetty-server-12.0.7.jar:12.0.7] > at org.eclipse.jetty.rewrite.handler.RewriteHandler$LastRuleHandler.handle(RewriteHandler.java:159) ~[jetty-rewrite-12.0.7.jar:12.0.7] > at org.eclipse.jetty.rewrite.handler.Rule$Handler.handle(Rule.java:108) ~[jetty-rewrite-12.0.7.jar:12.0.7] > at org.eclipse.jetty.rewrite.handler.HeaderPatternRule$1.handle(HeaderPatternRule.java:89) ~[jetty-rewrite-12.0.7.jar:12.0.7] > at org.eclipse.jetty.rewrite.handler.Rule$Handler.handle(Rule.java:108) ~[jetty-rewrite-12.0.7.jar:12.0.7] > at org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:143) ~[jetty-rewrite-12.0.7.jar:12.0.7] > at org.eclipse.jetty.rewrite.handler.RewriteHandler$LastRuleHandler.handle(RewriteHandler.java:159) ~[jetty-rewrite-12.0.7.jar:12.0.7] > at org.eclipse.jetty.rewrite.handler.Rule$Handler.handle(Rule.java:108) ~[jetty-rewrite-12.0.7.jar:12.0.7] > at org.eclipse.jetty.rewrite.handler.HeaderPatternRule$1.handle(HeaderPatternRule.java:89) ~[jetty-rewrite-12.0.7.jar:12.0.7] > at org.eclipse.jetty.rewrite.handler.Rule$Handler.handle(Rule.java:108) ~[jetty-rewrite-12.0.7.jar:12.0.7] > at org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:143) ~[jetty-rewrite-12.0.7.jar:12.0.7] > at org.eclipse.jetty.server.handler.gzip.GzipHandler.handle(GzipHandler.java:597) ~[jetty-server-12.0.7.jar:12.0.7] > at org.eclipse.jetty.server.Handler$Wrapper.handle(Handler.java:716) ~[jetty-server-12.0.7.jar:12.0.7] > at pl.edu.icm.unity.engine.server.TraceBlockingHandler.handle(TraceBlockingHandler.java:34) ~[unity-server-engine-4.0.0.jar:?] > at org.eclipse.jetty.server.Server.handle(Server.java:179) ~[jetty-server-12.0.7.jar:12.0.7] > at org.eclipse.jetty.server.internal.HttpChannelState$HandlerInvoker.run(HttpChannelState.java:619) ~[jetty-server-12.0.7.jar:12.0.7] > at org.eclipse.jetty.server.internal.HttpConnection.onFillable(HttpConnection.java:411) ~[jetty-server-12.0.7.jar:12.0.7] > at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:322) ~[jetty-io-12.0.7.jar:12.0.7] > at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:99) ~[jetty-io-12.0.7.jar:12.0.7] > at org.eclipse.jetty.io.ssl.SslConnection$SslEndPoint.onFillable(SslConnection.java:574) ~[jetty-io-12.0.7.jar:12.0.7] > at org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:390) ~[jetty-io-12.0.7.jar:12.0.7] > at org.eclipse.jetty.io.ssl.SslConnection$2.succeeded(SslConnection.java:150) ~[jetty-io-12.0.7.jar:12.0.7] > at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:99) ~[jetty-io-12.0.7.jar:12.0.7] > at org.eclipse.jetty.io.SelectableChannelEndPoint$1.run(SelectableChannelEndPoint.java:53) ~[jetty-io-12.0.7.jar:12.0.7] > at org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.runTask(AdaptiveExecutionStrategy.java:478) ~[jetty-util-12.0.7.jar:12.0.7] > at org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.consumeTask(AdaptiveExecutionStrategy.java:441) ~[jetty-util-12.0.7.jar:12.0.7] > at org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.tryProduce(AdaptiveExecutionStrategy.java:293) ~[jetty-util-12.0.7.jar:12.0.7] > at org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.run(AdaptiveExecutionStrategy.java:201) ~[jetty-util-12.0.7.jar:12.0.7] > at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:410) ~[jetty-util-12.0.7.jar:12.0.7] > at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:971) ~[jetty-util-12.0.7.jar:12.0.7] > at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.doRunJob(QueuedThreadPool.java:1201) ~[jetty-util-12.0.7.jar:12.0.7] > at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:1156) ~[jetty-util-12.0.7.jar:12.0.7] > at java.base/java.lang.Thread.run(Thread.java:1583) [?:?] > > > Best regards, > Sander > > > > > _______________________________________________ > Unity-idm-discuss mailing list > Uni...@li... > https://lists.sourceforge.net/lists/listinfo/unity-idm-discuss |
|
From: Sander A. <sa....@fz...> - 2024-07-30 11:09:56
|
Hello again,
we have another issue with the userhome. We make sure all accounts have
the attributes which should be displayed. But for new created accounts
the profile shows only error, while for old accounts the content is
shown.
The log shows this stacktrace:
2024-07-30T10:58:43,582 [qtp1550177731-229427] DEBUG org.mariadb.jdbc.client.impl.StandardClient: execute query: set autocommit=1
2024-07-30T10:58:43,582 [qtp1550177731-229427] DEBUG org.mariadb.jdbc.message.server.OkPacket: System variable change: autocommit = ON
2024-07-30T10:58:43,582 [qtp1550177731-229427] DEBUG com.vaadin.flow.server.auth.NavigationAccessControl: Checking access for view io.imunity.home.views.HomeErrorPage
2024-07-30T10:58:43,582 [qtp1550177731-229427] DEBUG com.vaadin.flow.server.auth.AnnotatedViewAccessChecker: Access to view 'io.imunity.home.views.HomeErrorPage' with path '' is allowed
2024-07-30T10:58:43,582 [qtp1550177731-229427] DEBUG com.vaadin.flow.server.auth.DefaultAccessCheckDecisionResolver: Access to view 'io.imunity.home.views.HomeErrorPage' with path '' allowed by 1 out of 1 navigation checkers (0 neutral).
2024-07-30T10:58:43,582 [qtp1550177731-229427] DEBUG com.vaadin.flow.server.auth.NavigationAccessControl: Decision against 1 checker results: Access decision: ALLOW
2024-07-30T10:58:43,582 [qtp1550177731-229427] ERROR unity.server.web.HomeErrorPage: Vaadin rendering error:
java.lang.ClassCastException: class io.imunity.vaadin.endpoint.common.plugins.attributes.ext.LayoutWithIcon cannot be cast to class com.vaadin.flow.component.HasLabel (io.imunity.vaadin.endpoint.common.plugins.attributes.ext.LayoutWithIcon and com.vaadin.flow.component.HasLabel are in unnamed module of loader 'app')
at io.imunity.vaadin.endpoint.common.plugins.attributes.AttributeViewer.lambda$createContents$1(AttributeViewer.java:79) ~[unity-server-vaadin-endpoint-common-4.0.0.jar:?]
at java.base/java.util.Optional.ifPresent(Optional.java:178) ~[?:?]
at io.imunity.vaadin.endpoint.common.plugins.attributes.AttributeViewer.createContents(AttributeViewer.java:79) ~[unity-server-vaadin-endpoint-common-4.0.0.jar:?]
at io.imunity.vaadin.endpoint.common.plugins.attributes.AttributeViewer.generate(AttributeViewer.java:62) ~[unity-server-vaadin-endpoint-common-4.0.0.jar:?]
at io.imunity.vaadin.endpoint.common.plugins.attributes.AttributeViewer.<init>(AttributeViewer.java:39) ~[unity-server-vaadin-endpoint-common-4.0.0.jar:?]
at io.imunity.home.views.profile.ProfileView.getAttributes(ProfileView.java:274) ~[unity-server-user-home-4.0.0.jar:?]
at io.imunity.home.views.profile.ProfileView.getAttributes(ProfileView.java:205) ~[unity-server-user-home-4.0.0.jar:?]
at io.imunity.home.views.profile.ProfileView.init(ProfileView.java:134) ~[unity-server-user-home-4.0.0.jar:?]
at io.imunity.home.views.profile.ProfileView.afterNavigation(ProfileView.java:118) ~[unity-server-user-home-4.0.0.jar:?]
at com.vaadin.flow.router.internal.AbstractNavigationStateRenderer.lambda$fireAfterNavigationListeners$3(AbstractNavigationStateRenderer.java:364) ~[flow-server-24.3.7.jar:24.3.7]
at java.base/java.util.ArrayList.forEach(ArrayList.java:1596) ~[?:?]
at com.vaadin.flow.router.internal.AbstractNavigationStateRenderer.fireAfterNavigationListeners(AbstractNavigationStateRenderer.java:364) ~[flow-server-24.3.7.jar:24.3.7]
at com.vaadin.flow.router.internal.AbstractNavigationStateRenderer.handle(AbstractNavigationStateRenderer.java:243) ~[flow-server-24.3.7.jar:24.3.7]
at com.vaadin.flow.component.internal.JavaScriptNavigationStateRenderer.handle(JavaScriptNavigationStateRenderer.java:78) ~[flow-server-24.3.7.jar:24.3.7]
at com.vaadin.flow.component.UI.handleNavigation(UI.java:1853) ~[flow-server-24.3.7.jar:24.3.7]
at com.vaadin.flow.component.UI.renderViewForRoute(UI.java:1816) ~[flow-server-24.3.7.jar:24.3.7]
at com.vaadin.flow.component.UI.connectClient(UI.java:1729) ~[flow-server-24.3.7.jar:24.3.7]
at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103) ~[?:?]
at java.base/java.lang.reflect.Method.invoke(Method.java:580) ~[?:?]
at com.vaadin.flow.server.communication.rpc.PublishedServerEventHandlerRpcHandler.invokeMethod(PublishedServerEventHandlerRpcHandler.java:227) ~[flow-server-24.3.7.jar:24.3.7]
at com.vaadin.flow.server.communication.rpc.PublishedServerEventHandlerRpcHandler.invokeMethod(PublishedServerEventHandlerRpcHandler.java:204) ~[flow-server-24.3.7.jar:24.3.7]
at com.vaadin.flow.server.communication.rpc.PublishedServerEventHandlerRpcHandler.invokeMethod(PublishedServerEventHandlerRpcHandler.java:150) ~[flow-server-24.3.7.jar:24.3.7]
at com.vaadin.flow.server.communication.rpc.PublishedServerEventHandlerRpcHandler.handleNode(PublishedServerEventHandlerRpcHandler.java:133) ~[flow-server-24.3.7.jar:24.3.7]
at com.vaadin.flow.server.communication.rpc.AbstractRpcInvocationHandler.handle(AbstractRpcInvocationHandler.java:74) ~[flow-server-24.3.7.jar:24.3.7]
at com.vaadin.flow.server.communication.ServerRpcHandler.handleInvocationData(ServerRpcHandler.java:466) ~[flow-server-24.3.7.jar:24.3.7]
at com.vaadin.flow.server.communication.ServerRpcHandler.lambda$handleInvocations$4(ServerRpcHandler.java:447) ~[flow-server-24.3.7.jar:24.3.7]
at java.base/java.util.ArrayList.forEach(ArrayList.java:1596) ~[?:?]
at com.vaadin.flow.server.communication.ServerRpcHandler.handleInvocations(ServerRpcHandler.java:447) ~[flow-server-24.3.7.jar:24.3.7]
at com.vaadin.flow.server.communication.ServerRpcHandler.handleRpc(ServerRpcHandler.java:324) ~[flow-server-24.3.7.jar:24.3.7]
at com.vaadin.flow.server.communication.UidlRequestHandler.synchronizedHandleRequest(UidlRequestHandler.java:114) ~[flow-server-24.3.7.jar:24.3.7]
at com.vaadin.flow.server.SynchronizedRequestHandler.handleRequest(SynchronizedRequestHandler.java:40) ~[flow-server-24.3.7.jar:24.3.7]
at com.vaadin.flow.server.VaadinService.handleRequest(VaadinService.java:1574) ~[flow-server-24.3.7.jar:24.3.7]
at com.vaadin.flow.server.VaadinServlet.service(VaadinServlet.java:398) ~[flow-server-24.3.7.jar:24.3.7]
at jakarta.servlet.http.HttpServlet.service(HttpServlet.java:614) ~[jakarta.servlet-api-6.0.0.jar:6.0.0]
at org.eclipse.jetty.ee10.servlet.ServletHolder.handle(ServletHolder.java:736) ~[jetty-ee10-servlet-12.0.7.jar:12.0.7]
at org.eclipse.jetty.ee10.servlet.ServletHandler$ChainEnd.doFilter(ServletHandler.java:1614) ~[jetty-ee10-servlet-12.0.7.jar:12.0.7]
at io.imunity.vaadin.endpoint.common.InvocationContextSetupFilter.doFilter(InvocationContextSetupFilter.java:67) ~[unity-server-vaadin-endpoint-common-4.0.0.jar:?]
at org.eclipse.jetty.ee10.servlet.FilterHolder.doFilter(FilterHolder.java:205) ~[jetty-ee10-servlet-12.0.7.jar:12.0.7]
at org.eclipse.jetty.ee10.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1586) ~[jetty-ee10-servlet-12.0.7.jar:12.0.7]
at io.imunity.vaadin.auth.server.ProxyAuthenticationFilter.doFilter(ProxyAuthenticationFilter.java:113) ~[unity-server-vaadin-authentication-4.0.0.jar:?]
at org.eclipse.jetty.ee10.servlet.FilterHolder.doFilter(FilterHolder.java:205) ~[jetty-ee10-servlet-12.0.7.jar:12.0.7]
at org.eclipse.jetty.ee10.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1586) ~[jetty-ee10-servlet-12.0.7.jar:12.0.7]
at io.imunity.vaadin.auth.server.AuthenticationFilter.gotoProtectedResource(AuthenticationFilter.java:300) ~[unity-server-vaadin-authentication-4.0.0.jar:?]
at io.imunity.vaadin.auth.server.AuthenticationFilter.handleBoundSession(AuthenticationFilter.java:171) ~[unity-server-vaadin-authentication-4.0.0.jar:?]
at io.imunity.vaadin.auth.server.AuthenticationFilter.doFilter(AuthenticationFilter.java:97) ~[unity-server-vaadin-authentication-4.0.0.jar:?]
at org.eclipse.jetty.ee10.servlet.FilterHolder.doFilter(FilterHolder.java:205) ~[jetty-ee10-servlet-12.0.7.jar:12.0.7]
at org.eclipse.jetty.ee10.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1586) ~[jetty-ee10-servlet-12.0.7.jar:12.0.7]
at io.imunity.vaadin.endpoint.common.RemoteRedirectedAuthnResponseProcessingFilter.doFilter(RemoteRedirectedAuthnResponseProcessingFilter.java:48) ~[unity-server-vaadin-endpoint-common-4.0.0.jar:?]
at org.eclipse.jetty.ee10.servlet.FilterHolder.doFilter(FilterHolder.java:205) ~[jetty-ee10-servlet-12.0.7.jar:12.0.7]
at org.eclipse.jetty.ee10.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1586) ~[jetty-ee10-servlet-12.0.7.jar:12.0.7]
at org.eclipse.jetty.ee10.servlet.ServletHandler$MappedServlet.handle(ServletHandler.java:1547) ~[jetty-ee10-servlet-12.0.7.jar:12.0.7]
at org.eclipse.jetty.ee10.servlet.ServletChannel.dispatch(ServletChannel.java:814) ~[jetty-ee10-servlet-12.0.7.jar:12.0.7]
at org.eclipse.jetty.ee10.servlet.ServletChannel.handle(ServletChannel.java:431) ~[jetty-ee10-servlet-12.0.7.jar:12.0.7]
at org.eclipse.jetty.ee10.servlet.ServletHandler.handle(ServletHandler.java:464) ~[jetty-ee10-servlet-12.0.7.jar:12.0.7]
at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:571) ~[jetty-security-12.0.7.jar:12.0.7]
at org.eclipse.jetty.ee10.servlet.SessionHandler.handle(SessionHandler.java:703) ~[jetty-ee10-servlet-12.0.7.jar:12.0.7]
at org.eclipse.jetty.server.handler.ContextHandler.handle(ContextHandler.java:765) ~[jetty-server-12.0.7.jar:12.0.7]
at pl.edu.icm.unity.engine.server.ClientIPSettingHandler.handle(ClientIPSettingHandler.java:67) ~[unity-server-engine-4.0.0.jar:?]
at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:181) ~[jetty-server-12.0.7.jar:12.0.7]
at org.eclipse.jetty.rewrite.handler.RewriteHandler$LastRuleHandler.handle(RewriteHandler.java:159) ~[jetty-rewrite-12.0.7.jar:12.0.7]
at org.eclipse.jetty.rewrite.handler.Rule$Handler.handle(Rule.java:108) ~[jetty-rewrite-12.0.7.jar:12.0.7]
at org.eclipse.jetty.rewrite.handler.HeaderPatternRule$1.handle(HeaderPatternRule.java:89) ~[jetty-rewrite-12.0.7.jar:12.0.7]
at org.eclipse.jetty.rewrite.handler.Rule$Handler.handle(Rule.java:108) ~[jetty-rewrite-12.0.7.jar:12.0.7]
at org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:143) ~[jetty-rewrite-12.0.7.jar:12.0.7]
at org.eclipse.jetty.rewrite.handler.RewriteHandler$LastRuleHandler.handle(RewriteHandler.java:159) ~[jetty-rewrite-12.0.7.jar:12.0.7]
at org.eclipse.jetty.rewrite.handler.Rule$Handler.handle(Rule.java:108) ~[jetty-rewrite-12.0.7.jar:12.0.7]
at org.eclipse.jetty.rewrite.handler.HeaderPatternRule$1.handle(HeaderPatternRule.java:89) ~[jetty-rewrite-12.0.7.jar:12.0.7]
at org.eclipse.jetty.rewrite.handler.Rule$Handler.handle(Rule.java:108) ~[jetty-rewrite-12.0.7.jar:12.0.7]
at org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:143) ~[jetty-rewrite-12.0.7.jar:12.0.7]
at org.eclipse.jetty.server.handler.gzip.GzipHandler.handle(GzipHandler.java:597) ~[jetty-server-12.0.7.jar:12.0.7]
at org.eclipse.jetty.server.Handler$Wrapper.handle(Handler.java:716) ~[jetty-server-12.0.7.jar:12.0.7]
at pl.edu.icm.unity.engine.server.TraceBlockingHandler.handle(TraceBlockingHandler.java:34) ~[unity-server-engine-4.0.0.jar:?]
at org.eclipse.jetty.server.Server.handle(Server.java:179) ~[jetty-server-12.0.7.jar:12.0.7]
at org.eclipse.jetty.server.internal.HttpChannelState$HandlerInvoker.run(HttpChannelState.java:619) ~[jetty-server-12.0.7.jar:12.0.7]
at org.eclipse.jetty.server.internal.HttpConnection.onFillable(HttpConnection.java:411) ~[jetty-server-12.0.7.jar:12.0.7]
at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:322) ~[jetty-io-12.0.7.jar:12.0.7]
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:99) ~[jetty-io-12.0.7.jar:12.0.7]
at org.eclipse.jetty.io.ssl.SslConnection$SslEndPoint.onFillable(SslConnection.java:574) ~[jetty-io-12.0.7.jar:12.0.7]
at org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:390) ~[jetty-io-12.0.7.jar:12.0.7]
at org.eclipse.jetty.io.ssl.SslConnection$2.succeeded(SslConnection.java:150) ~[jetty-io-12.0.7.jar:12.0.7]
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:99) ~[jetty-io-12.0.7.jar:12.0.7]
at org.eclipse.jetty.io.SelectableChannelEndPoint$1.run(SelectableChannelEndPoint.java:53) ~[jetty-io-12.0.7.jar:12.0.7]
at org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.runTask(AdaptiveExecutionStrategy.java:478) ~[jetty-util-12.0.7.jar:12.0.7]
at org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.consumeTask(AdaptiveExecutionStrategy.java:441) ~[jetty-util-12.0.7.jar:12.0.7]
at org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.tryProduce(AdaptiveExecutionStrategy.java:293) ~[jetty-util-12.0.7.jar:12.0.7]
at org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.run(AdaptiveExecutionStrategy.java:201) ~[jetty-util-12.0.7.jar:12.0.7]
at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:410) ~[jetty-util-12.0.7.jar:12.0.7]
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:971) ~[jetty-util-12.0.7.jar:12.0.7]
at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.doRunJob(QueuedThreadPool.java:1201) ~[jetty-util-12.0.7.jar:12.0.7]
at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:1156) ~[jetty-util-12.0.7.jar:12.0.7]
at java.base/java.lang.Thread.run(Thread.java:1583) [?:?]
Best regards,
Sander
--
Large-Scale Data Science
Juelich Supercomputing Centre
phone: +49 2461 61 8847
fax: +49 2461 61 6656
email: sa....@fz...
-----------------------------------------------------------------------
-----------------------------------------------------------------------
Forschungszentrum Jülich GmbH
52425 Jülich
Sitz der Gesellschaft: Jülich
Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Stefan Müller
Geschäftsführung: Prof. Dr. Astrid Lambrecht (Vorsitzende),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr. Ir. Pieter Jansens
-----------------------------------------------------------------------
-----------------------------------------------------------------------
|
|
From: Sander A. <sa....@fz...> - 2024-07-30 10:36:35
|
Dear Piotr, nice to hear you found the reason. Can you answer my second question as well? We found some issues regarding policies in our 3.16.1 instances and we are not sure if the problems based on our misconfiguration or unity. Best regards, Sander On Tue, 2024-07-30 at 12:20 +0200, Piotr Piernik wrote: > > Dear Sander > We have problem in policy document editor - saves optional policy > documents as mandatory and vice versa. > We will fix it in 4.0.1 patch. > > Best regards > Piotr > > > > W dniu 30.07.2024 o 07:13, Sander Apweiler pisze: > > > > > > Good morning Krzysztof, > > good morning Roman, > > > > we found another bug in unity 4. We created a mandatory policy (see > > 1st > > screenshot) and added it to the registration form (see 2nd > > screenshot). > > This policy should be mandatory but I can register without > > confirmation > > of the policy. > > > > Another question regarding policies because I do not remember and > > the > > manual is not that clear in this point. When I create a new version > > of > > a policy, is the confirmation of the new version shown to all users > > or > > do I need to create enquieries manually? > > > > Best regards, > > Sander > > > > > > > > > > _______________________________________________ > > Unity-idm-discuss mailing list > > Uni...@li... > > https://lists.sourceforge.net/lists/listinfo/unity-idm-discuss > > > -- Large-Scale Data Science Juelich Supercomputing Centre phone: +49 2461 61 8847 fax: +49 2461 61 6656 email: sa....@fz... ----------------------------------------------------------------------- ----------------------------------------------------------------------- Forschungszentrum Jülich GmbH 52425 Jülich Sitz der Gesellschaft: Jülich Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDir Stefan Müller Geschäftsführung: Prof. Dr. Astrid Lambrecht (Vorsitzende), Karsten Beneke (stellv. Vorsitzender), Prof. Dr. Ir. Pieter Jansens ----------------------------------------------------------------------- ----------------------------------------------------------------------- |
|
From: Piotr P. <pio...@gm...> - 2024-07-30 10:20:57
|
Dear Sander We have problem in policy document editor - saves optional policy documents as mandatory and vice versa. We will fix it in 4.0.1 patch. Best regards Piotr W dniu 30.07.2024 o 07:13, Sander Apweiler pisze: > Good morning Krzysztof, > good morning Roman, > > we found another bug in unity 4. We created a mandatory policy (see 1st > screenshot) and added it to the registration form (see 2nd screenshot). > This policy should be mandatory but I can register without confirmation > of the policy. > > Another question regarding policies because I do not remember and the > manual is not that clear in this point. When I create a new version of > a policy, is the confirmation of the new version shown to all users or > do I need to create enquieries manually? > > Best regards, > Sander > > > > _______________________________________________ > Unity-idm-discuss mailing list > Uni...@li... > https://lists.sourceforge.net/lists/listinfo/unity-idm-discuss |
|
From: Sander A. <sa....@fz...> - 2024-07-30 08:26:51
|
Hello again,
we have also the issue that email notifications are failing on the
server. We use the same config and message templates like in the 3.16.1
which is working on other servers.
We got the following stacktrace. Do you have any idea about this?
2024-07-30T07:53:11,572 [ForkJoinPool-1-worker-4179] ERROR unity.server.notification.EmailFacility: E-mail notification failed
java.lang.ClassCastException: class com.sun.mail.handlers.text_plain cannot be cast to class javax.activation.DataContentHandler (com.sun.mail.handlers.text_plain and javax.activation.DataContentHandler are in unnamed module of loader 'app')
at javax.activation.MailcapCommandMap.getDataContentHandler(MailcapCommandMap.java:631) ~[javax.activation-api-1.2.0.jar:1.2.0]
at javax.activation.MailcapCommandMap.createDataContentHandler(MailcapCommandMap.java:585) ~[javax.activation-api-1.2.0.jar:1.2.0]
at javax.activation.DataHandler.getDataContentHandler(DataHandler.java:630) ~[javax.activation-api-1.2.0.jar:1.2.0]
at javax.activation.DataHandler.writeTo(DataHandler.java:329) ~[javax.activation-api-1.2.0.jar:1.2.0]
at javax.mail.internet.MimeUtility.getEncoding(MimeUtility.java:340) ~[javax.mail-1.6.2.jar:1.6.2]
at javax.mail.internet.MimeBodyPart.updateHeaders(MimeBodyPart.java:1575) ~[javax.mail-1.6.2.jar:1.6.2]
at javax.mail.internet.MimeMessage.updateHeaders(MimeMessage.java:2271) ~[javax.mail-1.6.2.jar:1.6.2]
at javax.mail.internet.MimeMessage.saveChanges(MimeMessage.java:2231) ~[javax.mail-1.6.2.jar:1.6.2]
at javax.mail.Transport.send(Transport.java:123) ~[javax.mail-1.6.2.jar:1.6.2]
at pl.edu.icm.unity.engine.notifications.email.EmailChannel.sendEmail(EmailChannel.java:110) ~[unity-server-engine-4.0.0.jar:?]
at pl.edu.icm.unity.engine.notifications.email.EmailChannel.lambda$sendNotification$0(EmailChannel.java:92) ~[unity-server-engine-4.0.0.jar:?]
at java.base/java.util.concurrent.ForkJoinTask$AdaptedRunnable.exec(ForkJoinTask.java:1382) [?:?]
at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:387) [?:?]
at java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1312) [?:?]
at java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1843) [?:?]
at java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1808) [?:?]
at java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:188) [?:?]
The configuration of the message templates is attached.
Best regards,
Sander
--
Large-Scale Data Science
Juelich Supercomputing Centre
phone: +49 2461 61 8847
fax: +49 2461 61 6656
email: sa....@fz...
-----------------------------------------------------------------------
-----------------------------------------------------------------------
Forschungszentrum Jülich GmbH
52425 Jülich
Sitz der Gesellschaft: Jülich
Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Stefan Müller
Geschäftsführung: Prof. Dr. Astrid Lambrecht (Vorsitzende),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr. Ir. Pieter Jansens
-----------------------------------------------------------------------
-----------------------------------------------------------------------
|
|
From: Piotr P. <pio...@gm...> - 2024-07-30 07:24:54
|
Dear Sander I managed reproduce this problem. NPE occurs only when you have not saved "Exposed Attribute" (editor is open) and you click save/update service. We will fix it in 4.0.1 patch. Best regards Piotr W dniu 30.07.2024 o 08:10, Sander Apweiler pisze: > Good morning Roman, > I guess you mean this one: > > 2024-07-30T06:08:37,314 [qtp1550177731-224594] ERROR unity.server.web.CustomErrorPageInitializer: Vaadin initialization error: > java.lang.NullPointerException: null > at java.base/java.util.concurrent.ConcurrentHashMap.putVal(ConcurrentHashMap.java:1011) ~[?:?] > at java.base/java.util.concurrent.ConcurrentHashMap.put(ConcurrentHashMap.java:1006) ~[?:?] > at java.base/java.util.Properties.put(Properties.java:1346) ~[?:?] > at io.imunity.home.console.HomeServiceConfiguration.toProperties(HomeServiceConfiguration.java:74) ~[unity-server-user-home-4.0.0.jar:?] > at io.imunity.home.console.HomeServiceEditorComponent.getServiceDefiniton(HomeServiceEditorComponent.java:98) ~[unity-server-user-home-4.0.0.jar:?] > at io.imunity.home.console.HomeServiceEditor.getEndpointDefiniton(HomeServiceEditor.java:97) ~[unity-server-user-home-4.0.0.jar:?] > at io.imunity.console.views.services.base.MainServiceEditor.getService(MainServiceEditor.java:154) ~[unity-server-console-4.0.0.jar:?] > at io.imunity.console.views.services.base.NewServiceViewBase.onConfirm(NewServiceViewBase.java:89) ~[unity-server-console-4.0.0.jar:?] > at io.imunity.console.views.EditViewActionLayoutFactory.lambda$createActionLayout$8a6d8b6f$1(EditViewActionLayoutFactory.java:25) ~[unity-server-console-4.0.0.jar:?] > at com.vaadin.flow.component.ComponentEventBus.fireEventForListener(ComponentEventBus.java:239) ~[flow-server-24.3.7.jar:24.3.7] > at com.vaadin.flow.component.ComponentEventBus.handleDomEvent(ComponentEventBus.java:488) ~[flow-server-24.3.7.jar:24.3.7] > at com.vaadin.flow.component.ComponentEventBus.lambda$addDomTrigger$dd1b7957$1(ComponentEventBus.java:298) ~[flow-server-24.3.7.jar:24.3.7] > at com.vaadin.flow.internal.nodefeature.ElementListenerMap.lambda$fireEvent$2(ElementListenerMap.java:447) ~[flow-server-24.3.7.jar:24.3.7] > at java.base/java.util.ArrayList.forEach(ArrayList.java:1596) ~[?:?] > at com.vaadin.flow.internal.nodefeature.ElementListenerMap.fireEvent(ElementListenerMap.java:447) ~[flow-server-24.3.7.jar:24.3.7] > at com.vaadin.flow.server.communication.rpc.EventRpcHandler.handleNode(EventRpcHandler.java:62) ~[flow-server-24.3.7.jar:24.3.7] > at com.vaadin.flow.server.communication.rpc.AbstractRpcInvocationHandler.handle(AbstractRpcInvocationHandler.java:74) ~[flow-server-24.3.7.jar:24.3.7] > at com.vaadin.flow.server.communication.ServerRpcHandler.handleInvocationData(ServerRpcHandler.java:466) ~[flow-server-24.3.7.jar:24.3.7] > at com.vaadin.flow.server.communication.ServerRpcHandler.lambda$handleInvocations$4(ServerRpcHandler.java:447) ~[flow-server-24.3.7.jar:24.3.7] > at java.base/java.util.ArrayList.forEach(ArrayList.java:1596) ~[?:?] > at com.vaadin.flow.server.communication.ServerRpcHandler.handleInvocations(ServerRpcHandler.java:447) ~[flow-server-24.3.7.jar:24.3.7] > at com.vaadin.flow.server.communication.ServerRpcHandler.handleRpc(ServerRpcHandler.java:324) ~[flow-server-24.3.7.jar:24.3.7] > at com.vaadin.flow.server.communication.UidlRequestHandler.synchronizedHandleRequest(UidlRequestHandler.java:114) ~[flow-server-24.3.7.jar:24.3.7] > at com.vaadin.flow.server.SynchronizedRequestHandler.handleRequest(SynchronizedRequestHandler.java:40) ~[flow-server-24.3.7.jar:24.3.7] > at com.vaadin.flow.server.VaadinService.handleRequest(VaadinService.java:1574) ~[flow-server-24.3.7.jar:24.3.7] > at com.vaadin.flow.server.VaadinServlet.service(VaadinServlet.java:398) ~[flow-server-24.3.7.jar:24.3.7] > at jakarta.servlet.http.HttpServlet.service(HttpServlet.java:614) ~[jakarta.servlet-api-6.0.0.jar:6.0.0] > at org.eclipse.jetty.ee10.servlet.ServletHolder.handle(ServletHolder.java:736) ~[jetty-ee10-servlet-12.0.7.jar:12.0.7] > at org.eclipse.jetty.ee10.servlet.ServletHandler$ChainEnd.doFilter(ServletHandler.java:1614) ~[jetty-ee10-servlet-12.0.7.jar:12.0.7] > at io.imunity.vaadin.endpoint.common.InvocationContextSetupFilter.doFilter(InvocationContextSetupFilter.java:67) ~[unity-server-vaadin-endpoint-common-4.0.0.jar:?] > at org.eclipse.jetty.ee10.servlet.FilterHolder.doFilter(FilterHolder.java:205) ~[jetty-ee10-servlet-12.0.7.jar:12.0.7] > at org.eclipse.jetty.ee10.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1586) ~[jetty-ee10-servlet-12.0.7.jar:12.0.7] > at io.imunity.vaadin.auth.server.ProxyAuthenticationFilter.doFilter(ProxyAuthenticationFilter.java:113) ~[unity-server-vaadin-authentication-4.0.0.jar:?] > at org.eclipse.jetty.ee10.servlet.FilterHolder.doFilter(FilterHolder.java:205) ~[jetty-ee10-servlet-12.0.7.jar:12.0.7] > at org.eclipse.jetty.ee10.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1586) ~[jetty-ee10-servlet-12.0.7.jar:12.0.7] > at io.imunity.vaadin.auth.server.AuthenticationFilter.gotoProtectedResource(AuthenticationFilter.java:300) ~[unity-server-vaadin-authentication-4.0.0.jar:?] > at io.imunity.vaadin.auth.server.AuthenticationFilter.handleBoundSession(AuthenticationFilter.java:171) ~[unity-server-vaadin-authentication-4.0.0.jar:?] > at io.imunity.vaadin.auth.server.AuthenticationFilter.doFilter(AuthenticationFilter.java:97) ~[unity-server-vaadin-authentication-4.0.0.jar:?] > at org.eclipse.jetty.ee10.servlet.FilterHolder.doFilter(FilterHolder.java:205) ~[jetty-ee10-servlet-12.0.7.jar:12.0.7] > at org.eclipse.jetty.ee10.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1586) ~[jetty-ee10-servlet-12.0.7.jar:12.0.7] > at io.imunity.vaadin.endpoint.common.RemoteRedirectedAuthnResponseProcessingFilter.doFilter(RemoteRedirectedAuthnResponseProcessingFilter.java:48) ~[unity-server-vaadin-endpoint-common-4.0.0.jar:?] > at org.eclipse.jetty.ee10.servlet.FilterHolder.doFilter(FilterHolder.java:205) ~[jetty-ee10-servlet-12.0.7.jar:12.0.7] > at org.eclipse.jetty.ee10.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1586) ~[jetty-ee10-servlet-12.0.7.jar:12.0.7] > at org.eclipse.jetty.ee10.servlet.ServletHandler$MappedServlet.handle(ServletHandler.java:1547) ~[jetty-ee10-servlet-12.0.7.jar:12.0.7] > at org.eclipse.jetty.ee10.servlet.ServletChannel.dispatch(ServletChannel.java:814) ~[jetty-ee10-servlet-12.0.7.jar:12.0.7] > at org.eclipse.jetty.ee10.servlet.ServletChannel.handle(ServletChannel.java:431) ~[jetty-ee10-servlet-12.0.7.jar:12.0.7] > at org.eclipse.jetty.ee10.servlet.ServletHandler.handle(ServletHandler.java:464) ~[jetty-ee10-servlet-12.0.7.jar:12.0.7] > at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:571) ~[jetty-security-12.0.7.jar:12.0.7] > at org.eclipse.jetty.ee10.servlet.SessionHandler.handle(SessionHandler.java:703) ~[jetty-ee10-servlet-12.0.7.jar:12.0.7] > at org.eclipse.jetty.server.handler.ContextHandler.handle(ContextHandler.java:765) ~[jetty-server-12.0.7.jar:12.0.7] > at pl.edu.icm.unity.engine.server.ClientIPSettingHandler.handle(ClientIPSettingHandler.java:67) ~[unity-server-engine-4.0.0.jar:?] > at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:181) ~[jetty-server-12.0.7.jar:12.0.7] > at org.eclipse.jetty.rewrite.handler.RewriteHandler$LastRuleHandler.handle(RewriteHandler.java:159) ~[jetty-rewrite-12.0.7.jar:12.0.7] > at org.eclipse.jetty.rewrite.handler.Rule$Handler.handle(Rule.java:108) ~[jetty-rewrite-12.0.7.jar:12.0.7] > at org.eclipse.jetty.rewrite.handler.HeaderPatternRule$1.handle(HeaderPatternRule.java:89) ~[jetty-rewrite-12.0.7.jar:12.0.7] > at org.eclipse.jetty.rewrite.handler.Rule$Handler.handle(Rule.java:108) ~[jetty-rewrite-12.0.7.jar:12.0.7] > at org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:143) ~[jetty-rewrite-12.0.7.jar:12.0.7] > at org.eclipse.jetty.rewrite.handler.RewriteHandler$LastRuleHandler.handle(RewriteHandler.java:159) ~[jetty-rewrite-12.0.7.jar:12.0.7] > at org.eclipse.jetty.rewrite.handler.Rule$Handler.handle(Rule.java:108) ~[jetty-rewrite-12.0.7.jar:12.0.7] > at org.eclipse.jetty.rewrite.handler.HeaderPatternRule$1.handle(HeaderPatternRule.java:89) ~[jetty-rewrite-12.0.7.jar:12.0.7] > at org.eclipse.jetty.rewrite.handler.Rule$Handler.handle(Rule.java:108) ~[jetty-rewrite-12.0.7.jar:12.0.7] > at org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:143) ~[jetty-rewrite-12.0.7.jar:12.0.7] > at org.eclipse.jetty.server.handler.gzip.GzipHandler.handle(GzipHandler.java:597) ~[jetty-server-12.0.7.jar:12.0.7] > at org.eclipse.jetty.server.Handler$Wrapper.handle(Handler.java:716) ~[jetty-server-12.0.7.jar:12.0.7] > at pl.edu.icm.unity.engine.server.TraceBlockingHandler.handle(TraceBlockingHandler.java:34) ~[unity-server-engine-4.0.0.jar:?] > at org.eclipse.jetty.server.Server.handle(Server.java:179) ~[jetty-server-12.0.7.jar:12.0.7] > at org.eclipse.jetty.server.internal.HttpChannelState$HandlerInvoker.run(HttpChannelState.java:619) ~[jetty-server-12.0.7.jar:12.0.7] > at org.eclipse.jetty.server.internal.HttpConnection.onFillable(HttpConnection.java:411) ~[jetty-server-12.0.7.jar:12.0.7] > at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:322) ~[jetty-io-12.0.7.jar:12.0.7] > at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:99) ~[jetty-io-12.0.7.jar:12.0.7] > at org.eclipse.jetty.io.ssl.SslConnection$SslEndPoint.onFillable(SslConnection.java:574) ~[jetty-io-12.0.7.jar:12.0.7] > at org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:390) ~[jetty-io-12.0.7.jar:12.0.7] > at org.eclipse.jetty.io.ssl.SslConnection$2.succeeded(SslConnection.java:150) ~[jetty-io-12.0.7.jar:12.0.7] > at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:99) ~[jetty-io-12.0.7.jar:12.0.7] > at org.eclipse.jetty.io.SelectableChannelEndPoint$1.run(SelectableChannelEndPoint.java:53) ~[jetty-io-12.0.7.jar:12.0.7] > at org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.runTask(AdaptiveExecutionStrategy.java:478) ~[jetty-util-12.0.7.jar:12.0.7] > at org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.consumeTask(AdaptiveExecutionStrategy.java:441) ~[jetty-util-12.0.7.jar:12.0.7] > at org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.tryProduce(AdaptiveExecutionStrategy.java:293) ~[jetty-util-12.0.7.jar:12.0.7] > at org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.run(AdaptiveExecutionStrategy.java:201) ~[jetty-util-12.0.7.jar:12.0.7] > at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:410) ~[jetty-util-12.0.7.jar:12.0.7] > at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:971) ~[jetty-util-12.0.7.jar:12.0.7] > at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.doRunJob(QueuedThreadPool.java:1201) ~[jetty-util-12.0.7.jar:12.0.7] > at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:1156) ~[jetty-util-12.0.7.jar:12.0.7] > at java.base/java.lang.Thread.run(Thread.java:1583) [?:?] > 2024-07-30T06:08:37,315 [qtp1550177731-224594] DEBUG com.vaadin.flow.server.communication.UidlWriter: * Creating response to client > > > Best regards, > Sander > > > > On Tue, 2024-07-30 at 08:00 +0200, Roman Krysiński wrote: >> Good morning Sander, >> >> Would it be possible to provide a null pointer exception in >> question? >> >> We are working on the "HTML elements in the tooltips are not >> rendered" problem, and will be released in the 4.0.1 patch, along >> with other reported issues. >> >> Best regards, >> Roman >> >> wt., 23 lip 2024 o 11:09 Roman Krysiński <ro...@un...> >> napisał(a): >>> Good morning Sander, >>> >>> Thank you for reporting issues, we will look into it soon. >>> >>> Stay tuned, and thank you for your support! >>> >>> Best regards, >>> Roman >>> >>> wt., 23 lip 2024 o 09:57 Sander Apweiler >>> <sa....@fz...> napisał(a): >>>> Good morning Krzysztof, >>>> beside the issues Laura reported, we found two further issues. >>>> >>>> - HTML elements in the tool tips are not rendered. >>>> - Creating a HomeUI endpoint in the webconsole by filling only >>>> the >>>> mandatory parts + displayed attributes + adding single >>>> authenticator >>>> leads to a null pointer exception >>>> >>>> >>>> Best regards, >>>> Sander >>>> > > > _______________________________________________ > Unity-idm-discuss mailing list > Uni...@li... > https://lists.sourceforge.net/lists/listinfo/unity-idm-discuss |
