I'm integrating Azure AD into a server side blazor application. It works locally (using https), however when I deploy it to production, the redirect URI in the URL is HTTP, not HTTPS, which then once I log in, Microsoft say the redirect URI isn't valid.
I'm running a VM using Ubuntu and Apache, which is forwarding anything from port 80 to port 443 using a Lets Encrypt certificate, however when it sends the user to Microsoft to login, the redirect URI is http://mydomain.tld, rather than https://mydomain.tld. I think it's because the URL it's running on locally is http://localhost:9000 - But when I put it to https://localhost:9000, it throws an exception on start up as it doesn't have a certificate and as I'm not running on a development machine, I don't really want to install the net core SDK and create dev certificate.
I've seen a few people put this in their code to solve it, however my requests are still going through to Azure AD with a HTTP redirect URI:
var fordwardedHeaderOptions = new ForwardedHeadersOptions
{
ForwardedHeaders = ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto
};
fordwardedHeaderOptions.KnownNetworks.Clear();
fordwardedHeaderOptions.KnownProxies.Clear();
app.UseForwardedHeaders(fordwardedHeaderOptions);
Any ideas on how to fix it? I can't imagine I'm the first to be using Blazor behind Apache and connecting via openid.
Two options:
1.Set up Redirect URIs: http://localhost/****
2.Edit the Manifest like below:
Related
I'm attempting to use Keycloak for some future projects and it's still very new to me so I'm plugging away reading through the docs and searching for issues online but I'm currently stumped on one thing - I have a vuejs app I’ve added as a client (127.0.0.1:3001), I have a reverse proxy setup in IIS (idp.mc.local) and then a docker container on Windows with keycloak running (127.0.0.1:8080), when I attempt to login, instead of being redirected back to the vuejs client I am just getting redirected to the root of the reverse proxy with the state value in the url, as in the network logs in the screenshot below:
Network logs showing incorrected 'Location' redirect
If I don’t set a front end url for the realm and bypass the proxy / hook my vuejs client to login via Keycloak directly on 127.0.0.1:8080, it redirects to 127.0.0.1:3001/#state… correctly, as below:
Network logs showing correct 'Location' redirect
I can't spot any way to sort this issue, I thought the front end url for the realm should state the proxy address? I can't see why Keycloak would redirect to it at the end of the login process rather than to my client app url, the redirect_uri is being ignored by keycloak and for some reason taking me back to the root of my proxy domain. If I actually manually visit 127.0.0.1:3001/#state… with the state value copied in from the incorrect redirect, I log in successfully.
It's baffling me and any help would be appreciated!
The answer did turn out to be an IIS related issue with the setup of Application Request Routing / ARR being the problem. What was needed was to edit the settings for IIS Application Request Routing and uncheck the option:
Reverse rewrite host in response headers as can be seen in the image below:
IIS ARR Checkbox to untick
Hopefully this will be helpful for someone else who might have the same issue at some point!
I've recently tried moving an ASP.NET core 3.0 application from a windows server to a Linux server.
The application shares cookie authentication with another website so the cookie domain needs to be a wildcard to share across the sub-domains i.e. .example.com
This works fine on the Windows server the cookie domain for https://sub.example.com gets set as .example.com
However, when I login on the Linux server the cookie domain for some reason gets set with the sub-domain. For example for https://sub-test.example.com the cookie domain is .sub-test.example.com, which then won't be shared with https://sub.example.com, hence the problem.
I've checked the network tab in the browser and the set-cookie header has "domain=.sub-test.example.com", so I'm convinced it's a server side problem.
In Startup.cs, I have hard coded the domain wildcard I want, it just doesn't get honoured on Linux.
services.ConfigureApplicationCookie(opt =>
{
opt.Cookie.Domain = ".example.com";
}
Not sure what else I can try.
Sounds like an issue with a Reverse Proxy, which is probably overriding the settings you set there. Take a look at the this post: URL Rewrite keeps original host Location when reverse proxy 301 redirects
i have IHS 7 installed on an AIX system and its pointing to Application Server . now my requirement is if Application is not accessible or if we are working on the Application it self then whoever access the URL, it redirects to a custom page on the webserver that Application is under construction .
for example url is https://my.Application.com:8089/application if anyone hits this URL then this URL is redirected to custom URL on same webserver https://my.webserver
i have configured a proxy on IHS httpd.conf but it is not working
The good practice in such case is to create two config files and one maintenance page. When your app server do not work you should restart http server with config file which point to the maintenance page.
I know there are about a hundred questions of this on SO, but none of them are maybe up-to-date with what seems to be happening on facebook platform right now. It seems the switch that turns off SSL is disabled:
It may be hard to see, but the "Enforce HTTPS" toggle is greyed out and can't be toggled. I'm all for enforcing HTTPS in production, but is everyone who is building against facebook API really setting up an SSL certificate on their local server just for this?
You will still be able to use HTTP with “localhost” addresses, but
only while your app is still in development mode.
You can change the App mode to Development Mode from App Dashboard:
In this mode you can only test your application with Facebook test user accounts. You can obtain the test accounts login credentials from your app dashboard.
Please note, http://localhost redirects are automatically allowed while in development mode only and do NOT need to be added in Valid OAuth Redirect URIs section.
Read more about it in this Facebook Blog.
2021 update: Facebook do not allow localhost over HTTP any more. You will need to get your site working locally over HTTPS for testing. This is despite their blog post and the literal Facebook developer console assuring you that they allow localhost over HTTP by default.
paste this in your client json
"start": "set HTTPS=true&&react-scripts start",
next copy and enter this in your url bar .
chrome://flags/#allow-insecure-localhost,
and set Allow invalid certificates for resources loaded from localhost to enabled
The most simple way to test your facebook login, since you cannot dissable anymore "Enforce HTTPS" option, is to use ngrok:
ngrok.com
Im linux user. After installing it just type at your terminal:
ngrok http 80
and automaticly will be created a new https domain just for your local project. You will see an ui interface in your terminal and your secure domain will be that who starts with https://
Copy the domain and use it in developers.facebook.com in your app to see if you code is good or not.
If is good its ok keep going until you will host your project on a secure domain.
For more info and docs about ngrok.com see:
ngrok docs
This setting requires HTTPS for OAuth Redirects, and it requires and Facebook JavaScript SDK calls that return or require an access token are only from HTTPS pages. All new apps created as of March 2018 have this setting on by default, and you should plan to migrate any existing apps to use only HTTPS URLs by October 6, 2018.
Most major cloud application hosts provide free and automatic configuration of TLS certificates for your applications. If you self-host your app or your hosting service doesn't offer HTTPS by default, you can obtain a free certificate for your domain(s) from Let's Encrypt.
https://developers.facebook.com/docs/facebook-login/security
I'm brand new to Express Gateway and I'm trying to set up a basic API Gateway to link up some micro services. When I try and proxy to a specific end point https://my-service.net/status (not the real URL), I get this error
[EG:policy] warn: unable to verify the first certificate
I can access the URL 'https://my-service.net/status' in the browser just fine.
When I switch out the serviceEndPoint URL it works fine (e.g. to https://httpbin.org), so it seems like there's something different with my URL in terms of the SSL/authentication config.
Any ideas? Many thanks.
My gateway.config.yml -->
So the SSL setup allows me to access the page from a browser (Chrome), but at the command line (e.g. through my Express Gateway which is served by NPM and running locally on port 8080) it fails.