Help Desk Ticket Reference: https://na7.salesforce.com/500A0000005hXnl project_key: JBEPP if logged in user's role is changed, for example, from a "administrator" to "member", the user can still see the links to which only the "administrator" are supposed to access within a certain "cache" time(about 30 mins). The workaround for this issue is to invoke the method "clearCaches" of mbean exoortal="portal",service=cachemanager from jmx-console. If the user logs out and re-login the change can be reflected too. Can we have the new feature to make the change takes effect without logging out or flushing the cache via jmx-console?
Release Notes Docs Status: Added: Documented as Known Issue Release Notes Text: Added: If an authenticated user's role is demoted (for example, from a "administrator" to "member"), the user can still see the links to which only the "administrator" should see for approximately 30 minutes after the role info is changed. To work around the issue, invoke the method "clearCaches" of mbean exoportal="portal",service=cachemanager from jmx-console. A fix is being investigated. Primary SME: Added: theute
Labels: Added: EPP_5_2_1_Candidate
Labels: Removed: EPP_5_2_1_Candidate
Technical note added. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: CAUSE: when memberships of some user are changed (For example user root will remove user john from group /platform/users group), then user john won't see updates immediately. He needs to logout and login to see it. Example: 1) Start browser1, Go to http://localhost:8080/portal and login as john. User john is in group /platform/administrators by default, so he can see "Administrators" link in group menu, 2) Start browser2, Go to http://localhost:8080/portal and login as root. Go to OrganizationManagement and remove user john from /platform/administrators 3) Return to browser1 and refresh page. User john can still see "administrators" pages, which is a bug. 4) Logout and login again as john. Now "Administrators" are not longer visible. Bad is that john needs to logout and login, otherwise permissions for pages are not reflected. FIX: I added new listener "MembershipUpdateListener" into organization-configuration.xml file. This listener will update all memberships of logged user in ConversationRegistry, so that changes are immediately reflected in UI. RESULT: Changes are immediately reflected in UI. In previous example, user john won't see "Administrators" page in step 3, which is correct.
Technical note updated. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. Diffed Contents: @@ -1,9 +1 @@ -CAUSE: when memberships of some user are changed (For example user root will remove user john from group /platform/users group), then user john won't see updates immediately. He needs to logout and login to see it. Example: +It was discovered that changing memberships of already authenticated users did not immediately take effect. If a user had administrative membership revoked, and remained logged onto the portal, the privileges were still accessible for up to 30 minutes until the user permissions cache was refreshed. This could permit the user to perform undesirable actions in the portal. The fix introduces a new listener "MembershipUpdateListener" which is configurable from the organization-configuration.xml directive file. The listener immediately updates authenticated user memberships based on information in the ConversationRegistry. Changes to user memberships now take effect immediately, which corrects the originally reported issue.-1) Start browser1, Go to http://localhost:8080/portal and login as john. User john is in group /platform/administrators by default, so he can see "Administrators" link in group menu, -2) Start browser2, Go to http://localhost:8080/portal and login as root. Go to OrganizationManagement and remove user john from /platform/administrators -3) Return to browser1 and refresh page. User john can still see "administrators" pages, which is a bug. -4) Logout and login again as john. Now "Administrators" are not longer visible. Bad is that john needs to logout and login, otherwise permissions for pages are not reflected. - -FIX: I added new listener "MembershipUpdateListener" into organization-configuration.xml file. This listener will update all memberships of logged user in ConversationRegistry, so that changes are immediately reflected in UI. - -RESULT: Changes are immediately reflected in UI. In previous example, user john won't see "Administrators" page in step 3, which is correct.
Technical note updated. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. Diffed Contents: @@ -1 +1 @@ -It was discovered that changing memberships of already authenticated users did not immediately take effect. If a user had administrative membership revoked, and remained logged onto the portal, the privileges were still accessible for up to 30 minutes until the user permissions cache was refreshed. This could permit the user to perform undesirable actions in the portal. The fix introduces a new listener "MembershipUpdateListener" which is configurable from the organization-configuration.xml directive file. The listener immediately updates authenticated user memberships based on information in the ConversationRegistry. Changes to user memberships now take effect immediately, which corrects the originally reported issue.+It was discovered that changing memberships of already authenticated users did not immediately take effect. If a user had administrative membership revoked, and remained logged onto the portal, the privileges were still accessible for up to 30 minutes until the user permissions cache was refreshed. This could permit the user to perform undesirable actions in the portal. The fix introduces a new listener "MembershipUpdateListener" which has been added to organization-configuration.xml directive file. The listener immediately updates authenticated user memberships based on information in the ConversationRegistry. Changes to user memberships now take effect immediately, which corrects the originally reported issue.
Technical note updated. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. Diffed Contents: @@ -1 +1 @@ -It was discovered that changing memberships of already authenticated users did not immediately take effect. If a user had administrative membership revoked, and remained logged onto the portal, the privileges were still accessible for up to 30 minutes until the user permissions cache was refreshed. This could permit the user to perform undesirable actions in the portal. The fix introduces a new listener "MembershipUpdateListener" which has been added to organization-configuration.xml directive file. The listener immediately updates authenticated user memberships based on information in the ConversationRegistry. Changes to user memberships now take effect immediately, which corrects the originally reported issue.+It was discovered that changing memberships of already authenticated users did not immediately take effect. If a user had administrative membership revoked, and remained logged onto the portal, the privileges were still accessible for up to 30 minutes until the user permissions cache was refreshed. This could permit the user to perform undesirable actions in the portal. The fix introduces a new listener "MembershipUpdateListener" which has been added to EPP_HOME/server/<PROFILE>/deploy/gatein.ear/02portal.war/WEB-INF/conf/organization/organization-configuration.xml directive file. The listener immediately updates authenticated user memberships based on information in the ConversationRegistry. Changes to user memberships now take effect immediately, which corrects the originally reported issue.
Technical note updated. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. Diffed Contents: @@ -1 +1 @@ -It was discovered that changing memberships of already authenticated users did not immediately take effect. If a user had administrative membership revoked, and remained logged onto the portal, the privileges were still accessible for up to 30 minutes until the user permissions cache was refreshed. This could permit the user to perform undesirable actions in the portal. The fix introduces a new listener "MembershipUpdateListener" which has been added to EPP_HOME/server/<PROFILE>/deploy/gatein.ear/02portal.war/WEB-INF/conf/organization/organization-configuration.xml directive file. The listener immediately updates authenticated user memberships based on information in the ConversationRegistry. Changes to user memberships now take effect immediately, which corrects the originally reported issue.+It was discovered that changing memberships of already authenticated users did not immediately take effect. If a user had administrative membership revoked, and remained logged onto the portal, the privileges were still accessible for up to 30 minutes until the user permissions cache was refreshed. This could permit the user to perform undesirable actions in the portal. The fix introduces a new listener "MembershipUpdateListener" which has been added to <replaceable>JBOSS_HOME</replaceable>/server/<replaceable>PROFILE</replaceable>/deploy/gatein.ear/02portal.war/WEB-INF/conf/organization/organization-configuration.xml directive file. The listener immediately updates authenticated user memberships based on information in the ConversationRegistry. Changes to user memberships now take effect immediately, which corrects the originally reported issue.
Technical note updated. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. Diffed Contents: @@ -1 +1 @@ -It was discovered that changing memberships of already authenticated users did not immediately take effect. If a user had administrative membership revoked, and remained logged onto the portal, the privileges were still accessible for up to 30 minutes until the user permissions cache was refreshed. This could permit the user to perform undesirable actions in the portal. The fix introduces a new listener "MembershipUpdateListener" which has been added to <replaceable>JBOSS_HOME</replaceable>/server/<replaceable>PROFILE</replaceable>/deploy/gatein.ear/02portal.war/WEB-INF/conf/organization/organization-configuration.xml directive file. The listener immediately updates authenticated user memberships based on information in the ConversationRegistry. Changes to user memberships now take effect immediately, which corrects the originally reported issue.+It was discovered that changing memberships of already authenticated users did not immediately take effect. If a user had administrative membership revoked, and remained logged onto the portal, the privileges were still accessible for up to 30 minutes until the user permissions cache was refreshed. This could permit the user to perform undesirable actions in the portal. The fix introduces a new listener "MembershipUpdateListener" which has been added to <filename><replaceable>JBOSS_HOME</replaceable>/server/<replaceable>PROFILE</replaceable>/deploy/gatein.ear/02portal.war/WEB-INF/conf/organization/organization-configuration.xml</filename> directive file. The listener immediately updates authenticated user memberships based on information in the ConversationRegistry. Changes to user memberships now take effect immediately, which corrects the originally reported issue.
verified: I tried these 3 steps in EPP5.2.0.GA 1) Start browser1, Go to http://localhost:8080/portal and login as john. User john is in group /platform/administrators by default, so he can see "Administrators" link in group menu, 2) Start browser2, Go to http://localhost:8080/portal and login as root. Go to OrganizationManagement and remove user john from /platform/administrators 3) Return to browser1 and refresh page. and user john is still able to see "administrators" pages. I tried the steps in EPP5.2.0.ER03 and john is not able to see "administrators" pages immediately (no need to log out and log in).