I'm reading through the documentation, and don't see what i'm looking for.
This new build is going to run on a staging --> prod set up. On the prod side, I'm hoping to the have the admin login only available to local host. This way you have to be logged into the server to access the admin panel.
I'm assuming i need to make the web.config adjustments, but how do i ensure that only http://localhost/ works?
Try installing URL Rewrite on the web server and adding the following rewrite rule to your web.config system.webServer section. This should cause IIS to intercept any URLs under /admin and return a 403 if not on a URL local to the server. You might also need to adapt the URL match or add additional rules for other Kentico admin paths (e.g. CMSAdministraton.aspx etc.).
<rewrite>
<rules>
<rule name="Block Remote Access to Admin" stopProcessing="true" patternSyntax="ECMAScript" enabled="true">
<match url="admin(/|$)" ignoreCase="true" />
<conditions logicalGrouping="MatchAll">
<add input="{REMOTE_ADDR}" pattern="localhost" ignoreCase="true" negate="true" />
<add input="{REMOTE_ADDR}" pattern="127.0.0.1" negate="true" />
<add input="{REMOTE_ADDR}" pattern="::1" negate="true" />
</conditions>
<action type="CustomResponse" statusCode="403" statusDescription="Forbidden" statusReason="Access to this URL is restricted"/>
</rule>
<rules>
</rewrite>
Add custom code in Admin/CMSAdministration.aspx.cs to grant localhost only.
Related
I have an app in the azure app service which has "index.html" setup as a default document in portal and also url rewrites in web-config (see below). If I go to the site with cleared history or chrome incognito mode it gives me a 404. I can hit the url directly on "mysite.com/index.html" and after that "mysite.com" will work too, but brand new browser session always 404.
I also have below in www_root in attempt to force "index.html" to load but no luck, any ideas?
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<system.webServer>
<!-- IIS URL Rewrite for react routes -->
<rewrite>
<rules>
<rule name="Angular Routes" stopProcessing="true">
<match url=".*" />
<conditions logicalGrouping="MatchAll">
<add input="{REQUEST_FILENAME}" matchType="IsFile" negate="true" />
<add input="{REQUEST_FILENAME}" matchType="IsDirectory" negate="true" />
<add input="{REQUEST_URI}" pattern="^/(api)" negate="true" />
</conditions>
<action type="Rewrite" url="/index.html" />
</rule>
</rules>
</rewrite>
</system.webServer>
</configuration>
Try by removing '/' in url=/index.html and add appendQueryString="true"
The default document is the web page that's displayed at the root URL for a website. The first matching file in the list is used. To add a new default document, click New document.
So, you could remove the above and then try adding> In the Azure portal, search for and select App Services, and then select your app. In the app's left menu, select Configuration > Default documents.
If the app uses modules that route based on URL instead of serving static content, there is no need for default documents.
To isolate, try to configure web.config similar to this:
<configuration>
<system.webServer>
<rewrite>
<rules>
<rule name="SPA">
<match url=".*" />
<action type="Rewrite" url="index.html" />
</rule>
</rules>
</rewrite>
</system.webServer>
</configuration>
Or If you wish to actually rewrite but not redirects, try enabling ARR with applicationHost.xdt file with in the site root folder. If you connect to your site using Kudu console, you will see the deployed files under your site\wwwroot folder - Kudu console (https://yoursite.scm.azurewebsites.net) > From the Kudu Console> Debug Console >> (CMD/PowerShell> Site > wwwroot. >> Shows-up all your deployment files.
I have Apache NiFi running on a Windows server. I've setup HTTPS access and connected it to my AD via LDAP for users authentication. The value of property nifi.web.https.host is localhost and nifi.web.https.port is 6444 and I'm able to access the web UI through https://localhost:6444/nifi with no issues.
I want now to setup NiFi to run behind IIS on the same server so IIS acts as a proxy. I've created a new site within IIS and configured the URL Rewrite rules in its web.config file as below:
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.webServer>
<rewrite>
<rules>
<clear />
<rule name="Redirect to HTTPS" stopProcessing="true">
<match url="(.*)" />
<conditions>
<add input="{HTTPS}" pattern="^OFF$" />
</conditions>
<action type="Redirect" url="https://{HTTP_HOST}/{R:1}" redirectType="SeeOther" />
</rule>
<rule name="NiFi Reverse Proxy" stopProcessing="true">
<match url="(.*)" />
<conditions logicalGrouping="MatchAll" trackAllCaptures="false" />
<action type="Rewrite" url="https://localhost:6444/{R:1}" />
</rule>
</rules>
</rewrite>
</system.webServer>
</configuration>
Both IIS and NiFi are using the same SSL certificate from my organization.
I've configured the nifi.web.proxy.host property in the nifi.properties file to nifi01.myorg.com:443.
I'm able to access https://nifi01.myorg.com/nifi from an external computer. I see the sign in page and am able to sign in successfully. However, after the authorization is completed, I'm redirected to https://localhost:6444/nifi. If in the same browser session I type in https://nifi01.myorg.com/nifi, then I can see the main Nifi workflow UI which tells me that the sign in process did work.
Can someone help me with the redirection that is happening to https://localhost:6444/nifi. Is there something that I'm missing in the web.config or nifi.properties files?
I found this article https://community.hortonworks.com/articles/113240/running-apache-nifi-behind-a-proxy-2.html that I've not been able to follow as don't know where in IIS the settings should go.
I have a website that I host on azure. I recently bought an SSL and configured it. Now users can visit my site by typing in either http://example.com or https://example.com.
What I want is for users who type in the former to be automatically redirected to the latter while also keeping anything after the .com
So if a user types in http://example.com/about they will be redirected instead to https://example.com/about.
After some reading, I've come across this code that seems to do what I want
<system.webServer>
<rewrite>
<rules>
<rule name=”Redirect to https”>
<match url=”(.*)”/>
<conditions>
<add input=”{HTTPS}” pattern=”Off”/>
<add input=”{REQUEST_METHOD}” pattern=”^get$|^head$” />
</conditions>
<action type=”Redirect” url=”https://{HTTP_HOST}/{R:1}”/>
</rule>
</rules>
</rewrite>
</system.webServer>
But before I add this to my web.config file I have a few questions.
What is the IIS url rewrite module? IIS Rewrite and is it required to be installed on my azure hosted websites before I upload my new web.config file.
How can I also include removing www from my URL when a user enters it. For example if a user types in www.example.com they should be redirected to https://example.com instead. The reason that I want this is because in my google search console I've told google to display URLs as example.com rather then www.example.com
and finally, will this code do what I'm looking for? Is there a more professional way to achieve this? What are the benefits. I should note that my sites are asp .net web forms. I know MVC has routing options but that is not an option for me.
Edit : I don't think How to force HTTPS using a web.config file solves my issue because I don't even know if I can install the URL Rewrite module since I am not hosting IIS myself. Does azure give you access to the IIS settings? I am unfamiliar with azure details.
The Microsoft URL Rewrite Module for IIS enables IIS administrators to create powerful customized rules to map request URLs to friendly URLs that are easier for users to remember and easier for search engines to find.
This module is pre-installed for Azure Web App, as shown when inspect the applicationHost.config of the Azure Web App in Kudu.
Hence, you do not need to worry about the availability of the module for Azure Web App.
The URL Rewrite configuration to enforce HTTPS redirection for Azure web app is the simplest way to achieve what you intend. Your above configuration will apply
only if the request method is either HTTP GET or HTTP HEAD. The below configuration will not have such limitation.
<system.webServer>
<rewrite>
<rules>
<rule name="Force HTTPS Redirection" enabled="true" stopProcessing="true">
<match url="^$" ignoreCase="false"/>
<conditions>
<add input="{HTTPS}" pattern="^OFF$"/>
</conditions>
<action type="Redirect" url="https://{HTTP_HOST}/" redirectType="Permanent"/>
</rule>
</rules>
</rewrite>
</system.webServer>
I would add one last thing. Assuming you are running on Azure Web Apps, they have various probes to your site for warm up and initialization. You probably don't want these probes to also be redirected, otherwise, you may have some issues when you restart or use Azure's swaps feature for stuff like blue/green deployments. These probes would then be return with a 301/302 rather than actually hitting your site (and Azure doesn't actually follow the redirect)
More examples https://github.com/projectkudu/kudu/wiki/Xdt-transform-samples
<rule name="Redirect to non-WWW" stopProcessing="true">
<match url="(.*)" />
<conditions>
<add input="{HTTP_HOST}" pattern="www.example.com$" />
<add input="{HTTP_USER_AGENT}" pattern="Initialization" negate="true" /> <!-- IIS Application Initialization Warmup -->
<add input="{HTTP_USER_AGENT}" pattern="SiteWarmup" negate="true" /> <!-- Azure WebApps Warmup Request -->
<add input="{HTTP_USER_AGENT}" pattern="AlwaysOn" negate="true" /> <!-- Azure WebApps AlwaysOn Probes -->
</conditions>
<action type="Redirect" redirectType="Permanent" url="https://example.com/{R:1}" />
</rule>
<!-- Redirect to HTTPS Version -->
<rule name="HTTP to HTTPS redirect" stopProcessing="true">
<match url="(.*)" />
<conditions>
<add input="{HTTPS}" pattern="off" ignoreCase="true" />
<add input="{HTTP_USER_AGENT}" pattern="Initialization" negate="true" />
<add input="{HTTP_USER_AGENT}" pattern="SiteWarmup" negate="true" />
<add input="{HTTP_USER_AGENT}" pattern="AlwaysOn" negate="true" />
</conditions>
<action type="Redirect" redirectType="Permanent" url="https://{HTTP_HOST}/{R:1}" />
</rule>
I use Azure cloud with web app and my server side written on nodejs.
When web app receive a http request I want to redirect the request to https
I found the solution.
I put that to my web.config file inside the rules tag
<rule name="Force HTTPS" enabled="true">
<match url="(.*)" ignoreCase="false" />
<conditions>
<add input="{HTTPS}" pattern="off" />
</conditions>
<action type="Redirect" url="https://{HTTP_HOST}/{R:1}" appendQueryString="false" redirectType="Permanent" />
</rule>
The problem is when I type in the browser "https://myURL.com" it redirect to main screen every thing ok,
but when I change https to http "http://myURL.com" it redirect to https://myURL.com/" and add to the url "bin/www" according that the url looks like that "http://myURL.com/bin/www", the response is: page doesn't find.
The question is how to redirect a clear url without added data to the url?
Part of my web.config file:
<rewrite>
<rules>
<!-- Do not interfere with requests for node-inspector debugging -->
<rule name="NodeInspector" patternSyntax="ECMAScript" stopProcessing="true">
<match url="^bin/www\/debug[\/]?" />
</rule>
<!-- First we consider whether the incoming URL matches a physical file in the /public folder -->
<rule name="StaticContent">
<action type="Rewrite" url="public{REQUEST_URI}" />
</rule>
<!-- All other URLs are mapped to the node.js site entry point -->
<rule name="DynamicContent">
<conditions>
<add input="{REQUEST_FILENAME}" matchType="IsFile" negate="True" />
</conditions>
<action type="Rewrite" url="bin/www" />
</rule>
<!-- Redirect all traffic to SSL -->
<rule name="Force HTTPS" enabled="true">
<match url="(.*)" ignoreCase="false" />
<conditions>
<add input="{HTTPS}" pattern="off" />
</conditions>
<action type="Redirect" url="https://{HTTP_HOST}/{R:1}" appendQueryString="false" redirectType="Permanent" />
</rule>
</rules>
</rewrite>
<!-- 'bin' directory has no special meaning in node.js and apps can be placed in it -->
<security>
<requestFiltering>
<hiddenSegments>
<remove segment="bin" />
</hiddenSegments>
</requestFiltering>
</security>
Thanks for answers, Michael.
Go to Azure portal and open the overview page of the (Web) App Service you wanna set to HTTPS only. In the sidebar, under the Settings section, there is an option for TLS/SSL Settings.
On clicking it, you will get an option on the screen to set your app's protocol to HTTPS only. There isn't any need to manually add separate ruleset for this.
This works on every tier of App Service Plan including the 'F'-Series (free subscription).
Note that, if you are adding any custom domain you also need to add corresponding SSL bindings, you can easily get them using LetsEncrypt or alike. If any of the custom hostnames for your app are missing SSL bindings, then:
When HTTPS Only is enabled clients accessing your app on those custom hostnames will see security warnings.
PS: I just saw that this question was asked about 3 years ago and that time maybe there was no direct option to do this. But even so, I'm posting my answer because on Google (as on February 2020) this question still ranks first among others regd. automatic HTTPS redirection in Azure.
As of November 2017, this is now a simple switch in the Azure Portal: "HTTPS Only", under Custom domains.
https://blogs.msdn.microsoft.com/benjaminperkins/2017/11/30/how-to-make-an-azure-app-service-https-only/
It's also very easy in ARM:
“httpsOnly”: true
There is also a free and open source extension for this.
Go to your Web App settings sidebar, search for the "Extensions" tab and click on "Add".
Scroll down and find the extension Redirect HTTP to HTTPS by gregjhogan.
Accept the terms.
Restart the Web App for the actions to take effect immediately.
Done !
For further details on the implementation of this extension, check the source code on GitHub. The most important source file is the applicationhost.xdt.
Quote from GitHub (02-08-2017) (credits go to gregjhogan):
applicationhost.xdt
<?xml version="1.0"?>
<configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
<location path="%XDT_SITENAME%" xdt:Transform="InsertIfMissing" xdt:Locator="Match(path)">
<system.webServer xdt:Transform="InsertIfMissing">
<rewrite xdt:Transform="InsertIfMissing">
<rules xdt:Transform="InsertIfMissing" lockElements="clear">
<rule name="redirect HTTP to HTTPS" enabled="true" stopProcessing="true" lockItem="true">
<match url="(.*)" />
<conditions>
<add input="{HTTPS}" pattern="off" ignoreCase="true" />
<add input="{WARMUP_REQUEST}" pattern="1" negate="true" />
</conditions>
<action type="Redirect" url="https://{HTTP_HOST}/{R:1}" appendQueryString="true" redirectType="Permanent" />
</rule>
</rules>
</rewrite>
</system.webServer>
</location>
</configuration>
R:1 is a back-reference to the rule pattern. You append that to the url here:
url="https://{HTTP_HOST}/{R:1}"
changing that into
url="https://{HTTP_HOST}"
should result in a redirect to the https root.
We are using IIS URL Rewrite module to redirect all request from a mobile browser to m.mymobilesite.com by checking HTTP_USER_AGENT. This works fine and now we need to implement a "View Full Site" link which will allow the user to see the main site. Trying to achieve this by adding a "nomobile" cookie when user clicks on "View Full Site" link which will be validated and negated by the rule. For some reason my rule doesn't seems to work.
Please help.
<rewrite>
<rules>
<rule name="MobileRedirect" patternSyntax="ECMAScript" stopProcessing="true">
<match url=".*" ignoreCase="true" />
<conditions logicalGrouping="MatchAll">
<add input="{HTTP_COOKIE}" pattern="nomobile" ignoreCase="true" negate="true" />
<add input="{HTTP_USER_AGENT}" pattern="android|blackberry|googlebot-mobile|iemobile|iphone|ipod|opera mobile|palmos|webos" />
</conditions>
<action type="Redirect" url="http://m.mymobilesite.com" appendQueryString="false" redirectType="Found" />
</rule>
</rules> </rewrite>
The rule is perfect and I figured out the issue after doing a trace on failed request at IIS level as described here
The cookie which I was creating while user select the "View Full Site" link was not created with the domain name. I added domain="mymainsite.com" on the cookie creation script and it is working fine now.