Skip to Content

SAPUI5 custom library hosted in SCP

Hi folks, let me try to find an answer here.

I built UI5 library with some custom controls. Built it and deployed it on SCP using full-stack WebIDE. I need to reuse this library in the other ui5 app as embedded. This other ui5 app is running in the different domain.

But it didn't work when the library is deployed on Cloud Platform. The reason is a cross-domain origin of the request to get this library. And the request to load my library is refused.

When the same library is deployed, let's say, into github.io - all good and it's running well.

BTW, neo-app has authenticationMode as none.

If I had a complete app, I'd probably use frameOptions in bootstrap. Not sure. But it is mentioned in the documentation of SAPUI5. I didn't find how to deal with whitelisting for libraries.

So the question here is how to whitelist origins in the library hosted in SCP?

The error looks like attached. It says "No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin '...' is therefore not allowed access".

cors.png (39.9 kB)
Add comment
10|10000 characters needed characters exceeded

  • Get RSS Feed

2 Answers

  • Best Answer
    Nov 22, 2017 at 11:14 PM

    Solved.

    Very good explanation of CORS and what I needed to do in my case I found here: How does Access-Control-Allow-Origin header work?

    So the answer to my question was simple: I need somehow set "Access-Control-Allow-Origin" header in the response.

    Finally, gathering this and all ideas from Mike Doyle and some other folks from my twitter discussion, I used simple cloud connectivity proxy (open sourced by SAP at https://github.com/SAP/cloud-connectivityproxy ) .

    Steps I did (may be it's not the best approach, but worked well for my needs; origin can be adjusted certainly):

    1. Do an adjustment in the proxy code in processBackendResponse method in ProxyServlet class as below after "the copy of backend response headers" logic:

    response.addHeader("Access-Control-Allow-Origin", "*");

    2. Adjust url-pattern in web.xml of the proxy to point to my SCP destination as:

    <url-pattern>/proxy/ycustomlib/*</url-pattern>

    3. Build and deploy the proxy from Eclipse (HCP-ready) to my SCP account.

    4. In the deployed Java application create a destination ycustomlib (application-layer, not account/subaccount layer - important!; must be the same name as in created <url-pattern> above) as HTTP destination to Application URL of my deployed JS-library on SCP with NoAuthentication (since I have authenticationMode as none in my neo-app) and Proxy Type = Internet.

    5. Use it.

    One important thing what the url I needed to use. Finally, the following worked:

    https://<ApplicationURL>/proxy/ycustomlib/

    <ApplicationURL> - find it in SCP cockpit.

    For me it was https://<my_application+my_account>.hanatrial.ondemand.com/connectivity.proxy/proxy/zcustomlib/

    Hope this will make someone's life easier.

    Add comment
    10|10000 characters needed characters exceeded

  • Nov 16, 2017 at 04:56 AM

    Hi Andrei,

    I've not done this myself, but I'm struck by the parallel with what we normally do with Fiori Apps running on SCP but accessing OData services on an on-prem system. We create an SCP destination and reference this in the neo-app.json. The (HTTP) OData requests reference the destination listed in that file and the browser believes that the app and the OData service are in the same domain.

    Couldn't you do something similar in this case? When you load your library you could reference a destination that is listed in the neo-app.json and the browser should be happy that the library and the app are in the same domain.

    A broader question is whether you are sure you want to have this dependency between the different domains because it might make your app less robust.

    Mike

    Add comment
    10|10000 characters needed characters exceeded

    • Former Member

      And the broader answer: yes, I'm pretty sure there have to be different domains. This is the only way in my case. I will share more details in my upcoming blogs to let you completely understand the reason and use case. But for now, the answer is yes, I need different domains. I wish, I could use the same domain to store my library. But... anyway, wait for upcoming blogs from me on this topic ;)