Uploaded image for project: 'PUBLIC - Liferay Documentation'
  1. PUBLIC - Liferay Documentation
  2. LRDOCS-689

PACL development documentation about spring

    Details

      Description

      Hi Team,

      We have recognized that PACL won't work in some cases by just generating the policy. We would need to document these cases (I'm not completely sure where), here's the first one (from Ray):
      First off, Liferay + PACL do not allow getting undeclared access to classLoader which do not belong to the app itself. Accessing the classLoader is a very strict operation which in order to use, the code must declare access, and state the name of the classloader.

      So, RSC has spring configurations inside their app. These spring configs in particular do something tricky to try and get a hold of some Liferay services.

      1)
      <bean id="liferayDataSource" class="org.springframework.jdbc.datasource.LazyConnectionDataSourceProxy">
      <property name="targetDataSource">
      <bean class="com.liferay.portal.kernel.util.InfrastructureUtil" factory-method="getDataSource" />
      </property>
      </bean>
      2)
      <bean id="userServiceBeanFactory" class="com.liferay.portal.service.UserLocalServiceUtil" factory-method="getService" />
      3)
      <bean id="journalArticleFinderFactory" class="com.liferay.portlet.journal.service.JournalArticleLocalServiceUtil" factory-method="getService" />
      4)
      <bean id="journalContentFactory" class="com.liferay.portlet.journalcontent.util.JournalContentUtil" factory-method="getJournalContent" />

      You'll note that the spring config tries to use spring factory bean to call methods on some Liferay classes.

      the problem with how spring handles this is that it will try to get the classLoader of these classes... who really cares why! The issue is that spring is trying to get the classLoaders at all. This is no different than the plugin trying to get the classloader of the classes, which again we do not allow.

      But all is not lost. You can do one of two things:

      1) in the code, call the methods on these classes directly

      2) write a factory class which returns a wrapper around the instance needed, this avoids the fact that spring will try to do reflection. It won't matter if that code belongs to the plugin, that won't cause a security issue at all.

      Here is the class I used to get around the issue [attached]

      I basically replaced the cases above like so:

      1)
      <bean id="liferayDataSource" class="test.FactoryUtil" factory-method="getDataSource" />
      2)
      <bean id="userServiceBeanFactory" class="test.FactoryUtil" factory-method="getUserLocalService"></bean>
      3)
      <bean id="journalArticleFinderFactory" class="test.FactoryUtil" factory-method="getJournalArticleLocalService"></bean>
      4)
      <bean id="journalContentFactory" class="test.FactoryUtil" factory-method="getJournalContent"></bean>

      Please delete any reference to RCS as it's one of our ISVs. Also, please let me know if you would like us to handle these issues a different way.

        Attachments

          Issue Links

            Activity

              People

              • Votes:
                0 Vote for this issue
                Watchers:
                0 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:

                  Packages

                  Version Package
                  6.1.X
                  6.2.x