Locale dependent view permission for pages

[Roland Blochberger, geändert vor 15 Jahren.]

Hi,

I am going to implement an addition to the Liferay PermissionChecker that allows to control which pages are visible to users having selected certain Locales.
I plan to extend the com.liferay.portal.security.permission.AdvancedPermissionChecker and configure this extended class as the portal's permission checker in the portal-ext.properties file.

My question is how to extend the persistent storage for the locale dependent permission so the core Liferay permission system will not break.
I could imagine to create a new database table for the locales to be allowed/disallowed for certain pages. At the moment I need to check this locale dependent permission for pages only and could ignore groups, roles, or organizations.
So I would implement this by overriding the existing hasPermission and hasUserPermission methods of the AdvancedPermissionChecker class. My overridden methods would check my added locale table only if the respective method of the superclass returns true.
But I have to associate the entries of my locale table with Liferay pages and I cannot see how to do that. Do the methods of the PermissionChecker have any knowledge about pages?

Regards
Roland

[Ray Augé, geändert vor 15 Jahren.]

You might want to have a look at:

[tt]com.liferay.portal.service.permission.LayoutPermissionImpl[/tt]

This class performs permission checks on, and is aware of pages.

What you can do is extend that class and override some methods, then configure the portal to use your implementation:

[tt] <bean id="com.liferay.portal.service.permission.LayoutPermissionUtil" class="com.liferay.portal.service.permission.LayoutPermissionUtil">
<property name="layoutPermission">
<bean class="com.liferay.portal.service.permission.LayoutPermissionImpl" />
</property>
</bean>[/tt]

This is found in the [tt]util-spring.xml[/tt] file in the [tt]portal-impl.jar!/META-INF[/tt] folder.

Copy that file to [tt]ROOT/WEB-INF/classes/META-INF/util-spring.xml[/tt]

and make your changes there...

One catch! NOTE this change for your future upgrades. The spring files are not usually an API feature that we promote much, but they are there for this specific reason, but we've frequently changed them as we've tuned our spring usage. But as long as you are careful to be aware of this, you should be fine. It's a very clean way to customize behavior.

[Roland Blochberger, geändert vor 15 Jahren.]

Ray Augé:

You might want to have a look at:

[tt]com.liferay.portal.service.permission.LayoutPermissionImpl[/tt]

This class performs permission checks on, and is aware of pages.

...

Thanks for your hint. I have seen that LayoutPermissionImpl calls the PermissionChecker and supplies the classname and primary key of the Layout if it wants to check Layout permissions.

So maybe it would be enough for my Locale dependent permission checks on Layouts to just extend the AdvancedPermissionChecker and do Locale dependent checks there if the Layout classname is passed to the hasPermission method.
Nevertheless I will have to create a new database table (and the respective service) that associates the Layout primary key to a (comma separated) list of Locale ids, right?

Do you think that implementation would fit into the overall Liferay architecture?

EDIT: I just recognized that the AdvancedPermissionChecker's method setValues(PortletRequest portletRequest) is called far too late to let me use the PortletRequest's Locale for my checks. I would need it just before or after the init method call which is called before any of the hasPermission methods. Is there another method to get the HttpRequest's Locale into my extended PermissionChecker?

Another issue is to somehow add the administration GUI to select the allowed/disallowed Locales to the existing permission administration for pages. Is there some preferred way to do that?

Regards,
Roland

[Roland Blochberger, geändert vor 15 Jahren.]

Roland Blochberger:

EDIT: I just recognized that the AdvancedPermissionChecker's method setValues(PortletRequest portletRequest) is called far too late to let me use the PortletRequest's Locale for my checks. I would need it just before or after the init[/] method call which is called before any of the hasPermission[/] methods. Is there another method to get the HttpRequest's Locale into my extended PermissionChecker?

I could solve this problem as described here: HttpServletRequest attributes statically (threadlocal) available?

[Lisa Simpson, geändert vor 15 Jahren.]

You probably ought to get yourself over to the permissions sticky thread at the top of this board and chime in with your 2 cents as well.

[Marc Piparo, geändert vor 12 Jahren.]

Hi.
Ah. I spotted this thread shortly after posting to mine: http://www.liferay.com/community/forums/-/message_boards/message/10640451 and may think participants here my help.
For different reasons, i want to extend the permission checker, specifically SearchPermissionChecker so as to include assets in the result set that users without permission to view.
I am having trouble understanding how to have my updated ExtSearchPermissionChecker class picked up. I did as follows in extlet-spring.xml:

<beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" default-destroy-method="destroy" default-init-method="afterPropertiesSet" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd">
<bean id="com.liferay.portlet.asset.service.AssetEntryService" class="com.liferay.portlet.asset.service.impl.ExtAssetEntryServiceImpl" />
<bean id="com.liferay.portal.search.SearchPermissionCheckerImpl" class="com.liferay.portal.search.ExtSearchPermissionCheckerImpl" />
</beans>

As you can see, I used the same approach for another ext class, AssetEntryService, for another functionality, and that is being picked up and working (though I dont fully understand why, which is probably part of my problem. :-). but my new ExtSearchPermissoinCheckerImpl class is not being picked up. (I also updated spring.configs property in portal-ext.properties to pick the exlet-spring.xml. Any ideas what I may be doing wrong?

much appreciated!