Random 304 redirect and a CORS error (CORS header 'Access-Control-Allow-Origin' missing)

Problem Statement:

If you have embedded the jasperserver application and get a random 304 redirect and a CORS error [CORS header 'Access-Control-Allow-Origin' missing]. 

Resolution:

In order to investigate this issue further, we must follow the below steps:

1. First check if you have OPTIONS as allowed methods, to do that open: <path-to-deployed-jrs>/WEB-INF/applicationContext-security-pro-web.xml and check if <property name="allowedMethods"> contains <value>OPTIONS</value>, it should look like this:

<property name="allowedMethods">

    <list>

        <value>GET</value>

        <value>POST</value>

        <value>HEAD</value>

        <value>PUT</value>

        <value>DELETE</value>

        <value>PATCH</value>

        <value>OPTIONS</value>     

    </list>

</property> 

2. If the method OPTIONS is not present in the list of allowedMethods then add it and restart the application server. If it is present then we need to debug the issue further by enabling logging for the Spring Cors Filter. 

Open <path-to-deployed-jrs>/WEB-INF/log4j2.properties file ** and add next lines (somewhere below root logger definition rootLogger.level=ERROR or in the end of the file):

logger.defaultCorsProcessor.name=org.springframework.web.cors.DefaultCorsProcessor

logger.defaultCorsProcessor.level=TRACE

logger.defaultCorsProcessor.appenderRef.stdout.ref=stdout

logger.defaultCorsProcessor.appenderRef.rolling.ref=fileout 

Open <path-to-deployed-jrs>/WEB-INF/applicationContext-diagnosticCollectors-pro.xml, find customLoggerToLevelMap bean and replace it with the next definition:

<bean id="customLoggerToLevelMap" class="java.util.EnumMap" lazy-init="true">

    <constructor-arg>

        <util:map key-type="com.jaspersoft.ji.diagnostic.Verbosity">

            <entry key="LOW">

                <util:map>

                    <entry key="com.jaspersoft" value="ERROR"/>

                </util:map>

            </entry>

            <entry key="MEDIUM">

                <util:map>

                    <entry key="com.jaspersoft" value="WARN"/>

                    <entry key="mondrian.mdx" value="WARN"/>

                </util:map>

            </entry>

            <entry key="HIGH">

                <util:map>

                    <entry key="com.jaspersoft" value="DEBUG"/>

                    <entry key="mondrian.mdx" value="DEBUG"/>

                    <entry key="com.jaspersoft.jasperserver.api.engine.jasperreports.service.impl.JdbcDataSourceService"

                           value="DEBUG"/>

                </util:map>

            </entry>

        </util:map>

    </constructor-arg>

</bean>

All <entry key="root" value="..."/> lines were removed from it, they hide CORS logger.

After jasperserver.log file should contain entries like this:

2021-07-03T00:00:42,927 DEBUG DefaultCorsProcessor,http-nio-8080-exec-5:128 - Reject: HTTP 'OPTIONS' is not allowed

2021-07-03T00:00:42,927 DEBUG DefaultCorsProcessor,http-nio-8080-exec-5:128 - Reject: HTTP 'OPTIONS' is not allowed 

3. Additonally JRS does not generate 304 status responses in general. If you read https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/304 you will find out that it might be triggered by conditional request when If-None-Match or If-Modified-Since headers are used. And we see such headers in the request with 304 responses.

These headers are used for cache manipulation operations. The cache accelerator could be involved in this caching business here. 

Refer to the following about edge cases of 304 and CORS combination https://stackoverflow.com/questions/67730604/should-a-304-not-modified-response-to-a-cors-request-contain-cors-headers

The suggestions here would be to adjust the settings of the cache accelerator or whatever other proxy is there between the browser and JRS to:

• either respond with access control headers even for 304 status 
• or exclude JRS from caching business in general as we already have our own caching mechanism where it is needed