Force HTTP to HTTPS redirect - redirect

I have a site on SharePoint and I have implemented HTTPS successfully.
However, if user goes to the URL and remove 's' from 'https' then site becomes accessible without SSL.
I want a way to force redirect the user to HTTPS in all cases. How can I achieve this using IIS or SharePoint Central Administration?

The IIS rewrite module has a template configuration for this very purpose. YOu can download it here and theres a sample here if you are stuck. Its a very powerful and much underused extension in IIS IMO.

Related

Wildfly HTTP-only redirect

Quick and dirty fix needed here if possible...
We've been running a bunch of REST services on a Wildfly installation for a few years. The server isn't for public use -- on the main https://ourserver.com page we have a redirect which points wandering users to our main website. It's a very simple standalone config.
But the server has always been HTTPS only. And now thanks to a domain reshuffle, we need to make it possible for users who go to http://ourserver.com without SSL to hit the redirect to ourserver.net. So we basically need to expose just the welcome-content directory on this server over the "http" interface (which was previously firewalled off), while not letting non-SSL users reach any of the webservice subdirectories.
What's the simplest way to ensure that accessing any URL via plain HTTP gets redirected?
You can try adding a filter to the standalone.xml under the subsystem urn:jboss:domain:undertow:4.0
e.g. for http (8080) to https (8443), it would be:
<filter-ref name="http-to-https" predicate="equals(%p,8080)"/>
under the tag filters, you add it:
<rewrite name="http-to-https" target="https://myhttpsurl.com:8443%U" redirect="true"/>

WS Federation (single sign on) module - redirect issue when using SSL offloading

We have a site that we are trying to configure as a client in a SSO scenario, using WS Federation and SAML.
Our site sits behind a load balancer that is doing SSL offloading - the connection to the balancer is under https, but decrypted and forwarded (internally) to the actual site under http and port 81.
Somewhere the WS federation module is attempting to redirect us, but is building up the URL based on the port and incoming protocol to the website:
We request:
https://www.contoso.com/application
and are getting redirected to:
http://www.contoso.com:81/Application
Which doesn't work as the load balancer (correctly) won't respond on this port.
And it seems to be related to the casing of the virtual directory. Browsing to
https://www.contoso.com/Application
seems to work without issue.
(Note for completeness, attempting to browse to http://www.contoso.com/Application with no port will correctly redirect us to the SSL secured URL).
I am trying to find out:
a) Where this redirect is happening in the pipeline and
b) How to configure it to use the correct external address.
If anybody is able to point me in the right direction, I would very much appreciate it.
EDIT 14:19: Seems to be either the WsFederationAuthenticationModule or the SessionAuthenticationModule. These do a case sensitive comparison of the incoming url to what it expects and redirects otherwise:
https://brockallen.com/2013/02/08/beware-wif-session-authentication-module-sam-redirects-and-webapi-services-in-the-same-application/
So that seems to be happening, its a matter now of trying to get the site to behave nicely and redirect to the correct external url.
The following seems to be related and ultimately points to the culprit in the default CookieHandler:
Windows Identity Foundation and Port Forwarding
Looking at that code decompiled in VS, it compares HttpContext.Current.Request.Url against the targetUrl and will redirect to the expected 'cased' version otherwise (in our case including the errant port number).
It would seem that explicitly setting the path attribute of the cookie fixes this issue. Either an empty string or the virtual directory name seems to work:
<federationConfiguration>
<cookieHandler requireSsl="true" name="ContosoAuth" path="/Application/"/>
<wsFederation passiveRedirectEnabled="true" issuer="https://adfsSite" realm="https://www.contoso.com/Application/" reply="https://www.contoso.com/Application/Home" requireHttps="true"/>
</federationConfiguration>

Circumventing web security limitations between two sites on the same server

I'm using Eclipse to develop an app that consists of an Angular 2 front end and a Java REST back end.
For the front end, I'm using the Angular CLI plugin, which starts the app by issuing an ng serve command to the CLI. This command sets up an http server on port 4200.
For the back end, I'm using an in-company framework that launches in Jetty within Eclipse in port 8088.
While both these ports are configurable, by nature of the frameworks and plugins in use, they'll always be distinct.
Authentication works via an OAuth2 service that is also deployed to port 8088, as part of the framework. This service sets a cookie which certifies the browser session as authenticated. I have verified that this service works correctly by testing it against a Swagger instance of the REST API (also running in 8088 as part of the same framework).
The problem is that when the browser is aimed at the Angular 2 app on :4200, its internal REST API requests to :8088 aren't carrying the authentication cookie. Presumably, this is because of cross-site protection.
Is there any way for the app or the framework to tell the browser that these two "sites" are actually part of the same system?
Alternatively, if I have to configure the dev browser (Chrome) to work, I can live with that too. However, I've tried the --disable-web-security --user-data-dir recommendation, but the cookie still doesn't show up on the requests.
Lastly, I have Apache installed on the dev machine. If I can set up appropriate vhosts and use it as a proxy so that the browser thinks it's all the same, that would probably work too. It would just be a matter of intercepting all /swagger and /api requests and sending them to :8088, and all forwarding all other requests to :4200. However, I've been banging my head against mod_rewrite and mod_proxy and haven't been able to come up with anything that works.
I think what you're looking for is
withCredentials = true
https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/withCredentials

IIS Redirects - Redirecting domain without website binding

I have a bunch of domains (50+), e.g. example1.org example2.org, example3.org that I would like to redirect (301) to a single domain, examplethebest.org. Nothing is hosted on any of these domains other than examplethebest.
I've set up all the example domains in the registrar's DNS to point to the IP of my web server.
I was wondering if redirecting these is something I could achieve via rewrites in the applicationHost.config file. Or do I need to add bindings for example1 - example3.org in examplethebest's website bindings?
Just wanted to add that I understand how to do the rewrites via the web.config in examplethebest if I add bindings for the domains I want to redirect, but would rather not have loads of domain bindings - e.g. what is best practice here? Thanks!
Okay so the issue I had on this particular web server was that the default website (listening to all requests on port 80) was stopped - the other websites all had specific bindings.
At least two possible solutions for this one:
Starting the default website and adding {http_host} rewrites in there
Creating another website, make it listen to all requests on port 80 with just a web.config and putting the {http_host} rewrites in there.
We went with option 2.

Need to set up SSL for facebook site apps to work, any suggestions? I do not need to protect passwords or anything

facebook is forcing apps to use HTTPS, i have been looking in to openSSL, but i really cannot get my head around on how to install it, i am using godaddy and it runs on a linux server, i dont think i can execute from any command line.
I need to have a valid HTTPS link, a self signed certificate it OK, but i cannot seem to get one up on GoDaddy, can i redirect all HTTPS to HTTP, would that work? via .htacess
Any suggestions are welcome!
I had the exact same problem Yesterday, and quickly found a way around this without having to move my application to a server with SSL.
Facebook only validates the starting URL to be https://..... however, you are not forced to use ssl from there on forward. Thus I simply created a free Heroku account (you can use any other hosting provider that supports SSL) and added a index.php file with the following code:
<?php
header( 'Location: http://my.app.url' );
When the IFrame is loaded, it will automatically redirect to your application hosted on a non-ssl server and will work without any problems.
For more information you can check out my blog post http://www.xethron.co.za/building-a-facebook-app-on-a-host-without-https-ssl-support