I'm making an application using SignalR.
The Hub is placed on one server running Windows Server 2012 with IIS 8.
http://mentor.cloudapp.net/mass/rexona/previa/signalr/hubs.
The client is here:
http://massdeveloperstage.com/Rexona/Site/colombia/Previa/Match?matchId=6F318A29-3400-444B-95D9-7EC41A7AD2D4
The Signalr set up looks like this:
var match;
$(document).ready(function () {
$.connection.hub.loging = true;
match = $.connection.match;
match.client.addMessage = function (message) {
var vm = {
avatar: message.ProfileImageLocation,
content: message.Text,
user: message.UserScreenName,
obj: JSON.stringify(message)
};
alert(vm.obj);
}
$.connection.hub.url = 'http://mentor.cloudapp.net/mass/rexona/previa/signalr';
$.connection.hub.start().done(function () {
match.server.addToGroup("97-987-PP");
}).fail(function () {
//alert("fail!");
});
Everything works perfectly in Chrome, FF, Opera and in IE10, but when it's accessed using IE9 the application fails.
Am I missing something in the set up of the connection? Do I need to enable something else on the server in order to work with IE9?
Thanks.
I think you're trying to do CORS (Cross-Site Origin Sharing) there. It doesn't work quite like that with IE9, check this for detailed discussion, and microsoft page for the exact limitations. It is done with XDomainRequest custom object instead of XMLHttpRequest, and...
The target URL must be accessed using the HTTP or HTTPS protocols
The target URL must be accessed using only the HTTP methods GET and POST
No custom headers may be added to the request
Only text/plain is supported for the request's Content-Type header (no soap, json or encoded data types!)
No authentication or cookies will be sent with the request
Requests targeted to Intranet URLs may only be made from the Intranet Zone
Requests must be targeted to the same scheme as the hosting page
Edit: I haven't actually ever used SignalR myself, this answer was based on CORS in general. According to a comment by #stricq, IE needs long polling enabled for this to work with SignalR, as explained in here.
Related
I am trying to make an API call via Office Scripts (fetch) to a publicly available Azure Function-based API I created. By policy we need to have CORS on for our Azure Functions. I've tried every domain I could think of, but I can't get the call to work unless I allow all origins. I've tried:
https://ourcompanydoamin.sharepoint.com
https://usc-excel.officeapps.live.com
https://browser.pipe.aria.microsoft.com
https://browser.events.data.microsoft.com
The first is the Excel Online domain I'm trying to execute from, and the rest came up during the script run in Chrome's Network tab. The error message in office Scripts doesn't tell me the domain the request is coming from like it does from Chrome's console. What host do I need to allow for Office Scripts to be able to make calls to my API?
The expected CORS settings for this is: https://*.officescripts.microsoftusercontent.com.
However, Azure Functions CORS doesn't support wildcard subdomains at the moment. If you try to set an origin with wildcard subdomains, you will get the following error:
One possible workaround is to explicitly maintain an "allow-list" in your Azure Functions code. Here is a proof-of-concept implementation (assuming you use node.js for your Azure Functions):
module.exports = async function (context, req) {
// List your allowed hosts here. Escape special characters for the regular expressions.
const allowedHosts = [
/https\:\/\/www\.myserver\.com/,
/https\:\/\/[^\.]+\.officescripts\.microsoftusercontent\.com/
];
if (!allowedHosts.some(host => host.test(req.headers.origin))) {
context.res = {
status: 403, /* Forbidden */
body: "Not allowed!"
};
return;
}
// Handle the normal request and generate the expected response.
context.res = {
status: 200,
body: "Allowed!"
};
}
Please note:
Regular expressions are needed to match the dynamic subdomains.
In order to do the origin check within the code, you'll need to set * as the Allowed Origins on your Functions CORS settings page.
Or if you want to build you service with ASP.NET Core, you can do something like this: https://stackoverflow.com/a/49943569/6656547.
I am trying to authenticate an app with Azure AD. It's all good in localhost, it redirects to Azure AD where I enter details to authenticate, and it sends back the token that allows to view the resource.
Everything managed behind the scenes with the Microsoft.AspNetCore.Authentication.AzureAD.UI 3.1.10 in an aspnetcore 3.1 application.
My app runs on http://localhost:5000 and I can configure the redirectUri/replyUri at Azure AD for that application to support this url. All good.
The problem is in a different environment when my app runs in a service fabric cluster.
I can see the problem
AADSTS50011: The reply URL specified in the request does not match the reply URLs configured for the application
When I inspect the url I can see that the redirect_uri has some url like this http://12.12.12.12/signin-oidc
The problem is double here. First of all I don't know which IP the cluster is gonna assign. Second, it is http, not https, and that's not supported by Azure AD.
Luckily my app has an external Url with a reverse proxy I can use to access. Something like https://myservicefabriccluster.com/MyApp
That Url I could configure as my redirect_uri in both my application and Azure AD, but I don't know how to do so.
My code has something like this:
services
.AddAuthentication(AzureADDefaults.AuthenticationScheme)
.AddAzureAD(options => Configuration.Bind("AzureAd", options));
where I bind my settings.
"AzureAd": {
"Instance": "https://login.microsoftonline.com/",
"ClientId": "76245c66-354e-4a94-b34d-...",
"TenantId": "59c56bd4-ce18-466a-b515-..."
},
I can see the AzureADOptions supports some other parameters such as Domain (not needed) or CallbackPath (which by default is ok being /signin-oidc) but there is nothing similar to ReplyUrl or RedirectUri where I can specify an absolute URL as the callback.
I have found a few similar issues without an answer. Others suggest some kind of tricks like a middleware that rewrites that parameter just before redirecting to Azure AD.
Certainly there must be an easier way to deal with this problem that I expect is not so strange. Any help please?
The solution to overwrite redirect_uri parameter with a custom value is to use the Events available in OpenIdConnect library. This library should be available as it's a dependency for Microsoft.AspNetCore.Authentication.AzureAD.UI, so this is my solution that, in addition to the standard properties for AzureADOptions it adds a flag to determine whether the redirect uri must be overwritten and a value to do so. I hope it's self explanatory
services
.AddAuthentication(AzureADDefaults.AuthenticationScheme)
.AddAzureAD(options => configuration.Bind("AzureAd", options));
var isCustomRedirectUriRequired = configuration.GetValue<bool>("AzureAd:IsCustomRedirectUriRequired");
if (isCustomRedirectUriRequired)
{
services
.Configure<OpenIdConnectOptions>(
AzureADDefaults.OpenIdScheme,
options =>
{
options.Events =
new OpenIdConnectEvents
{
OnRedirectToIdentityProvider = async ctx =>
{
ctx.ProtocolMessage.RedirectUri =
configuration.GetValue<string>("AzureAd:CustomRedirectUri");
await Task.Yield();
}
};
});
}
services
.AddAuthorization(
options =>
{
options.AddPolicy(
PolicyConstants.DashboardPolicy,
builder =>
{
builder
.AddAuthenticationSchemes(AzureADDefaults.AuthenticationScheme)
.RequireAuthenticatedUser();
});
});
And the appsettings.json would have something like this:
"AzureAd": {
"Instance": "https://login.microsoftonline.com/",
"ClientId": "76245c66-354e-4a94-b34d-...",
"TenantId": "59c56bd4-ce18-466a-b515-..."
"IsCustomRedirectUriRequired": true,
"CustomRedirectUri": "https://platform-cluster-development01.cubictelecom.com:19008/Scheduler/WebApi/signin-oidc"
},
Notice the IsCustomRedirectUriRequired and CustomRedirectUri are my custom properties that I read explicitly in order to overwrite (or not) the redirect uri query parameter when being redirected to the identity provider (i.e: Azure AD)
Looking at this, you should be configuring the public URL as the redirect URI, which is a value such as this:
https://myservicefabriccluster.com/MyApp
It looks like that the above library does not easily support this, and forces the redirect URI to be based on the HTTP listening URL of the code. As part of resolving this it is worth considering how you are writing your code:
This line of code indicates that your app is limited to only ever working with Azure AD:
- services.AddAzureAD
This line of code would ensure that your code works with both AzureAD and any other Authorization Server that meets the Open Id Connect standard:
- services.AddOpenIdConnect
The latter option also has an Events class with a commonly used OnRedirectToIdentityProvider operation that you can use to override the CallbackPath and provide a full RedirectUri.
Azure AD endpoints are standards based so you do not strictly have to use AzureAD specific libraries. Out of interest, I have a Single Page App Azure code sample that uses a neutral library like this, so I know this technique works.
I'm having incredible difficulty setting up the Twilio Client in Meteor JS, and would really appreciate any help.
I have extracted the relevant code and error logs below. So far as I can tell, it should be simple. The code is just grabbing an authtoken which I have previously generated, and then trying to set up the device using that authtoken. But it's not working.
'click #initializeDevice'(event) {
var thisAuthToken = Session.get('myAuthToken');
console.log(thisAuthToken); // I have confirmed with Twilio support that these authtokens are correctly generated
const Device = require('twilio-client').Device;
Device.setup(thisAuthToken, { debug: true });
var myStatus = Device.status()
console.log(myStatus); //this is logging "offline"
Device.on('ready',function (device) {
log('Twilio.Device Ready!'); //this is not logging anything
});
},
When that code runs, it generates the following logs:
eyJhbGciDpvdXRnb2luZz9hcHBTaWQ9QVA2NDE2MzJmMzA1ZjJiY2I[Note:I have deleted part of the middle of the logged authtoken for the purpose of this public post]5YmMxOGQyOWVlNGU2ZGM0NjdmMzRiNDVhNCIsImV4cCI6MTU3Nz0ygbJKTx15GgNCWDkm-iUPjn_O1NZU6yovp4vjE
modules.js?hash=69069bec9aeba9503ae3467590cf182be57d9e62:3605 Setting up VSP
modules.js?hash=69069bec9aeba9503ae3467590cf182be57d9e62:3605 WSTransport.open() called...
modules.js?hash=69069bec9aeba9503ae3467590cf182be57d9e62:3605 Attempting to connect...
modules.js?hash=69069bec9aeba9503ae3467590cf182be57d9e62:3605 Closing and cleaning up WebSocket...
modules.js?hash=69069bec9aeba9503ae3467590cf182be57d9e62:3605 No WebSocket to clean up.
modules.js?hash=69069bec9aeba9503ae3467590cf182be57d9e62:3605 Could not connect to endpoint: ws does not work in the browser. Browser clients must use the native WebSocket object
modules.js?hash=69069bec9aeba9503ae3467590cf182be57d9e62:3605 Closing and cleaning up WebSocket...
modules.js?hash=69069bec9aeba9503ae3467590cf182be57d9e62:3605 No WebSocket to clean up.
calltemplate.js:31 offline
I'm doing this all from a local server, tunneled through NGROK. I've also set up the Twilio back end, linked the app, purchased a number, etc.
So far as I can tell, the issue, from the logs, appears to be something to do with the way that Meteor uses WebSockets.
Could not connect to endpoint: ws does not work in the browser. Browser clients must use the native WebSocket object
This is a not a Meteor related problem rather than browser issue.
Make sure your browser supports WebRTC
BTW, Your browser might be supporting it but you'd need to enable it.
IS there a way to trick the server so I don't get this error:
Content was blocked because it was not signed by a valid security certificate.
I'm pulling an iframe of an html website into another website but I keep getting the console (chrome) error in the title of this question and in internet explorer it says:
Content was blocked because it was not signed by a valid security certificate.
Your resource probably use a self-signed SSL certificate over HTTPS protocol.
Chromium, so Google Chrome block by default this kind of resource considered unsecure.
You can bypass this this way :
Assuming your frame's URL is https://www.domain.com, open a new tab in chrome and go to https://www.domain.com.
Chrome will ask you to accept the SSL certificate. Accept it.
Then, if you reload your page with your frame, you could see that now it works
The problem as you can guess, is that each visitor of your website has to do this task to access your frame.
You can notice that chrome will block your URL for each navigation session, while chrome can memorise for ever that you trust this domain.
If your frame can be accessed by HTTP rather than HTTPS, I suggest you to use it, so this problem will be solved.
Sometimes Google Chrome throws this error, even if it should not.
I experienced it when Chrome had a new version, and it needed to be restarted.
After restarting the same page worked without any errors.
The error in the console was:
net::ERR_INSECURE_RESPONSE
I still experienced the problem described above on an Asus T100 Windows 10 test device for both (up to date) Edge and Chrome browser.
Solution was in the date/time settings of the device; somehow the date was not set correctly (date in the past). Restoring this by setting the correct date (and restarting the browsers) solved the issue for me. I hope I save someone a headache debugging this problem.
Offering another potential solution to this error.
If you have a frontend application that makes API calls to the backend, make sure you reference the domain name that the certificate has been issued to.
e.g.
https://example.com/api/etc
and not
https://123.4.5.6/api/etc
In my case, I was making API calls to a secure server with a certificate, but using the IP instead of the domain name. This threw a Failed to load resource: net::ERR_INSECURE_RESPONSE.
open up your console and hit the URL inside. it'll take you to the API page and then in the page accept the SSL certificate, go back to your app page and reload.
remember that SSL certificates should have been issued for your Dev environment before.
If you're developing, and you're developing with a Windows machine, simply add localhost as a Trusted Site.
And yes, per DarrylGriffiths' comment, although it may look like you're adding an Internet Explorer setting...
I believe those are Windows rather than IE settings. Although MS tend to assume that they're only IE (hence the alert next to "Enable Protected Mode" that it requries restarted IE)...
Try this code to watch for, and report, a possible net::ERR_INSECURE_RESPONSE
I was having this issue as well, using a self-signed certificate, which I have chosen not to save into the Chrome Settings. After accessing the https domain and accepting the certificate, the ajax call works fine. But once that acceptance has timed-out or before it has first been accepted, the jQuery.ajax() call fails silently: the timeout parameter does not seem help and the error() function never gets called.
As such, my code never receives a success() or error() call and therefore hangs. I believe this is a bug in jquery's handling of this error. My solution is to force the error() call after a specified timeout.
This code does assume a jquery ajax call of the form jQuery.ajax({url: required, success: optional, error: optional, others_ajax_params: optional}).
Note: You will likely want to change the function within the setTimeout to integrate best with your UI: rather than calling alert().
const MS_FOR_HTTPS_FAILURE = 5000;
$.orig_ajax = $.ajax;
$.ajax = function(params)
{
var complete = false;
var success = params.success;
var error = params.error;
params.success = function() {
if(!complete) {
complete = true;
if(success) success.apply(this,arguments);
}
}
params.error = function() {
if(!complete) {
complete = true;
if(error) error.apply(this,arguments);
}
}
setTimeout(function() {
if(!complete) {
complete = true;
alert("Please ensure your self-signed HTTPS certificate has been accepted. "
+ params.url);
if(params.error)
params.error( {},
"Connection failure",
"Timed out while waiting to connect to remote resource. " +
"Possibly could not authenticate HTTPS certificate." );
}
}, MS_FOR_HTTPS_FAILURE);
$.orig_ajax(params);
}
This problem is because of your https that means SSL certification. Try on Localhost.
I am using SignalR-1.0.0-rc2.
I am using cross domain SignalR because some browsers on mobile devices still only allow two connections per domain. So I have one domain for SignalR and one for the web. Server-side, they are both the same.
My implementation works for Opera, Firefox, Chrome, Safari, and IE10. It does not work for IE9, IE8 and IE7.
jQuery.support.cors = true;
var connection = $.connection.globalHub;
$.connection.hub.url = SignalRDomain;
$.connection.hub.logging = true;
$.connection.hub.qs = "UserID="+UserID+"&Login="+UserLogin+"&UserHash="+UserHash;
connection.client.MyLocalFunction = function () {
// do something
}
$.connection.hub.start();
I have logging turned on. The IE9/8/7 consoles show me two SignalR trace messages:
[13:54:37 UTC+0100] SignalR: Auto detected cross domain url.
[13:54:37 UTC+0100] SignalR: Negotiating with 'http://live.mydomain.de/signalr/negotiate'.
If I look in the "Network"-tab of the debugger I don't see that any call to the server is made. So it seems that SignalR just dies after that debug message.
Any ideas?
So here's the reason why the request is failing: IE9 jQuery AJAX with CORS returns "Access is denied"
You can fix this issue by removing the line "jQuery.support.cors = true".
For SignalR 1.0.0-rc2 it will just work, however for all versions of SignalR 1.0.0 and above you will need to enable cross domain in your map hubs call: SignalR cross domain not working on browsers other than IE10