Erroneous Authentication Popup when Previewing Fiori Application in BAS

[andrewlove]

I'm a longtime ABAP developer who is currently learning Fiori development & I'm running into an issue that has me stumped. Below are the steps that I have taken to get to where I am now.

1. I am using S4HANA demo system A4H that is running in a docker container on my desktop computer.
2. In A4H, I created OData project ZFUM in SEGW, implemented the needed ABAP code, and exposed this on the gateway as service ZFUM_SRV.
3. In A4H's docker container, I'm also running a Cloud Connector instance.
4. I created a BTP Trial account and connected this trial account to the Cloud Connector instance running in the A4H docker container.
5. I created destination A4H in the BTP Cockpit using BasicAuthentication specifying the user and password of a user in A4H.
6. I subscribed to BAS in the BTP Cockpit and created a dev space in BAS.
7. In the BAS dev space, I created a basic freestyle Fiori project using the A4H destination and the ZFUM_SRV service.
8. I developed some views in the Fiori project using the OData service and I was successfully able to preview this application in BAS without being presented any authentication popups (since the user and password are specified in the BTP destination).
9. Ok, no problems yet. So, when I'm done for the day, I close BAS and shutdown the docker container running A4H and Cloud Connector.
10. The next day, I start the docker container with A4H and start the Cloud Connector. I start the dev space in BAS, but now when I try to preview the app, it is presenting the following authentication popup:

It should not be asking for user and password because that is specified in the BTP destination. I tried providing the same user & password the destination is using, but it does not work and the data is not fetched. The only solution I have found so far is to delete the dev space in BAS, create a new dev space, & clone the same Fiori development files from git. After I do this, then the preview works as it did the previous day and the OData calls are successful without seeing any authentication popup.

This workaround is fine for now I suppose, but it seems extreme to have to recreate a dev space every day. So, I assume there is something I am missing to prevent this issue. What can I do to prevent this problem or to more gracefully address it each time I see it happen?

[rotem_puterman-sobe]

Hi,
Creating a new dev space is resulted with a new URL (since it is including the unique dev space ID), therefore I wonder if this is related to browser cache / cookies issue somehow after a first successful authentication from your application preview (which could be no longer valid after your local docker container restart).
I'm not sure exactly why this happens, but I can suggest trying a better workaround than creating a new dev space for the next time this happens: 
You can try opening developer tools of your browser, find in the network tab the request to your OData service failing with authentication error, and after right clicking on it you can select the option to clear browser cache / cookies for this specific request domain. Then simply refresh your browser tab to trigger the request again.
(tested on Chrome browser).

Thanks,
Rotem

[andrewlove]

@rotem_puterman-sobe,

Thanks for the suggestion.  Interestingly, last time I saw the issue was on Friday.  I did not check again until today (Monday) and I do no currently see the behavior.  In fact, after checking today, I shutdown the docker container and the dev space, waited about 3 hours, and then re-started the docker container and dev space.  I checked again and still don't see the erroneous behavior.

I'll check again tomorrow and once I see the behavior occur, I will try your suggestion.

[andrewlove]

Today I encountered the issue again and I tried the suggestion mentioned by @rotem_puterman-sobe.

As before, it presents the login popup:

While the popup is still open, this request is still pending as seen in the dev tools:

When I close the popup, it shows status 401 unauthorized:

So, as suggested, I found the request and right clicked and then clicked both clear browser cache and clear browser cookies.

I was expecting this to only clear the cache/cookies for the domain related to this request, however I noticed that all tabs I was logged into were immediately logged out.  So, I would appear these menu options just do a global removal of the cache/cookies.

Anyway, after doing that I logged back in and tried again.  This time it was executed as normal:

This is better than recreating the dev space, however, having to re-login to the ~10 other open tabs was irritating.

Next time, I am going to try manually deleting the cookies related to just that request and see if I can avoid affecting other logins.  If that doesn't work, I suppose changing to only ever logging into BAS from incognito mode would probably achieve the same result without having to do anything since incognito mode cache/cookies are deleted when the window is closed.

[eedens]

I did the same thing the first time. That's why I set up a second browser profile that I use specifically for running BAS.

[rotem_puterman-sobe]

Next time you can probably only delete cookies and not cache. If you can find the specific cookie causing the issue and delete only this one this is for sure even better.... Some of the cookies used for the dev space domain (and therefore are associated with the request) are also applicable for *.cloud.sap domain or other SAP BTP apps, so it can affect re-login to those. With that it should not affect non-SAP related browser tabs, so it is better than cleaning the global cache / cookies from my personal experience.

[eedens]

I've been having this issue as well. The workaround that I've found is to delete all the browser data, and re-open it. I've had to set up a second profile in Chrome so I don't keep wiping out my history and settings on my regular profile.