Is there a way to use WCF to redirect all HTTP requests on a certain port - wcf

I need to redirect all requests on port 80 of an application server to a web server. I'm trying to avoid the need to install IIS and instead use WCF to do the job.
It looks like an operation such as the one below is suitable but one problem I've got is if a URL of the form http://mydomain.com/ is used then WCF will present a page about metadata.
[OperationContract, WebGet(UriTemplate = "*")]
RedirectToWebServer();
Does anybody know of a way to get WCF behaving the same as IIS in redirect mode?

This just seems like the wrong tool for the job. If you really don't want to use one of the many web servers that could do this with a couple minutes of setup time (IIS, Apache, Lighttpd), you could just make a simple HTTP socket server.
Listen on port 80. As soon as you get two newlines in a row, send back the response:
HTTP/1.1 301 Moved Permanently
Location: http://myothersite.com/whatever
(I'm almost certain that's the minimum you need). If you want to be really fancy and follow HTTP specs, match HTTP/1.1 or HTTP/1.0 based on what the request has.. but for a quick and dirty redirect, that's all you need.
That said, again, I'd say go grab another web server and set up a redirect using it. There are many lightweight HTTP servers that will work.

Related

How to receive XMLHTTPRequests on Server side?

it's probably I pretty dumb question but I just can't find any information online on how to do this. Probably I'm googling the wrong stuff.
I have to do 2 things. Send xml files via XMLHTTPRequests to a given Server. That's not a problem and easily done. But the company I'm working with also wants me to provide a Server that can receive XMLHTTPRequests and saves them into a file which I can then work with.
How do I handle this? Does I have to setup e.g. NGINX to do this or is this just a specific website I have to host? When I google for XMLHTTPRequests I only find how to send or get data but not how to setup the Server Side. I really have no clue.
Hope you can send me the right way so I can finally continue to work on this.
ty :)
You need a web server server side to receive requests from XMLHTTPRequest calls. You could set up NGINX to do this, or use any web server that you want.
This isn't usually covered in the documentation because you need to serve the page that contains the JavaScript with the XMLHTTPRequest from some server. To get to the point where you are making a XMLHTTPRequest, you already need some HTTP server set up and working. You would usually configure the page to be served from some a main URL like https://example.com/ and have the XMLHTTPRequest call to another URL like https://example.com/log-data would have you logic for storing to a file like your requirement.

Different ports for frontend and backend. How to make a request?

