• Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Low Low
    • None
    • 7.18.0
    • Server - Platform
    • None

      Issue Summary

      This is reproducible on Data Center: yes

      Use the new module like this:

      <xstream-security key = "xstream-set" name="Some XStream allowlist set">
          <wildcard>**</wildcard>
      </xstream-security> 

      does not work.

      Steps to Reproduce

      1. Create an app that uses <xstream-security/>
      2. Use atlas-debug to start Confluence

      Expected Results

      The app runs without error

      Actual Results

      The below exception is thrown in the atlassian-conflence.log file:

      2022-08-22 09:01:36,891 ERROR [ThreadPoolAsyncTaskExecutor::Thread 31] [plugin.osgi.factory.OsgiPlugin] onPluginContainerFailed Unable to start the plugin container for plugin 'com.company.myplugin'
       -- url: /confluence/rest/plugins/1.0/ | traceId: 401ca2d490aee6a6 | userName: admin
      org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'sampleComponent': Invocation of init method failed; nested exception is com.atlassian.confluence.api.service.exceptions.ServiceException: Could not deserialize object as XStream might not be properly initialized

      Workaround

      When using atlas-debug add

      <configuration>
          <systemPropertyVariables>
      	<xstream.allowlist.enable>false</xstream.allowlist.enable>
          </systemPropertyVariables>
      </configuration> 

            [CONFSERVER-81014] xstream-security module not working in atlas-debug mode

            It is happening in the attached sample plugin because of incorrect initialisation of xstream . Here xstream is being used just at the time of bean initialisation and cannot use xstream in afterPropertiesSet .

            In order to fix/avoid this issue:
            It is recommended to lazily initialise XStream instance, and use in a flow that triggers after the SAL LifecycleAware.onStart is called.

            If a plugin wants to use it in afterPropertiesSet, they need delayed calls as XStream won’t be ready until plugin starts.

            This is because as per plugin’s workflow, all the modules will be enabled after the beans/objects gets initialised.

             

            !https://developer.atlassian.com/favicon.ico!Plugins2 add-ons

            Ajay Sharma (Inactive) added a comment - It is happening in the attached sample plugin because of incorrect initialisation of xstream . Here xstream is being used just at the time of bean initialisation and cannot use xstream in afterPropertiesSet . In order to fix/avoid this issue: It is recommended to lazily initialise XStream instance, and use in a flow that triggers after the SAL LifecycleAware.onStart is called . If a plugin wants to use it in afterPropertiesSet , they need delayed calls as XStream won’t be ready until plugin starts. This is because as per plugin’s workflow, all the modules will be enabled after the beans/objects gets initialised.   !https://developer.atlassian.com/favicon.ico!Plugins2 add-ons

              19cb521e4007 Ajay Sharma (Inactive)
              jrichards@atlassian.com James Richards
              Affected customers:
              0 This affects my team
              Watchers:
              2 Start watching this issue

                Created:
                Updated:
                Resolved: