I Have a simple back-end app on a Google cloud virtual machine. It receives websocket connections and sends some simple messages to clients. I also have nginx server running on same machine, listening to 443 port and redirecting requests to my application (http://127.0.0.1:8080). Everything is secured by a valid SSL certificate, so requests are made through https:// and wss://.
Now I'm writing Angular front-end application that connects to my server like this:
return webSocket({
url: `wss://www.mydomain.site/${path}`,
closeObserver: {
next: (event: CloseEvent) => { console.log(event) }
}
}).multiplex(() => {}, () => {}, () => true)
When I try to run the code in my browser with AdBlock chrome extension enabled, it thinks that my request to websocket is an ad and blocks it. So my server doesn't even receive Upgrade request and browser logs WebSocket connection to 'wss://mydomain.site/something' failed.
When AdBlock is disabled, everything works fine: Request is sent to my server and incoming messages are received on the browser.
Also, when I try sending request directly to my app and bypassing nginx proxy like this: ws://www.mydomain.site:8080/something, everything works fine with AdBlock enabled.
My website doesn't use ads, so I don't care if users have AdBlock on or off, and asking users to disable AdBlock might be annoying for them and bad for UX.
My question is, what can I do to prevent AdBlock from treating my wss:// request as an ad and blocking it?
My domain is .site, can that be causing this issue ?
Same issue, I was previously using no-ip.com to redirect the websocket using certbot TLS system with domain name, but no-ip was requesting an update every month which is really tedious work for a 8$/mo server hosted on google cloud.
I started using duckdns which doesn't require every month update, and when I investigated for 5 hours why it couldn't connect, it was adblock which doesn't like duckdns.com it seems ...
You can use no-ip if you are not afraid to click "update" every month, or find another service which isn't blocked by adblock :)
Related
I search everywhere I found 0 information about this specific redirect.
I have app that I need to use "HTTP" to function, recently chrome started to redirect my app to HTTPS automatically, and If I put HTTPS to HTTP code in my app it cause infinite loop.
My app is not on the HSTS preload domain list, my app and server have no redirect code to HTTPS.
Request URL: http://4444.com/z.txt
Request Method: GET
Status Code: 307 Internal Redirect (from disk cache)
Referrer Policy: strict-origin-when-cross-origin
Cross-Origin-Resource-Policy: Cross-Origin
Location: https://4444.com/z.txt
Non-Authoritative-Reason: DNS
This does not happen on any other browser other than chrome.
Does that mean chrome is targeting my host's dns to make sure all website hosted on the DNS is HTTPS?
If yes I think this is very bad move from google as I can't find any announcement by google that they will start forcing https on websites. This could break many non https sites without prior warning.
If not what can I do to fix this issue?
Thanks
I encountered the same problem just like you, and that situation didn't happen all the time, sometimes when I open another window as incognito mode, the redirect disappeared!Sooooo Annoying:(
And I just tried another way, it seemed to work fine with me!
go to : chrome://net-internals/#dns, and click Clear host cache , then refresh your page, the redirect will be gone!
Even if the "Always use secure connections" (chrome://settings/security) is disabled, chrome will still try to use HTTPS if it finds HTTPS records in DNS, as per #dns-https-svcb flag - "Support for HTTPS records in DNS" (chrome://flags/#dns-https-svcb) - which is enabled by default.
This causes the loop leading to the ERR_TOO_MANY_REDIRECTS with Non-Authoritative-Reason: DNS.
Either remove any HTTPS record from the host zone file or disable the aforementioned flag from chrome.
Did you access websites using VPN? VPN server seems able to force http to https
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.
How to revive HttpClient and make it see that the network is available again without fully restarting the application?
In case when a Xamarin.Forms app was launched with no network connection available and then later network connection is enabled, HttpClient.SendAsync(request) throws NameResolutionFailure and it does not recover, no matter how many times the request is repeated.
It seems, HttpClient does not know how to recover when network connection appears.
To reproduce the issue in Android emulator:
ensure your app is completely closed
turn network off (set Data status to Roaming in emulator settings or use the status bar to toggle the data or LTE switch).
launch your app, run a web request to verify that it does not work (obviously, you will need try/catch around the web request to avoid crashing)
while the app is still open, enable the network
run a web request - will get NameResolutionFailure
only full application restart will revive HttpClient
The issue does not happen if I use domain names specified in etc/hosts file.
I tried to fully recreate HttpClient and resend a new request when the issue occurs, but that does not help. Only full restart of the app helps.
Obviously, I cannot ask user to fully kill my app and start it again every time when user has turned on his network connection after launching my app.
This is a known issue. See:
Mono: https://bugzilla.xamarin.com/show_bug.cgi?id=45761
iOS: https://bugzilla.xamarin.com/show_bug.cgi?id=45763
Android: https://bugzilla.xamarin.com/show_bug.cgi?id=45383
The workaround is to manually set the DNS refresh:
System.Net.ServicePointManager.DnsRefreshTimeout = 0;
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