Using the angular 2 debug server, I proxy requests to the real server using proxy.config.js. It seems that the ng2-signalr library does not respect the proxy configuration, and will attempt requests to whatever was defined as url in the IConnectionOptions used.
for the following request:
GET
localhost:4200/signalr/negotiate?clientProtocol=2.1&user=client&connectionData=%5B%7B%22name%22%3A%22compilationhub%22%7D%5D&_=1557816148076
the following error is produced:
Cross origin requests are only supported for protocol schemes: http, data, chrome, chrome-extension, https
What would be the best course of action?
I got this working by adding the signalr route to proxy.config.js and setting the url property of my IConnectionOptions to location.origin. This setup bypasses the default route of /signalr so that a double forward slash route is not used.
Related
I've configured a rewrite rule in IIS to basically rewrite the request from http://mydomain to http://mydomain/subfolder/mywebservice.asmx and I can verify that the rewrite triggers and rewrites correctly.
However the problem is that once it's rewritten I get an IIS error "The file extension for the requested URL does not have a handler configured to process the request on the Web server."
When I navigate directly to http://mydomain/subfolder/mywebservice.asmx it works and the .asmx extension is handled correctly.
What am I missing?
I was missing the Application Request Routing extension. All that was required was to install ARR, then enable the proxy and the rewrite rules started resolving properly.
https://www.iis.net/downloads/microsoft/application-request-routing
In my Rails app I use both Rails' native form_tag method and the simple_form_for method provided by the simple_form rubygem.
Both of them are leading to the following warning in the chrome console:
Mixed Content: The page at 'https://example.com' was loaded over a secure connection, but contains a form which targets an insecure endpoint 'http://example.com'. This endpoint should be made available over a secure connection.
And indeed, the rendered HTML forms use the http protocol for their action attribute.
What is the reason for that? All my other URL's use the https protocol.
You have not correct protocol set up for your environment.
Your server is running on HTTPS and form creates HTTP URL.
You need to tell your URL helpers to build the URLs with the same protocol as your server is running for your environment.
Development should run on HTTP, staging should be HTTPS and production as well HTTPS.
There are different ways how to do it. The best is to set protocol in your environment config file. So place this line:
Rails.application.routes.default_url_options[:protocol] = 'https'
into your environment config file like production.rb and staging.rb.
Another approach is to set the default protocol per controller action. Check this one for more info.
In case you are using the mailer, also check your mailer protocol settings. As described here.
I installed TFS 2017 to be accessible on both, HTTP (port 8080, default settings) and HTTPS. Now I removed HTTP binding form the IIS and reapplied the Public URL (via Administration Console -> Change Public URL).
Most of the TFS application tier works normally (as it uses relative addressing). However, build extensions somehow want to get their icons from HTTP (port 8080). See screenshot. When I noticed this, I first checked the HTML/JS source and I found that _vssPageContext variable still holds some URLs pointing to old HTTP configuration.
Has anyone solved that mistery or has any idea what to do?
EDIT: Later I re-enabled the HTTP bindings in IIS just to make the TFS work and I get a lot of warnings and errors due to HTTP / HTTPS mixup (I access TFS via HTTPS, however some content is still accessed via HTTP):
Mixed Content: The page at
'https://xxxx.xxxxx.xxxx/tfs/TFSDefault/Project/_build/definitionEditor?definitionId=113&_a=simple-process'
was loaded over HTTPS, but requested an insecure image
'http://xxxx.xxxxx.xxxx:8080/tfs/TFSDefault/_apis/distributedtask/tasks/9fcb05af-0ffe-4687-99f2-99821aad927e/0.1.1305/icon'.
This content should also be served over HTTPS.
WebSocket connection to
'ws://xxxx.xxxxx.xxxx:8080/tfs/signalr/connect?transport=webSockets&clientProtocol=1.5&contextToken=412c3608-de3b-4dab-a00d-bf5c13728d97&connectionToken=OoSymcl1qzWg%2BrHB9pzSBpb%2BdHVywo7NNUWN5xMx3Z51p9ZdZQ14wvoQKXqxB%2Bvo66eTap4iUdlqzHR1hJNUf%2By8oFUaudlkCbQIZjHQhLBHsEWtcLdfLlL7MAevl4h0My1yQA%3D%3D&connectionData=%5B%7B%22name%22%3A%22builddetailhub%22%7D%5D&tid=7'
failed: HTTP Authentication failed; no valid credentials available.
This is an issue related to the default endpoint of TFS being initially set as http, which all the elements are then defaulting their requests to, rather than relying on the initial request you are making in the browser. so you end up with a javascript element attempting to connect to the server via http and get a cross content issue.
Here is a really good article that covers the issues you are probably facing and how to fix them to use https: https://hybriddbablog.com/2017/12/16/changing-tfs-to-use-https-update-your-agent-settings-too/
I have to caveat that I havent done this yet, we actually went back in favour of running http until we moved to the next version of TFS, but from my experience of TFS, the steps look sound.
I have an app in facebook developer.
This app is configured with a "Valid OAuth redirect URIs"-value with a URL with https.
But when I click on the Login with facebook button on my page facebook redirects me to the http version of the URI. This seems like a facebook bug in their OAuth module?
I had exactly this issue when I deployed to an AWS Elastic Beanstalk environment with SSL terminated at the load-balancer. In this case, the request received from the load-balancer by the server looks like the client is connecting with HTTP, and the OWIN providers incorrectly infer that the URL Facebook/Twitter/Google needs to connect back into your site should use HTTP instead of HTTPS on the public side of the load-balancer.
I couldn't find a simple solution to this, there didn't seem to be any parameters to override the URI protocol which gets stored in the IOwinRequest.Scheme property. In the end, I grabbed the source code for the Katana project, and the source code for the ASP.NET Identity project, and I hacked it around a bit so that I had local projects in my solutions for:
Microsoft.AspNet.Identity.Core
Microsoft.AspNet.Identity.EntityFramework
Microsoft.AspNet.Identity.Owin
Microsoft.Owin.Security.Cookies
Microsoft.Owin.Security.Facebook
Microsoft.Owin.Security.Google
Microsoft.Owin.Security.OAuth
Microsoft.Owin.Security.Twitter
There was 50 or so other projects within Katana that I left out - I made all of these other dependencies Nuget package references to the official versions.
Then I found every reference to IOwinRequest.Scheme, and I replaced it with a snippet of code that also looked for the X-Forwarded-Proto header that is injected by the load-balancer when using SSL offloading.
Something like this:
var scheme = Request.Scheme;
if (string.Equals(Request.Headers["X-Forwarded-Proto"], "https", StringComparison.InvariantCultureIgnoreCase))
{
scheme = "https";
}
// Use the scheme in the construction of a URI...
If your load-balancer or proxy server doesn't provide the X-Forwarded-Proto header, then your options are pretty limited. You could re-encrypt the traffic and send it on to your server using the same protocol it came in on.
I have enabled SSL in my MVC website for IIS Express by setting 'Enable SSL' in the project properties to true. So now I can access my site while debugging over http as well as https (IIS Express's default port 44300). However I'd like to force the default URL to be the SSL one. https://localhost:44300/. Whenever I run the app. from VS it always loads the http URL.
If I try and update the project URL (right click on the project -> click on properties -> navigate to the web tab -> set project URL to https://localhost:44300/) to https, the website fails to load. I just get a 'Page could not be loaded' error in the browser. However if I explicitly add a binding for https to port 44300 in my local IIS instance using IIS Management service it seems to work. I don't think I should have to touch local IIS in any way though.
Am I missing something here? Could someone help me figure this out?
The core of this seems to be finding the applicationhost.config file being passed to IIS, find the section like
<bindings>
<binding protocol="http" bindingInformation="*:62858:localhost" />
and change http to https
If you're using the Rider IDE, open the project properties (right click on solution explorer's icon for the project).
Make sure you add a port number for "SSL" and switch the Url from http://... to https://...
The port must be between 44300 and 44398, otherwise you'll get a connection reset error (see https://stackoverflow.com/a/24957146/423033 )
Sudeep,
If you are using the IIS on your machine (or on your server) you could create a rewrite rule that would intercept any http requests and will replace the http protocol with https.
Here is a link to get you started: http://www.iis.net/learn/extensions/url-rewrite-module/creating-rewrite-rules-for-the-url-rewrite-module
As for IIS Express, it has its advantages of using it, but on the other side it is missing advanced functionality like URL Rewrite (check this link: http://weblogs.asp.net/scottgu/introducing-iis-express).
Best Regards,
Daniel D.
Figured it out. This tutorial is perfect and walks you through the whole process
http://www.lansweeper.com/kb/54/How-to-configure-SSL-in-IIS-Express.html