Each isolated app also uses a (mostly) isolated network stack, which includes not sharing an authentication cache, so this sounds like expected behavior, from a network standpoint.

Well, but it would use proxy settings and authentication from Chrome (if you log in to proxy in Chrome, Files won't ask for a password and vice versa), and all other traffic goes through proxy in Files, as far as I can see.

> During the meeting, we explained the CWS Chrome Extension functionality to, amongst others, control the proxy settings on the Chromebook devices to send the traffic to the CWS Cloud and to perform the Proxy-Authorization required by the CWS Proxy to identify the users.
    > We also explained our findings that, while using the CWS Chrome Extension, the Proxy-Authorization header is appended to the browser traffic and not to the standalone apps traffic.
    > From a user’s point of view, the fact that the Proxy-Authorization header is missing on standalone apps traffic generates a Proxy Auth pop-up on the Chromebook and the app stops working. We were able to reproduce this behaviour during our meeting.
    > From a technical point of view, in support of these findings, we also proved sample PCAPs (traffic captures) taken from one of our test CWS proxies for traffic sent from a test Chromebook device both from the browser and standalone apps. Comparing these PCAPs we were able to see that the Proxy-Authorization header was present on browser traffic and missing on standalone app traffic.
    >  
    > 1)    Our first question for the Google Support team is in regards to this difference. Why isn’t the Proxy-Authorization computed by the CWS Chrome Extension applied to Standalone Apps? Is this by design or a Chrome OS bug/defect? We found multiple forum posts complaining of the same issue: Proxy Authorization computed by a chrome extension is not applied to standalone apps.
    > Is there a way we can force the Proxy-Authorization header to apply to standalone apps as well?
    >  
    > As a temporary workaround, during our meeting, we also tried to use another functionality offered by the CWS Chrome Extension (the possibility to whitelist domains) to configure the domains used by the standalone apps to bypass the proxy. This functionality offers our customers the option to define a list of domains and IPs that the CWS Chrome Extension will then set as proxy bypass rules on the Chromebook device.
    > During the meeting, we proved that this functionality works as expected as we were able to add domains via our portal and we saw these domains listed in the proxy bypass list on the Chromebook device.
    > During our meeting, we were able to get dropbox to bypass the proxy. However, HAC app did not work even though we could validate that the domains used by the app were present on the proxy bypass list.
    >  
    > Questions for Google support team:
    > 2)    How can we identify all domains used by a standalone app? Is there a log on the Chromebook where we could see the URLs an app is requesting?
    > 3)    Is there a generic manner (maybe via the Google Admin Console) to configure standalone apps to bypass a proxy? This seems to be possible for Android apps: https://support.google.com/chrome/a/answer/2657289?hl=en(access “Proxy Mode” -> “Android apps running on Chrome OS”) is there a similar solution form Chrome apps?
    > 4)    Why aren’t all domains in the proxy bypass list applied? Is there a limit of how many can be added? Are there any domains that Chromebook proxy bypass functionality would ignore?
    >  
    > We will now have to wait for the Google Support team to get back to us with their findings on the above questions.
    >  
    

Hello!
This bug is receiving this notice because there has been no acknowledgment of its existence in quite a bit of time
- If you are currently working on this bug, please provide an update.
- If you are currently affected by this bug, please update with your current symptoms and relevant logs.

If there has been no updates provided by EOD Wednesday, 12/12/18 (5pm EST), this bug will be archived and can be re-opened at any time deemed necessary.

Thank you!

Due to lack of action this bug has been Archived. If work is still being done on this issue or you are still experiencing this issue please feel free to re-open with the appropriate information.