In the context of a unit test I need to send some code to the console of a chrome app I am developing. It's clear that I can do that from the chrome.debug API, but is there a way to do that from outside the browser?
Yes, there is a way; if you can do something with chrome.debug you can do so with remote debugging.
You need to enable remote debugging with command line switches; you can then connect to Chrome with a debugger client instance.
Google lists some existing debugger clients, and you can implement your own by following the debugger protocol (which works over HTTP+WebSockets).
The procedure for a debugger client is to request /json from the debugger port over HTTP, which lists all possible debug targets; the client then connects to the WebSocket associated with that target to work with it.
Related
I have a SPA running on my localhost:3000 and my ASP.NET Core 3.1 Web API running on localhost:44372.
I'm trying to debug the SPA from my connected Android Device. I connected the device, did port forwarding, everything is well, SPA gets opened, but then it does a request to Web API and receives CORS error. When I check network tab I see that the origin is https://localhost:3000, which is correct. Does chrome remote debugging mode somehow replace the origin, because everything works well if I open the SPA locally?
I tried to debug Web API project with custom middleware, but I'm unable to hit the breaking point: seems like it returns CORS error before pipeline even started.
Here are my CORS configs in Web API:
builder.UseCors(x => x
.WithOrigins("https://localhost:3000", "http://localhost:3000")
.AllowAnyMethod()
.AllowAnyHeader()
.AllowCredentials())
UPDATE
The CORS errors:
UPDATE 2
I also forwarded the port 44372 which I have the Web API on and the error changed to: net::ERR_CERT_AUTHORITY_INVALID. Is this an issue with the chrome on android? I'm not quite sure how to address it. The issue seems to be with the Web API server certificate, because SPA gets loaded properly.
I managed to solve the issue by opening https://localhost:44372 on the Device. There I got a security warning, but when I chose "proceed to localhost (unsafe)" I was able to reach Web API. Then https://localhost:3000 started working well.
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.
I'd like to make an SSH-based extension for Chrome, but I can't figure out how the secure shell extension is able to access raw sockets in Chrome.
It only has these permissions:
Yet I'm able to connect on port 22 via SSH. I know it uses PNaCl through Enscripten, but how do these provide raw socket access?
Has Google hard-coded whitelabel permission to the sockets API just for this extension?
Secure Shell gets access to raw sockets via (P)NaCl because it has been whitelisted in the Chromium source. ugly, i know.
https://chromium.googlesource.com/apps/libapps/+/master/nassh/doc/hack.md#Whitelisted-Permissions
if you want to do raw sockets in your own Chrome app, you can do so via JavaScript:
https://developer.chrome.com/apps/socket
if you want to access raw sockets from Chrome extensions, or via a PWA, then currently you won't be able to do so. those only have access to WebSockets currently (which is basically HTTP). this is why projects like WebSockify exist.
if you check the manifest, you will see that it has this permission "terminalPrivate".
Then if you poke alittle bit around you will find those posts:
http://chromium.2324630.n4.nabble.com/crx-Use-chrome-terminalPrivate-API-in-chromeOS-extension-app-td17265.html
https://groups.google.com/a/chromium.org/forum/#!topic/chromium-hterm/PtR2q2p_vss
The "good" comments you find on those sites are:
chrome.terminalPrivate exists, but it's native code only available to
the Secure Shell chrome extension, and only on Chrome OS.
Or this one:
chrome.xPrivate APIs are, well, private APIs that are only used by
certain Chrome or Google extensions and applications.
I am trying to get a simple web page server from within a Google Chrome Packaged App. There is already a UDP server running within the app and working without any problems.
I am starting the socket.listen on 0.0.0.0:8080 and copying most of the code from
https://github.com/GoogleChrome/chrome-app-samples/tree/master/webserver
. The same issue is replicated in the sample app.
What I am doing is accepting the request and sending a single HTML file to all requests which have some data in the request (request.data.length > 0). The flow of the app is similar to the sample app with near-equivalent functions.
To test this I am using Socket Test 3.0 (from SourceForge). Creating a socket to 127.0.0.1:8080 and sending it GET / HTTP/1.1 as the content. As intended the Chrome App responds with the html file and correct headers. I can repeat this multiple times without restarting the App. The problem arises when the App is sent a request through Chrome. On first look it works as intended, but then it Time Out on refresh. This is also replicated in the sample app.
On debugging I found that every thing was being handles. The write socket being destroyed and a socket.accept(serverSocket, ...) being issued. I also made sure that it was done inside the callback function of the socket.write. The first request as intended is for the page requested (GET / HTTP/1.1 for localhost:8080). Second was for favicon.ico as GET /favicon.ico HTTP/1.1. And then a third connection with none in data (which is then ignored and socket destroyed). Unlike in the SocketTest where every request was answered back.
I have created a video showing the screencast while reproducing the error on YouTube. Also the repo for the project that I'm working on is at GitHub.
I had the same issues with Google's sample web server. I wrote a more robust socket server app that does not hang. The source is on GitHub at https://github.com/kzahel/web-server-chrome and you can install it from the Chrome web store at https://chrome.google.com/webstore/detail/web-server-for-chrome/ofhbbkphhbklhfoeikjpcbhemlocgigb