BUG - ODataModel not getting called when adding authorization header

matt1as commented 4 months ago

Description

We have an fiori application where we call a SuccessFactors OData service secured by a JWT Bearer token, but since about two weeks it is not working anymore.

If we add an authorization header to our ODataModel it receievs a http 401 error when trying to fetch metadata, and i cannot see anything in the terminal output of Business Application Studio.

If I remove the authorization header I get the expected result, a popup asking for Basic Auth and a log in the BAS Terminal. If I add the header I get a 401 far too quick (20ms) for it to be coming from SuccessFactors, and no log in BAS.

Steps to Reproduce

Steps to reproduce the behavior:

Create Odata model and try to read const oDataModel = new ODataModel({ "serviceUrl": "/odata/v2", "headers": { "Authorization": "Bearer " + variable_containing_jwt } });
Call GET on the model ODataModel.read('entity');
Look in Chrome Developer network view
See error

Expected results

call visible in BAS Terminal and metadata getting loadeed from /odata/v2

Actual results

401 received in around 20ms and no call visible in BAS Terminale

Version/Components/Environment

The call os routed using fiori-tools-proxy with the follwing settings.

The JWT works when trying using or REST Client.

specVersion: "2.0"
metadata:
  name: appname
type: application
server:
  customMiddleware:
    - name: fiori-tools-proxy
      afterMiddleware: compression
      configuration:
        ui5:
          path:
            - /resources
            - /test-resources
          url: https://ui5.sap.com
        backend:
          - path: /odata/v2
            destination: successfactors
          - path: /sap/opu/odata
            destination: gateway

    - name: fiori-tools-preview
      afterMiddleware: compression
      configuration:
        component: las.las
        ui5Theme: sap_horizon

I am pretty sure it has worked, and it is still working when running deployed on a ABAP system, which is why I'm thinking it might be related to backend-proxy-middleware.

Root Cause Analysis

Problem

{describe the problem}

Fix

{describe the fix}

Why was it missed

{Some explanation why this issue might have been missed during normal development/testing cycle}

How can we avoid this

{if we don’t want to see this type of issues anymore what we should do to prevent}

tobiasqueck commented 4 months ago

@matt1as "I am pretty sure it has worked" is an interesting phrase ;)

The proxy is part of the @sap/ux-ui5-tooling module, therefore, the best way to check if indeed the module caused a regression, please check which version you are currently using that does not work, and which version worked for you.

matt1as commented 4 months ago

@tobiasqueck We're on 1.13 and have been for a long time. I realise this probably means its not ux-ui5-tooling that has changed. Even if I check out a version that used to work I still get the same behaviour.

Could the BAS Proxy (that redirects https://port8080-workspaces-xxxxx.eu20.applicationstudio.cloud.sap to localhost:8080) be responsible? I cannot see any changelogs for that, and maybe this is not the right project to file a bug for this. This seems plausibe to me since we don't even see it in the terminal, and it affects all users in the same way.

tobiasqueck commented 4 months ago

If you didn't change the version of the @sap/ux-ui5-tooling then I don't think it is a regression in the proxy. To narrow down the cause, I'd recommend using a simple http client in BAS, e.g. I like using curl. So, in your case you could test in the terminal in BAS with something like curl -I --header "Authorization: Bearer your_token" https://successfactors.dest/odata/v2.

If it fails, then it is independent of the tools, and we sadly cannot help you, and you need to open an issue with the BAS team.
If it works, then please start the proxy, and try curl again but this time with curl -I --header "Authorization: Bearer your_token" http://localhost:8080/odata/v2
- if that one fails (with other one having worked before), then we need to investigate a possible issue in the proxy
- if it also works then the issue is somewhere in your client-side coding

matt1as commented 4 months ago

Those two calls work, and the calls to localhost shows up in backend-proxy-middleware as expected.

What does not work, and what the Fiori app is trying to do, is calling https://port8080-workspaces-XXXXXXX.eu20.applicationstudio.cloud.sap/odata/v2/$metadata This gives me the exact same message as the Fiori app gets

curl -I --header "Authorization: Bearer xxxxx" https://port8080-workspaces-XXXXXXX.eu20.applicationstudio.cloud.sap/odata/v2/$metadata
HTTP/1.0 200 OK

HTTP/2 401 
date: Tue, 25 Jun 2024 05:40:01 GMT
x-envoy-upstream-service-time: 2
strict-transport-security: max-age=31536000; includeSubDomains
content-security-policy: frame-ancestors 'self' *.eu20cf.applicationstudio.cloud.sap gw.eu20.applicationstudio.cloud.sap *.eu20.applicationstudio.cloud.sap;
server: sap-business-application-studio

I guess this means there's something with the BAS proxy, and not backend-proxy-middleware . Also I don't understand why it gives me two HTTP statuses, where is the first one coming from?

HTTP/1.0 200 OK

HTTP/2 401

matt1as commented 4 months ago

Hello again, seems like it's working if I run the SAP Business Application Studio toolkit in VS Code. Closing this as it's related to BAS and not open-ux-tools.

SAP / open-ux-tools