The below piece of code works fine UWP,
<WebView Source="https://www.microsoft.com/" VerticalAlignment="Stretch" Grid.Row="1" />
but fails in WASM with the below error. Is there needs to be done differently for WASM? Is there way a UNO app can be CORS enabled to be consumed in the WebView?
dotnet.js:1 Mixed Content: The page at 'https://localhost:44342/' was
loaded over HTTPS, but attempted to connect to the insecure WebSocket endpoint 'ws://[fe80::21ca:fecc:e7b9:44ae]:64237/rc'.
This request has been blocked; this endpoint must be available over WSS.
The WebView control is not yet supported on WebAssembly.
Related
I'm trying to connect to play.google.com in my website iframe and I'm receiving this error:
Refused to frame 'https://play.google.com/' because an ancestor violates the following Content Security Policy directive: "frame-ancestors https://play.google.com".
Am I missing some thing??
Here is the code:
Here is the error:
Can I do something so that I can work?
The code reference which I took from google is here.
I was trying to render the iframe after using Android Management API. What I was expecting is when I open the url directly in new tab then it's working but when I try to open in iframe it's not working. It should work in iframe!
This problem can occur when you render the Managed Configurations iframe over an ‘http’ (unsecure) connection. I suggest you embed your iframe with an ‘https’ (secure) connection to prevent cross-site scripting attacks. I tested this locally, and swapping to ‘https’ resolved the issue in my tests.
I have a Blazor Server app. When I run the app in Visual Studio, I see this message in the Browser console:
WebSocket connected to wss://localhost:44329/_blazor?id=HX5t9UdbZwj35PkMxV3Fkw.
So it looks to me like SignalR is working as expected. On the Network Tab, I see signalR working as expected with message:
However, now I publish the App to IIS. The app works fine. However, if I look in the browser console, I no longer see WebSocket being connected. What I see in the network tab looks like this:
Request URL: https://blazor/_blazor?id=O_acVtnuEIOjlRAosu1YFg
Request Method: POST
There are many many of these like 1 per second.
So it looks like SignalR is no longer being used.
Why is this? What do I need to do to ensure SignalR is being used?
Make sure WebSockets has been enabled on IIS. Here is a brief overview:
https://learn.microsoft.com/en-us/iis/get-started/whats-new-in-iis-8/iis-80-websocket-protocol-support
I have an ASP.NET MVC 4 app (.NET 4.5) and SIgnalR works fine with forms-based authentication (hosted via IIS/IIS Express)
As soon as I change the app to windows-integrated authentication (<authentication mode="Windows"/> in "web.config") it stops working.
jquery.signalR-2.2.2.min.js:9 WebSocket connection to ws://localhost:51030/signalr/connect?transport=webSockets&blhablahblah failed: Error during WebSocket handshake: Unexpected response code: 403
After adding the [Authorize] attribute to my hub, the error changes to
WebSocket connection to ws://localhost:51030/signalr/connect?transport=webSocketsblahblah failed: HTTP Authentication failed; no valid credentials available
Other parts of the app are working just fine, windows-auth is enabled on the server and works, etc. etc.
How do I solve this?
And if it is unsolvable for some reason (it could be Chrome not supporting windows auth on websocket connections or something else) - why doesn't it fall back to non-websocket protocol? and how do I force the fallback?
UPDATE: I created a github issue https://github.com/SignalR/SignalR/issues/3953. The problem is not that I can't connect. The problem is that I cannot handle the error to fall back to another transport. Neither .fail() not .error() are being invoked. Try-catch doesn't help either.
Update from 2020: looks like Chrome now supports NTLM on WS-connections, not an issue any more
...10 hours later after asking the question...
Partially solved (answering my own question)
After playing with it I can confirm, that adding the [Authorize] attribute to my hub (or alternatively, adding GlobalHost.HubPipeline.RequireAuthentication(); to your "Startup.cs") actually does help. It does fall back now to an alternative transport, even though the error is still thrown into the browser's console.
You can also specify which transport it falls back to, by calling:
$.connection.hub.start( { transport: ['webSockets', 'longPolling'] });
in case you don't like the default priority (I guess, "hidden iframe" is the default second option).
The reason
The error is caused by Chrome, it does not support NTLM on websocket connections. Funny enough, IE, MS Edge and Firefox do support it ("Chrome is the new IE" huh).
There's an open issue in Chromium bugtracker for this here https://bugs.chromium.org/p/chromium/issues/detail?id=423609 if anyone wants to add any input to Chromium devs.
I too was experiencing this error, but only when developing locally using http; I think Chrome doesn't like unsecured ws:// connections. Once I deployed to server with secure https connection, the WebSocket connection was upgraded to wss://, and Chrome stopped complaining, worked fine with WebSockets--didn't have to fall back to other transport.
tl:dr; Make sure to use https for your site.
I'm currently deploying a spring boot 1.5.1 application to pivotal cloud foundry. The Apps manager is displaying the Spring icon but i cant configure the log level or see any of the settings. I'm getting a browser 'mix content exception'. Apps manager is trying to access /cloudfoundryapplication/info over http instead of https and the browser is blocking the request. Is there a setting to force Apps manager to only use https?
Our team encountered a similar issue. We feel it has nothing to do with the apps manager but rather as to how our app behaves.
In our case we had a bad configuration which was causing the URLS getting built as http when httpRequest.getScheme() was being called.
server.tomcat.internal-proxies: <ips other then your proxy>
Correcting this property in our case by letting it to default as defined here let the getScheme to be returned as https and there by when the call being made to /cloudfoundryapplication/info the scheme got built as https.
Also another suggestion made by one of our colleague which also resolves this issue but would not address the root cause is - fronting your application(highest precedence) with ForwardedHeaderFilter - this causes the X-FORWARDED-* headers to be available in your httpServletResquest as described here
Trying to upload a media (video / image) for iphone and android, from one domain using HTTPs to another HTTP. Cant change both to a single protocol as both have different environments which cant be changed apparently.
Everything's working fine on iOS but Android is not doing the uploading thing.
Getting following error on Android chrome :
Mixed Content: The page at 'https://*****' was loaded over HTTPS, but requested an insecure XMLHttpRequest endpoint 'http://*****'. This request has been blocked; the content must be served over HTTPS.
When the main page is https, then insecure (http) request are mostly blocked.
The best way to avoid mixed content errors is to use https for everything.