We have following URLs like
http://testserver1.com:port1
http://testserver2.com:port2
Each URL is pointing to different application on the Windows Server.
What we need to do is that we need to change the URL like http://testserver1.com instead of http://testserver1.com:port1 and it should be forwarded to the application serving port1. We do not want users to enter port number with the URL.
And if we type http://testserver2.com instead of http://testserver2.com:port2 also it should be forwarded to the application serving port2.
How can we do this with Windows Firewall - Inbound Rules and IIS. Can somebody help?
We have tried to add first Inbound Rule under Windows Firewall but we have no idea how to do the rest to forward such incoming requests to the correct application serving the specific port.
Related
I have an application that runs fine in AWS App Runner and can be found here: https://iyarles.net
However, it's not accessible via the naked domain name iyarles.net.
Clarification comment: If I goto iyarles.net in my browser (edge), the request times out. If I goto iyarles.net, my website loads fine.
The App Runner service has a custom domain configured and my hosted zone has the 2 certificate validation records and the alias record pointing to my service.
A few weeks ago I transferred my domain from Google Domains to Route 53. It was originally a redirect from iyarles.net or any other subdomain (with or without https://) to the default domain for my service.
How can I replicate the previous behavior? What exactly are these alias records doing?
When you type the hostname into the browsers address bar, browsers will assume you want to make a plain HTTP request.
When you explicitly include the https: scheme, browsers will make a secure HTTP request.
Your server is running an encrypted service on port 433. It is not running a plain service on port 80.
It times out if you type http://iyarles.net too.
The issue is that the custom domain configured in AWS App Runner is not accessible via the naked domain name, iyarles.net. To replicate the previous behavior, you will need to create an Alias Record in your hosted zone in Route 53, which will point your domain name to the service URL.
The Alias Record is used to route traffic from a domain name to the service URL. It will ensure that any requests to the domain name will be routed to the service URL, thereby allowing your application to be accessible via the naked domain name.
It is important to note that you will also need to create two Certificate Validation Records in your hosted zone in Route 53. These records are used to validate the SSL Certificate for your domain name, which is necessary for HTTPS connections.
The manual says this about the HTTP URL value of an http listener:
"Displays the generated HTTP URL for the HTTP Listener. This is not an actual
configurable setting, but is instead displayed for copy/paste convenience. Note
that the host in the URL will be the same as the host you used to connect to
the Administrator. The actual host that connecting clients use may be different
due to differing networking environments."
When I have used the feature in the past its value has always begun "http://localhost:" which would be great except this time it is auto-generating " http://'domainName':${Incoming_Pathology_Source_Port}/${Incoming_Pathology_Source_BaseContextPath}/"
For the first time, we are deploying Mirth inside a Kubernetes cluster, 'a different working environment'. (nginx accepts https and we want it pass the messages on as http to Mirth).
Is there any way I can take control of the URL or must I change the configuration of the cluster in some way.
All help/suggestions welcome.
I am developing a web service using REST API. This REST API is running on port 6443 for HTTPS. Client is going to be a Single page application running on port 443 for HTTPS on same machine. The problem I am facing is:
While I hit the url say: https://mymachine.com/new_ui I get certificate exception for an invalid certificate because I use a self signed one, so mymachine.com:443 gets added to server exception. But still requests doen't go to REST API as they are running on https://mymachine.com:6443/restservice. If I manually add mymachine.com:6443 to server exception on firefox it works but it will not be the case in production for customers.
Some options that I thought are:
1. Give another pop up and ask to add REST server on port 6443 exception too.But this doesn't look proper as why an end user should accept the cerf for same domain twice. Also REST api server port can change.
Can we programmatically add exception for domain and both the ports in one shot? Ofcourse with the consent of the user. 3. Use a reverse proxy. But then its going to have memory footprint on our system. Also it will be time consuming.
Please suggest some options. How do I deal with it. Thank you
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>
I'm running meteor on localhost:3000 and I have apache set up to proxy requests for a domain to that meteor instance using a virtualhost and mod_proxy.
I'm getting this error when trying to log in to my meteor app using accounts-facebook:
Given URL is not allowed by the Application configuration.: One or
more of the given URLs is not allowed by the App's settings. It must
match the Website URL or Canvas URL, or the domain must be a subdomain
of one of the App's domains.
I think this is because my ROOT_URL is http://localhost:3000 . If I change the ROOT_URL to the domain, then of course meteor tries to listen to the domain, but can't because my apache server is in the way.
Is there a way I can make this work without another IP address?
From Meteor documentation,
Ensure that your $ROOT_URL matches the authorized domain and callback
URL that you configure with the external service (for instance, if you
are running Meteor behind a proxy server, $ROOT_URL should be the
externally-accessible URL, not the URL inside your proxy).
In my case, my app is listening on a configured port with mod_proxy behind an Apache proxy server, say it is listening http://www.example.com:8080. I have other applications running on other ports.
To get going, on Facebook I set Site URL and Valid OAuth redirect URIs to http://www.example.com:3000 and App Domains to www.example.com. On my machine I set ROOT_URL to http://www.example.com:3000, which is externally-accessible.
Such configurations work for me without a second IP address.
I could get it working by simply having
# /etc/hosts
127.0.0.1 localhost.localdomain localhost
And the facebook settings as in the image below. I've set a secondary (mobile) url to point to http://localhost:3000
I've created a whole facebook app like this, with login, access to graph-api etc. And everything was working both online and in the dev envrionment