I have a dev server serving my rest API which is using SSL at https://api.stg.something.com
I also have the same API working from localhost at http://localhost:5000
Now i want with Fiddler to redirect every api request(POST,GET) to my dev server into localhost for debugging reasons
I added to FiddlerScript's static function OnBeforeRequest
if (oSession.HostnameIs("api.stg.iot.vodafoneinnovus.com")) oSession.host = "localhost:5000";
but that not seems to work. When i hit a request from Postman to lets say https://api.stg.something.com/api/stuff
i don't get the response and fiddler inspector says
fiddler.network.https> HTTPS handshake to localhost (for #6) failed. System.IO.IOException The handshake failed due to an unexpected packet format.
The fiddler trying to establish a Secure connection but localhost refuse it.
How can i go from https request to http in fiddler?
Is this supported?
A controller with incoming https request on one port, the controller calling a https web service with RestTemplate and forwarding the service response.
That isn't really multiple SSL connections. If you look at it as incoming and outgoing requests. On the incoming request to support SSL the server has to emit a certificate. It can be self signed or from a root authority. For the outgoing request the app is specifying that the protocol is HTTPS and then validating the server certificate is valid. If the certificate being validated is from a know root cert then the http client handles that on your behalf. If not then you would have to add the root cert to your keychain.
Now with that understanding there is nothing stopping you from configuring multiple incoming SSL endpoints and as well making multiple outgoing SSL requests. It is just a matter of configuring the specific connections. For that I would refer you to the Spring reference documentation as it has a lot of information on it as well as examples.
What does it mean when an application calls another application via 2 way SSL.
Does it mean that an external application calls another application via https and also receives a https response.
Similarly if it was one way SSL, does it mean it sends a https request but the response will be http.
Our web application has a button that is supposed to send data to a server on the local network that in turn prints something on a printer.
So far it was easy: The button triggered an AJAX POST request to http://printerserver/print.php with a token, that page connected to the web application to verify the token and get the data to print and then printed.
However, we are now delivering our web application via HTTPs (and I would rather not go back to HTTP for this) and newer versions of Chrome and Firefox don't make the request to the HTTP address anymore, they don't even send the request to check CORS headers.
Now, what is a modern alternative to the cross-protocol XHR? Do Websockets suffer from the same problem? (A Google search did not make clear what is the current state here.) Can I use TCP Sockets already? I would rather not switch to GET requests either, because the action is not idempotent and it might have practical implications with preloading and caching.
I can change the application on the printerserver in any way (so I could replace it with NodeJS or something) but I cannot change the users' browsers (to trust a self-signed certificate for printerserver for example).
You could store the print requests on the webserver in a queue and make the printserver periodically poll for requests to print.
If that isn't possible I would setup a tunnel or VPN between the webserver and printserver networks. That way you can make the print request from the webserver on the server-side instead of the client. If you use curl, there are flags to ignore invalid SSL certificates etc. (I still suspect it's nicer to introduce a queue anyway, so the print requests aren't blocking).
If the webserver can make an ssh connection to something on the network where the printserver is on, you could do something like: ssh params user#host some curl command here.
Third option I can think of, if printserver can bind to for example a subdomain of the webserver domain, like: print.somedomain.com, you may be able to make it trusted by the somedomain.com certificate, IIRC you have to create a CSR (Certificate Signing Request) from the printserver certificate, and sign it with the somedomain.com certificate. Perhaps it doesn't even need to be a subdomain for this per se, but maybe that's a requirement for the browser to do it client-side.
The easiest way is to add a route to the webapp that does nothing more than relay the request to the print server. So make your AJAX POST request to https://myapp.com/print, and the server-side code powering that makes a request to http://printerserver/print.php, with the exact same POST content it received itself. As #dnozay said, this is commonly called a reverse proxy. Yes, to do that you'll have to reconfigure your printserver to accept (authenticated) requests from the webserver.
Alternatively, you could switch the printserver to https and directly call it from the client.
Note that an insecure (http) web-socket connection on a secure (https) page probably won't work either. And for good reason: generally it's a bad idea to mislead people by making insecure connections from what appears to them to be a secure page.
The server hosting the https webapp can reverse proxy the print server,
but since the printer is local to the user, this may not work.
The print server should have the correct CORS headers
Access-Control-Allow-Origin: *
or:
Access-Control-Allow-Origin: https://www.example.com
However there are pitfalls with using the wildcard.
From what I understand from the question, printserver is not accessible from the web application so the reverse proxy solution won't work here.
You are restricted from making requests from the browser to the printserver by cross-origin-policy.
If wish to communicate with the printserver from an HTTPS page you will need the printserver to expose print.php as HTTPS too.
You could create a DNS A record as a subdomain of your web application that resolves to the internal address of your printserver.
With those steps in place you should be able to update your printserver page to respond with permissive CORS headers which the browser should then respect. I don't think the browser will even issue CORS requests across different protocol schemes (HTTPS vs HTTP) or to internal domains, without a TLD.
i have a webservice which is being consumed by my website using ajax. since im using ajax i cannot have ip restrictions on my webservice. i know i can always add an additional layer of security by using a proxy to call my webservice and the ajax code calls the proxy not the webservice. this way i can always restrict access to my webservice to only allow requests from the proxy
but the end problem is not solved. that is any smart end user can always come to know the proxy url im using from my ajax code and fire requests to this proxy to access all the webservice data
how do i secure my webservice (with or without proxy) such that it only serves requests which come from my website
i can always use http_referrer check in my proxy but thats easy to hack...
is there a fool proof way of doing this
One of the ways you can implement this is by using two way SSL authentication for your website.
In two-way SSL authentication, the SSL
client application verifies the
identity of the SSL server
application, and then the SSL server
application verifies the identity of
the SSL-client application.
Two-way SSL authentication is also
referred to as client authentication
because the application acting as an
SSL client presents its certificate to
the SSL server after the SSL server
authenticates itself to the SSL
client.
This way before executing any WS request your WS will first check if your client has the valid SSL certificate or not. If it does not then the WS will not execute. Implementing two way SSL requires configuration at both ends and can be slightly complicated to implement. However once setup this is a really secure way to call your webservice and ensure that only authorized clients(who already have the certificate) make those calls. So your AJAX code can make a call to a Servlet which in turn can make the call to this service. This way your service url is also not exposed to the browser.