I have a Website that runs on a web farm (4 servers) behind a load balancer. The load balancer is the one that has the ssl certificate for https and decides to what server the requests go to.
In the code for the website, using .net Core I have in the startup.cs file logic in the Configure method to force the https redirection with app.UseHttpsRedirection(); So when we access the site without https the .net core permanent redirect the user to the https version (this is importand bc the web app is a PWA, so we need it for use service worker)
Imagine the url to access the website is https://production.website.com, again if the user try to go to http://production.website.com, it will redirects to https version. But you can also access each server in the web farm directly using these subdomains http://prod1.website.com, http://prod2.website.com, http://prod3.website.com, http://prod4.website.com (we have this set bc we want to test individual servers in case a deployment error happens on a specific server).
The problem is, bc the ssl certificate is in the load balancer (production.website.com domain), when you try to go directly to a individual server (prod1, prod2, prod3 or prod4) the .net core will redirect it to the https version and that server doesnt have a ssl certificate and the user will see an error on the browser, so we need a way to control that with a condition. So what the problem is? that at the startup.cs code we dont have access to the site url bc we dont have a request yet, I have research a lot and some workarounds that use to work in the past now with .net core 3.1 dont.
So how I can make that the code in the configure method doesnt force a https redirect if the users is accessing the individual servers and not the main domain for the web site?
Related
I am working on a web application that is hosted in the internet, but shall be able to use a REST API provided by a local HTTP-printserver.
The problem is, that when the application is accessed via HTTPS, all my XmlHttpRequest to the local HTTP-printserver are blocked (because of security mechanisms of the browser).
Therefore my "solution" is to use plain HTTP for the web application.
However, whenever I open the site in my browser - explicitly with http (e.g. http://mysite.de/app/index.html) the browser sends an "Upgrade-Insecure-Requests" which is accepted by the webserver and they switch over to HTTPS.
Is there a way how to deny/reject the upgrade to HTTPS?
Ideally by .htaccess
Ideally only for index.html in the app folder
I am currently working on an .NET 5 & SignalR application and in localhost everything seems to be working fine. When I try to deploy it to IIS pre-production Server which doesn't have a SSL certificate configured, pages other than Login are showing the message "This site can’t provide a secure connection". In the login page from the browser console I can see that most of me javascript and css files aren't loaded with the error "Failed to load resource: net::ERR_SSL_PROTOCOL_ERROR". Also from what I can see after user logs in, the request is redirected to Https.
I have removed app.UseHttpsRedirection(); from the Startup and disabled SSL in the Debug properties of the application. That seems to be a wired behavior because I used to deploy applications in .NET CORE before and didn't have these kind of problems. is there any way around this problem, except configuring an SSL certificate?
From the suggestions in server fault, configuring a self-signed certificate provided by IIS itself seems to be the problem solver. Still I don't get why the application was making that https redirection, but anyways in case someone else has this kind of issue.
I have a blazor server-side application (netcore 3) which uses authentication through OpenID / Okta.
I started testing it through IIS, and running it as a regular website worked just fine.
But, I need to run it through a reverse proxy due to the rest of our setup, and after I set that up the blazor site no longer functions.
Our reverse proxy is simple, just takes a url (https: //subdomain.domain.com), and routes it internally (http: //localhost:8093). There are other sites connected here, this was just an example.
I managed to get all the resources (css, js, images) working correctly by adding the "app.UseForwardedHeaders", but I am still having an issue with Authentication.
For Authentication, it's setup with services.AddAuthentcation, and AddOpenIdConnect, which is triggered by an MVC call to Account/Login, that issues the HttpContext.ChallengeAsync.
Running the application standalone, or in it's website, the Login works, and redirects to Okta (https: //oktadevurl.com/oauth2/default/v1/authorize?parameters).
Through the reverse proxy, this url becomes relative to the Proxy address (https: //subdomain.domain.com/oauth2/default/v1/authorize?parameters) which is incorrect.
I've double checked the forward headers, and OpenId / Okta settings. I'm looking for anyone who has had this issue before and could point me in the right direction on how to get the absolute urls working from blazor through the reverse proxy.
Thanks.
I was able to solve this with one little checkbox is ARR:
In IIS Manager, Select the current server (not the website), open Application Request Routing, and on the right hand column there will be an option Server Proxy Settings. There you will see "Reverse rewrite host in response headers" option. If that is checked - uncheck it and your problem should be solved.
We have a couple of back-end web applications to which we want to provide access via the public internet. To that end, we are setting up a reverse proxy (IIS 7.5) from our DMZ. At the same time, we want these web applications to be claims-enabled through ADFS 2.0.
WEB1.MYCORP.COM/WFE1 is the other back-end web application, on our internal network
WEB1.MYCORP.COM/WFE2 is the other back-end web application, on our internal network
ADFS.MYCORP.COM is the ADFS 2.0 server, on our internal network
FSPROXY.MYCORP.COM is the ADFS 2.0 proxy server, on our DMZ
RPROXY1.MYCORP.COM is the reverse proxy for WFE1, on our DMZ
RPROXY2.MYCORP.COM is the reverse proxy for WFE2, on our DMZ
In keeping with the proper configuration of ADFS, our internal DNS resolves ADFS.MYCORP.COM to the actual internal server, while external DNS points ADFS.MYCORP.COM to the ADFS proxy (FSPROXY).
So, here's the scenario:
End user browses to RPROXY.MYCORP.COM
Reverse proxy forwards request to WEB1.MYCORP.COM/WFE1
WFE1 redirects browser to ADFS.MYCORP.COM (actually FSPROXY)
ADFS Proxy prompts for credentials and authenticates against ADFS server
Upon successful authentication, browser redirected back to web app
I have a couple of questions. Do I need to configure something in the rp or the application to allow this. Also the adfs endpoint is the rp url is that an issue?
Do I need to set up something for the reverse proxy as well? (Should I/can I) set up a claims-enabled reverse proxy in IIS? How do I set up the reverse proxy rules to pass back the ADFS request unaltered? Currently, when I try to access the back-end application, it fails with a 401 authentication error. If I remove the proxy and just hit the app server it works fine.
Further,
This fails:
The path is client --> rp -->app -->adfs --> rp -->app --> rp -->client machine
this works:
The path is client -->rp -->app -->adfs -->app -->rp -->client machine
Any suggestions would be greatly appreciated!
Not familiar with how you enabled reverse proxy in IIS (ARR?). Something like this http://blogs.iis.net/carlosag/setting-up-a-reverse-proxy-using-iis-url-rewrite-and-arr
One choice for you is to use ADFS 2012R2 (if possible) because the proxy in that, the Web Application Proxy, handles both ADFS authentication and can handle app publishing for your claims enabled application. There are 2 ways you can publish your app to the internet. Once is pass-through which is kinda what you are trying to do. But it also allows pre-authentication support for a claims aware app. This way, you can have a different policy that decides whether the application can get pass your EDGE network before a packet goes to your internal application.
After doing lots of digging and fiddler traces I found the issue. In testing idp setup the token was different then stage env. The fiddler traces showed that the token was making it back to the app server. The issue was it also looked like the cookie dropped off for no reason. The issue was because the old dev ipd value disagreed with the stage value...naturally. Once I cleared the old token from the database everything worked.
I have a client who wants to set up SSL on a new directory on their website. They already have one directory using SSL. BUT, when I go into IIS, even the current encrypted directory isn't set up to require SSL. And, when I set either the new or old directory to require SSL it returns and error page stating that I need to call the page over https (which I did), no matter what.
We are not running in a farm. This is a single web server with no load balancing or proxy that I know of. 443 is not blocked. The log files shows a request for the page over 443, but redirects to http. What could be handling the encryption?
ASP.NET 2.0 APP running on IIS 6.0.
Any help is appreciated.
Thx,
T
Your comment "The log files shows a request for the page over 443, but redirects to http" implies yours pages are being sent over port 80. If this is the case what makes you think your pages are being encryted?
Another thought - are you running any ISAPI extensions such as Helicon?