JS Asset Picker: No 'Access-Control-Allow-Origin' header is present on the requested resource | Community
Skip to main content
T
trumb1mj
September 21, 2020
Question

JS Asset Picker: No 'Access-Control-Allow-Origin' header is present on the requested resource

  • September 21, 2020
  • 2 replies
  • 1470 views

I'm using the asset picker documented here:  https://helpx.adobe.com/experience-manager/6-2/assets/using/asset-picker.html

 

I keep getting the following error and wondering what I'm doing wrong?

 

Access to XMLHttpRequest at 'https:/blah/content/dam/example.jpg' from origin 'https://local.test.blah.com' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.

Do I need to change my header or something?  I'm using an XHR javascript request.

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.

2 replies

vanegi
Adobe Employee
vanegiAdobe Employee
Adobe Employee
September 21, 2020

Check if https://local.test.blah.com is added in allowed origins of Adobe Granite Cross-Origin Resource Sharing Policy ( com.adobe.granite.cors.impl.CORSPolicyImpl ) configuration.

 

Also check the following:

 

  • Manually recreate XHR requests using curl, but make sure to copy all headers and details, as each one can make a difference; some browser consoles allow to copy the curl command
  • Verify if request was denied by the CORS handler and not by the authentication, CSRF token filter, dispatcher filters, or other security layers
    • If CORS handler responds with 200, but Access-Control-Allow-Origin header is absent on the response, review the logs for denials under DEBUG in com.adobe.granite.cors
  • If dispatcher caching of CORS requests is enabled
    • Ensure the /headers configuration is applied to dispatcher.any and the web server is successfully restarted
    • Ensure the cache was properly cleared after any OSGi or dispatcher.any configuration changes.
  • if required, check presence of authentication credentials on the request.
    T
    trumb1mjAuthor
    September 21, 2020
    I'm actually seeing something interesting now. It appears as though I'm getting a 302 back and a location url to a login page even though I'm already authenticated in the browser. If I visit the asset url directly it downloads without issue...
    T
    trumb1mjAuthor
    September 22, 2020

    It seems the entire difference between a working request and a broken one is the cookie being passed up.

     

    The working one includes ApplicationGatewayAffinityCORS, ApplicationGatewayAffinity, login-token and cq-authoring-mode.

     

    The broken one only has ApplicationGatewayAffinityCORS.

     

    So I guess my question is: How do I get the login-token (and other fields) from AEM? Can I force xhr to somehow use the default browser values for this?

      Terms & ConditionsAccessibility statement

      Loading footer...