Skip to main content

YUI Cross-Domain transactions without Flash

Recently I've worked on the application making cross-domain ajax calls with YUI. While YUI offers io-xdr module for making cross-domain requests via Flash transport, it seems to me quite unnatural as it leads to unnecessary complexity. Moreover, io-xdr was marked deprecated several months ago without explicit mentioning the preferred way. An obvious alternative is using XMLHttpRequest as a transport for cross-domain requests. However, it has some limitations and undocumented pitfalls that I'd like to review in this post.
  1. Cross-Domain request using XMLHttpRequest.
  2. YUI IO Utility.
  3. YUI Datasource IO.
Cross-Domain request using XMLHttpRequest
Cross-domain requests can be sent using a common XMLHttpRequest object. The only requirement is that the server must be configured to properly handle those requests. Specifically, it should set the Access-Control-Allow-Origin response header according to Cross-Origin Resource Sharing specification. For more details and good tutorials you can refer to Mozilla documentation.

YUI IO Utility
When I've tried to create a cross-domain request with YUI IO Utility, I've got the following JavaScript error:
OPTIONS https://request-url Request header field X-Requested-With is not allowed by Access-Control-Allow-Headers. io-base.js:731
XMLHttpRequest cannot load https://request-url. Request header field X-Requested-With is not allowed by Access-Control-Allow-Headers. 
Apparently, YUI IO Utility sends a preflight OPTIONS request first due to the X-Requested-With header. It looks like a recurring bug in YUI that seems to have been fixed. Anyway there is a guaranteed way to resolve this issue as you can unset headers since YUI 3.3.0. An example:
Y.io(remote_resource_uri, {
    headers: {
        'X-Requested-With': 'disable'
    }
});

YUI Datasource IO
As soon as you've found the above solution, it's easy to make Datasource.IO working with cross-domain requests. You just need to provide the optional ioConfig parameter to the datasource constructor:
var ds = new Y.DataSource.IO({
    source: remote_resource_uri,
    ioConfig: { 
        headers: { 
            'X-Requested-With': 'disable' 
        } 
    }
});

Comments

Popular posts from this blog

Connection to Amazon Neptune endpoint from EKS during development

This small article will describe how to connect to Amazon Neptune database endpoint from your PC during development. Amazon Neptune is a fully managed graph database service from Amazon. Due to security reasons direct connections to Neptune are not allowed, so it's impossible to attach a public IP address or load balancer to that service. Instead access is restricted to the same VPC where Neptune is set up, so applications should be deployed in the same VPC to be able to access the database. That's a great idea for Production however it makes it very difficult to develop, debug and test applications locally. The instructions below will help you to create a tunnel towards Neptune endpoint considering you use Amazon EKS - a managed Kubernetes service from Amazon. As a side note, if you don't use EKS, the same idea of creating a tunnel can be implemented using a Bastion server . In Kubernetes we'll create a dedicated proxying pod. Prerequisites. Setting up a tunnel. ...

Notes on upgrade to JSF 2.1, Servlet 3.0, Spring 4.0, RichFaces 4.3

This article is devoted to an upgrade of a common JSF Spring application. Time flies and there is already Java EE 7 platform out and widely used. It's sometimes said that Spring framework has become legacy with appearance of Java EE 6. But it's out of scope of this post. Here I'm going to provide notes about the minimal changes that I found required for the upgrade of the application from JSF 1.2 to 2.1, from JSTL 1.1.2 to 1.2, from Servlet 2.4 to 3.0, from Spring 3.1.3 to 4.0.5, from RichFaces 3.3.3 to 4.3.7. It must be mentioned that the latest final RichFaces release 4.3.7 depends on JSF 2.1, JSTL 1.2 and Servlet 3.0.1 that dictated those versions. This post should not be considered as comprehensive but rather showing how I did the upgrade. See the links for more details. Jetty & Tomcat. JSTL. JSF & Facelets. Servlet. Spring framework. RichFaces. Jetty & Tomcat First, I upgraded the application to run with the latest servlet container versio...

Managing Content Security Policy (CSP) in IBM MAS Manage

This article explores a new system property introduced in IBM MAS 8.11.0 and Manage 8.7.0+ that enhances security but can inadvertently break Google Maps functionality within Manage. We'll delve into the root cause, provide a step-by-step solution, and offer best practices for managing Content Security Policy (CSP) effectively. Understanding the issue IBM MAS 8.11.0 and Manage 8.7.0 introduced the mxe.sec.header.Content_Security_Policy   property, implementing CSP to safeguard against injection attacks. While beneficial, its default configuration restricts external resources, causing Google Maps and fonts to malfunction. CSP dictates which domains can serve various content types (scripts, images, fonts) to a web page. The default value in this property blocks Google-related domains by default. Original value font-src 'self' data: https://1.www.s81c.com *.walkme.com; script-src 'self' 'unsafe-inline' 'unsafe-eval' ...