What I'm trying should be basic; but must be missing something. Have couple of SignalR Hubs defined inside an MVC3 app running locally. Same solution has a Windows Phone 8 & a Windows Store app, both talking to the SignalR hubs for real-time communication. SignalR server uses latest bits & clients use latest .NET nuget.
On the client side, this is what I'm used to writing:
IHubProxy SignalRChatHub;
HubConnection chatConnection = new HubConnection("http://localhost:53478/");
SignalRChatHub = chatConnection.CreateHubProxy("ChatHub");
await chatConnection.Start();
if (chatConnection.State == Microsoft.AspNet.SignalR.Client.ConnectionState.Connected)
{
// Stuff here.
}
This works perfectly fine with a Windows 8 app client & we have easy connectivity with the SignalR hub running locally on IIS. However, the same code does not work for a Windows Phone client. The connection.start() bombs out with a 404 exception.
After a little research, it looks like the WP Emulator VM is treated as a different machine and uses the host machine's network virtually. So, IIS may be blocking calls from outside not allowing reach into the SignalR hub from Windows Phone 8 app. Accordingly, I tweak applicationhost.config for the SignalR server app to allow connectivity from outside localhost. So now, the SignalR hub is functional from both localhost and also off the local IP. Also, the routing has been changed to allow cross-domain SignalR connectivity in Global.asax.cs:
RouteTable.Routes.MapHubs(new HubConfiguration() { EnableCrossDomain = true });
The Windows Phone client code is changed to:
HubConnection chatConnection = new HubConnection("http://<LocalIP>:53478/");
But this continues to fail the connection.start() with a "Remote server returned an error: Not Found" exception. I have Fiddler sniffing network traffic from the phone emulator and shows absolutely nothing in response to the connection.start() call.
What am I missing? Any pointers would be helpful .. thanks!
Figured it out myself. Turns out the SignalR connectivity issue from the WPDev emulator was actually due to IIS/Windows security. Little more IIS config & opening local ports through Windows Firewall fixed the problem. Will blog about it; but these two posts helped:
http://msdn.microsoft.com/en-us/library/windowsphone/develop/jj684580.aspx
https://blogs.iis.net/robert_mcmurray/archive/2013/08/20/connecting-the-windows-phone-8-emulator-to-web-api-applications-on-a-local-computer.aspx
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.
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'm trying to detect whether a connection is available on my Sencha Touch+PhoneGap app that's running on Windows Phone 8. Problem is, any check I make (using both Ext.device.Connection.isOnline() from Sencha and navigator.network.connection from PhoneGap) results in the state of the connection when the app was launched. I do have ID_CAP_NETWORKING checked on WMAppManifest.xml, by the way.
So if I launched the app while there was no connection, Ext.device.Connection.isOnline() and navigator.network.connection will both always say that there is no connection, even if I get a connection while the app is running. If I launched the app while there was a connection, even if I lose the connection the calls will always say that there is a connection.
I have a hack for this (using simple ajax calls and seeing if they fail), but it's definitely not a great solution. Has anyone else encountered this problem? I have limited understanding of this part of mobile development and really don't even know where to start.
I have a website that works correctly under IIS 6.0: It authenticates users with windows credentials, and then when talking to the service that hits the DB, it passes the credentials.
In IIS 7.0, the same config settings do not pass the credentials, and the DB gets hit with NT AUTHORITY\ANONYMOUS.
Is there something I'm missing? I've turned ANONYMOUS access off in my IIS 7.0 website, but I can't get the thing to work.
These are the settings that I'm using on both IIS 6.0 and 7.0:
<authentication mode="Windows">
<identity impersonate="true">
What changed from 6.0 to 7.0?
There has been changes between IIS7 and IIS6.0. I found for you one blog post that might actually help you (click here to see it).
Are you running your application in Integrated Mode or in Classic Mode? From what I saw, putting the Impersonate attribute at true should display you a 500 error with the following error message:
Internal Server Error. This is HTTP
Error 500.19: The requested page
cannot be accessed because the related
configuration data for the page is
invalid.
Here is the workaround that is proposed:
Workaround:
1) If your application does not rely
on impersonating the requesting user
in the BeginRequest and
AuthenticateRequest stages (the only
stages where impersonation is not
possible in Integrated mode), ignore
this error by adding the following to
your application’s web.config:
<validation validateIntegratedModeConfiguration="false"
/>
2) If your application does rely on
impersonation in BeginRequest and
AuthenticateRequest, or you are not
sure, move to classic mode.
I hoped that was useful to understand how IIS 7.0 now works.
Is your IIS server set up to be trusted for delegation by the SQLServer? I've run into this before with WebDAV where we've had to have the server running IIS trusted by the file server to authenticate on the file server's behalf.
Interesting... I have the opposite problem - Not being able to get the authentication to be passed from the client browser, through the webserver and onto the database within a large corporate network over firewalls.
I also feel that "end to end user" authentication to the database is a bad idea and a potential security risk. There is nothing to stop the end user from loading up SQL Query and connecting directly to your database, so you'd better have your schema locked down!
#Esteban - Clarified my not very useful in helping you answer.
Typically if you are doing double hop authentication like this, Kerberos is typically involved unless the first authentication is Basic.
I would check the authentication on the IIS 6 servers and make sure that it's the same on IIS 7.
If the IIS 6 box is set to Windows Integrated, then you need to verify the kerberos settings - SPNs, Delegation etc.