Using Angular-CLI as a frontend. 4200 port
Using Express as a backend. 8080 port
Directories look like:
Application
- backend
- ...Express architecture
- frontend
-...Angular2 architecture
So I'm running two projects, two commanders, one for frontent, second one for backend. node app.js for backend (8080), ng serve for frontent (4200).
Let's assume that I have a layer in backend which returns some string.
app.get('/hello', function(req, res) {
res.send("Hello!");
}
How can I make a request from frontend to backend and get that string? I don't want to know how exactly should I use Angular2 because that's not the point. I'm asking, what technology should I use to be able connect these two (frontent and backend) sides on different ports. If I just run them and make a request from frontend, I'll get an error because it can't find /hello url.
Your request to /hello means an absolute path inside the application running the angular application, so the request goes to http://localhost:4200/hello. Your angular application just doesn't know about the express application you want to target.
absolute urls
If you want to access the hello route on the other (express) application, you need to explicitly specify this by referencing http://localhost:8080/hello.
cors
Doing it this way, the correct application is targeted, but you will likely run into CORS issues, because the browser will prevent the javascript code obtained from localhost:4200 to access a server at localhost:8080. This is a security feature of your browser. So if you want to allow the code at 4200 to access the backend at 8080 your backend can whitelist this so called origin. For details see http://enable-cors.org/ and a corresponding express middleware you could use to support cors in your backend (https://www.npmjs.com/package/cors).
Using this approach has two downsides in my opinion. First, you need a way to tell your frontend under which absolute url it can reach the backend. This must be configurable because you need different urls for dev, staging and production. You then also need a way to manage all your whitelisted urls because the frontend in production will have a different url than when running the frontend in development. This can get pretty cumbersome to handle.
proxying your backend
A better approach in my opinion is to handle this in your infrastructure by proxying the backend in your frontend application. With proxying you basically tell your frontend server that all requests to some url should be passed through to another application. In your case this could probably mean, that for example you configure a proxy for the path /api/ to proxy the application on localhost:8080. The server then doesn't try to find a url like /api/hello on your frontend application but forwards your request to localhost:8080/hello. In your angular application you then don't need to care about the url of your backend and you can then always do a request to a url like /api/some-express-route.
For this to work you need to configure your angular dev server to proxy the requests. For details on how to do this, please see the docs at https://angular.io/guide/build#proxying-to-a-backend-server. When going to production, you can do this by configuring your web server, e.g. nginx to proxy the requests.

Warning when HTTP used instead of HTTPS

I have a pure CherryPy server which has been running for a few years already. I decided recently to add SSL support. In this case it was enough to provide the certificate and key files and to assign correct values to the variables cherrypy.server.ssl_certificate and cherrypy.server.ssl_private_key.
I would like to give a warning about this change whenever somebody tries to access a page using "http://..." instead of "https://...". Is there a simple way of achieving this without many changes in my system? Another option would be to redirect the HTTP access to HTTPS—can that be done easily?
I would create a custom handler to achieve what you're after. This automatically redirects to HTTPS.
class Functions():
def check_ssl(self=None):
# check if url is in https and redirect if http
if cherrypy.request.scheme == "http":
cherrypy.HTTPRedirect(Referer.replace("http:", "https:"))
cherrypy.tools.Functions = cherrypy.Tool('before_handler', check_ssl)

redirect in .htaccess

I am trying to point www.mydomain.example/blogs to www.anotherdomain.example/blog.html and still keep the URL the same, any ideas?
I have tried so many different methods and the URL changes to the URL im am redirecting to.
Thanks
Unless both domains are hosted on the same server and you have access via the file system, you will probably need a proxy on mydomain.example that forwards the requests to anotherdomain.example, fetched the response and forwards it back to the client.

Reverse proxy mode Apache intercept or trap 302 responses from backend server and redirect internally without sending 302 response back to client

Does anyone knows how to tell Apache, in reverse proxy mode, to intercept or trap 302 (or 30x) responses from backend server and redirect internally without sending 30x response back to client?
Ultimately, the backend server the response is redirected to would not be accessible from the outside (or not listed in Apache conf).
My situation:
I have web_server_A and web_server_B listening on port 6666 and 7777. These ports are not accessible from outside, but are accessible from the inside.
I can eventually change the behavior of web_server_A, but not the one of web_server_B.
Apache is listening on ports 80/443, accessible from the outside and is acting as a reverse proxy sending requests addressed to web_server_{A,B}.example.com to web_server_{A,B}
The client asks Apache for web_server_A.example.com/foo. Apache proxies the request to web_server_A which makes some stuff and then sends back to Apache a HTTP/302 response pointing on web_server_B.example.com/bar/secret_token. Apache sends back the 302 response to the client which then sends Apache an HTTP request for web_server_B.example.com/bar/secret_token. Apache proxies the request to web_server_B, which replies something (usually it sends back some big file).
My problem:
I don't want the client to know about the url web_server_B.example.com/bar/secret_token, and ultimately I don't want web_server_B to be accessible from outside.
web_server_A could make the request to web_server_B and then send back the answer from web_server_B without issuing a 302 reply. But, the answer from web_server_B might take some time to come, might be quite big, and web_server_A should not spend too much time on any request (it has no ability for handling big files).
So I thought about a "302 trapper" feature that would be nice if existing, but so far haven't fund anything on the web on how to do that. Any idea?
As a reverse proxy, Apache won't be able to "block replies." It's not a censor.
You could write something like this yourself, though.
using ProxyPassReverse directive, web_server_A will modify Location header sent by web_server_B, so the client won't know about him.
to trap redirect from upstream server you can also edit Location header. For instance "Header unset Location" will show apache default 30X error page