A Chrome Packaged Application under Windows 10 doesn't seem to be using my public proxy settings under Internet Options. I'm trying to monitor this application's network activity via Fiddler installed on another computer. Every HTTP and HTTPS requests are successfully monitored there, except the ones from this packaged application.
I'm pretty sure it uses HTTP requests behind, because I generated it from an Android APK file, using ARC Welder. And I can see HTTP requests from Android application itself on my phone. But not from generated packaged chrome application on Windows. Is there anything I can do with the manifest file or something else?
Thank you.
chrome.sockets API does not use the Chrome browser proxy settings.
On ChromeOS, chrome.sockets will respect the system-wide VPN settings, however.
Related
I'm trying to determine if I can access any browser api for chrome OS that will allow me to identify the device that its running on when the application has been force-installed in kiosk mode as a PWA.
We're running into exactly the same issue right now. The correct path seems to be to create a PWA and to connect it to a (pre-installed) extension that has access to the enterprise.deviceAttributes:
See https://developers.chrome.com/apps/migration:
"If there is a capability that your Chrome App has that the regular web platform can't provide, it might be available as an extension API. In this case, you use a progressive web app together with an externally connectable extension your web app can send messages to."
enterprise.deviceAttributes are only accessible if the calling App/Site is pre-installed to the device and not loaded dynamically, so it cannot run in the PWA by design.
But with this tutorial, it seems possible:
https://developer.chrome.com/extensions/messaging#external-webpage
We're looking into that right now and will post our progess here.
Background: I have a web app that is accessed via Chrome on a Windows 10 machine.
I also have a native Win10 application installed on the device. The web app sends data to the Win10 application via a local web service running on the machine in IISExpress.
To allow for HTTPS communication on port 44300, I've created a self-signed certificate via PowerShell:
New-SelfSignedCertificate -DnsName "localhost" -CertStoreLocation "cert:\LocalMachine\My" -NotAfter (Get-Date).AddMonths(60)
And then imported it to 'Local Computer\Trusted Root Certificates\Certificates'
From within the web app I send a command to the win10 app that looks something like this:
https://localhost:44300/CMTService.svc/JumpToAssignment?Param=Key=418584577
The win10 app is polling for these requests and picks up the message.
Issue:
Different versions of Chrome behave differently with the acceptance of the self-signed certificate. For instance versions 62, 64 and 75 all accept the certificate and allow for communication with the web service. But other versions of Chrome like 76 and 78 block communication. The Security tab in the Chrome DevTools shows https://localhost:44300 as "Unknown / cancelled" and my requests fail with ERR_SSL_CLIENT_AUTH_CERT_NEEDED. Whereas in working versions of Chrome my URL shows under "Secure origins". The only thing that I change is the Chrome version to get these different results.
I've tried enabling the Chrome setting to allow for invalid certs for localhost (chrome://flags/#allow-insecure-localhost). This temporarily works, but then after closing and reopening chrome, my requests start failing again with the same error code.
If I take one of my failing URLs and paste it into a new Chrome tab, suddenly communication with my native app in my web app resumes as normal. But it only works for that session - when I close and reopen Chrome my communication is broken again.
Question:
How do I allow for communication between my Chrome v78 web app and my local native app?
ERR_SSL_CLIENT_AUTH_CERT_NEEDED means the server is asking the browser for a certificate for client authentication.
You've described how you setup server authentication, but not described how you setup client authentication.
Likely you have enabled certificates for client authentication, but have not configured the web app to send the correct client certificate or have not configured the native app to accept the correct client certificate. That's a very open ended topic to be prescriptive without knowing more about your development efforts, but you can confirm if client authentication is enabled by inspecting a packet capture. One description of the handshake is here : https://blogs.technet.microsoft.com/nettracer/2013/12/30/how-it-works-on-the-wire-iis-http-client-certificate-authentication/.
Just an update: I implemented a javascript workaround to get around my communication issues. When first loading the web app, I simply send my first communication to IIS (destined for Win10 native app) in a separate chrome browser tab. For whatever reason this allows for successful acceptance of the certificate and kick starts the communication with IIS. This is my code to send the command in a new tab and then close it:
var inst = window.open(launchWinAppURL);
if (inst != null) {
window.setTimeout(function() {
inst.close();
}, 1000);
}
This is not the most elegant solution, but it seems to work on all chrome versions, so i'm satisfied.
Is the web app only communicating with the one win10 machine? Have you installed the self-signed cert directly to the machine? I would try installing it directly to the machine and see if the later instances of chrome allow communication.
In my particular network environment the Google chrome executable can access via an authenticated outgoing proxy server external web sites. Other executables however (when pointing to that outgoing proxy) are not able to do so.
I now have the idea to use Chrome itself as a local proxy for other executables like git or pip. - Is this possible, say, with a Chrome extension or with a tool that uses Chrome in a headless mode to connect to the Internet?
To clarify, I am not asking how to configure the proxy settings inside Chrome - I have successfully done this. I am asking how I can set up Chrome to receive HTTP(S) requests from other local programs and pass the requests on as an intermediate proxy (to the outgoing proxy specified in Chrome's settings).
On its own, no: Chrome will not open a port that other software can connect to. Even WebRTC requires an intermediate server to begin a peer to peer connection between browsers.
However Chrome supports Native Messaging, which means it will execute a specific native application that already exists on the system.
With this set up you can have:
a native application that accepts incoming connections and forwards data to the extension.
the extension listens to messages from the application and sends them via Chrome elsewhere on the internet.
1password's chrome extension checks to see if the app is installed on your desktop before you can actually do anything.
I was wondering on how could I implement something similar?
This is probably implemented using the Native Messaging API.
Alternatively, the app can simply have a web server / websockets server open on the local machine, but it would mean the connection will only work while the app is running.
I have a HTML5 webapp which is running perfectly when served via the IIS without authentication.
Is is using a cache.manifest file.
Both when running in safari, and as an "add to homescreen" fullscreen app, once I update the manifest file on the server, and the app will update.
When I turn on authentication on all files except the cache.manifest, then I only see the update when running it in the safari browser.
If I add it to the homescreen, I am not able to make the app update the cache.
If I wireshark the traffic on the server, I can see the manifest file is fetched without problems, but all the files in the manifest file hits a 401 Unautorized error.
Any idea how I can fix this? Running it in the safari browser is working..
Any help is highly appreciated.
Safari is much more aware of HTTP Basic Auth, but web.app (the home screen web app handler, which is basically a UIWebView wrapper) isn't as full-featured and doesn't appear to support basic auth.
It seems you may need to work around this with either a server-side solution to append an authentication key to the filename (such as application.css?longhexkey) to bypass basic auth, or go with a more traditional login form (which may require significant changes to your app)
Same issue on Sencha forums: Unanswered: Forcing re-authentication after offline usage on iOS devices?