Four Stars

CORS preflight on REST service with HTTP basic authentication enabled

I have a REST service with basic HTTP authentication enabled and I want to access it from the browser (I tried using javascript XMLHttpRequest), but when I send a GET to the resource setting the authorization header it does first a preflight request with an OPTIONS verb that waits for a response with the header "Access-Control-Allow-Headers"  (among others) containing "Authorization" as one of the headers allowed for the GET verb.

I saw this post on previous talend forum suggesting to implement an OPTIONS verb with the same URI as GET and with these headers in the response. I have tested it successfully with basic HTTP authentication disabled (I simulated setting a different header on GET verb since authentication was disabled and it also sent the OPTIONS preflight). However, when I enable HTTP authentication again it is also applied to the OPTIONS verb and the authorization header is required for OPTIONS verb also, driving into a HTTP 401 Unauthorized error.


There is this JIRA ticket already opened for implementing CORS on tRestRequest. Is it related to this issue?

If so and while it is not solved, Is there any known workaround to access from the browser a REST service with HTTP authentication enabled?


Thanks in advance.


Best regards,



Re: CORS preflight on REST service with HTTP basic authentication enabled



This jira issue is about cross-origin resource sharing. During the pre-flight (OPTIONS) the browser is not using authentication.

This issue is still in process and we will keep you posted.

Best regards


Don't forget to give kudos when a reply is helpful and click Accept the solution when you think you're good with it.
Five Stars

Re: CORS preflight on REST service with HTTP basic authentication enabled

Just to add some context - and add a BIG YES VOTE for this enhancement request...


The W3 spec for CORS preflight requests states that user credentials should be excluded, so this enhancement would make Talend more compliant. This is important because REST APIs are more commonly used as an abstract layer for the Microservice architecture (cross origin situations) and development team who use the tRESTRequest component need to account for this situation.



  1. turn off the authentication in the tRESTRequest
  2. Add Authorization to the "non OPTIONS" Output Flow (e.g.: postData) as a header parameter.
  3. In the "postData" flow, add a  tJavaRow component that decodes (Base64) and splits (colon) the Authorization parameter in to the username and password
  4. Follow the flow with a tSOAP component to call the STS service
  5. Next, add a tExtractXMLField to extract the Assertion in the response.
    1. Loop XPath query = "/*[local-name()='Envelope']/*[local-name()='Body']/*[local-name()='RequestSecurityTokenResponseCollection']/*[local-name()='RequestSecurityTokenResponse']/*[local-name()='RequestedSecurityToken']"
    2. assertion = "*[local-name()='Assertion']"
    3. userId="*[local-name()='Assertion']/*[local-name()='Subject']/*[local-name()='NameID']"
  6. If the username in step #3 equals the userId in step #5.3, then authentication is successful
  7. Extra - add a tJavaRow to deflate and encode Base64 the assertion (don't forget to remove all the tabs and carriage returns) - This is the SAML token that you can pass in the tRESTResponse in the head to be used for SAML authentication.

Note: This work around is good for wrapping the STS authentication service into a RESTful endpoint to support Single Sign-On (using SAML)



Here are links to other discussions about this same requirement