Is it possible to configure the proxy on a secured route so that on a redirect the location header field in the response is rewritten to HTTPS?
I get Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at http://complan-complan.a3c1.starter-us-west-1.openshiftapps.com/planner
when I log in to the application. But also without login the request to the above URL is redirected to HTTP and again to HTTPS.
Thanks!
When the exposed route in OpenShift is set to TLS edge termination then the build-in HAProxy will terminate the HTTPS connection and create a new HTTP connection to your application.
To get the original client-ip/protocol/port the proxy inserts the HTTP headers X-Forwarded-For, X-Forwarded-Proto and X-Forwarded-Port.
For redirection to work correctly you have to tell your framework/server to use those fields. In your case with Wildfly you can follow theses instructions
There are samples for other frameworks/servers in the OpenShift FAQ:
https://developers.openshift.com/faq/troubleshooting.html#_how_do_i_redirect_traffic_to_https
Related
I understand preconnect tells a browser to perform DNS lookup, TCP connection & TLS handshake(in HTTPS) with a given host. All of of those processes are done, prior to sending any HTTP packets, although HTTP version might be negotiated during TLS handshake(ALPN).
I believe that crossorigin attribute affects the following:
No crossorigin attribute: Origin header is not sent, because of which server never sends Allow-Control-Allow-Origin header which can enable CORS.
anonymous mode: Origin header is sent & CORS can be enabled, but Cookies & authentication are not sent during a request.
use-credentials mode: Origin header is sent together with Cookies & Authentication header, which may enable CORS.
Origin, Cookies & Authentication are sent in HTTP request, after DNS+TCP+TLS was already established. In such case, why would crossorigin attribute matter during preconnect?
TLS client certificates.
The browser can authenticate itself to the server not just in HTTP headers when sending a request (at the application layer), but while still establishing a TLS session (at the transport-ish layer), using a client certificate. This requires the browser to know whether such authentication should be performed or not.
This is specified in the HTML Standard and in the Fetch Standard. As of this writing (October 2022), preconnecting is specified as directing the browser to obtain a connection, which in turn is defined in terms of creating a connection, which in step 2 chooses whether to use a certificate based, ultimately, on the CORS credential policy setting specified in the crossorigin= attribute. TLS certificates are currently the only authentication mechanism that CORS credential policy influences at the connection stage.
Exposed https soap service using openshift router TLS edge termination, but the xsd schema it is still taking as http reference.
examples: Service url https://example.net/test?wsdl
but when accessing above wsdl on browser, it is generating xsd schema reference as
Please let me know how we can refer the schema in relative way.
As you can see in following PR, openshift haproxy should correctly add X-Forwarded-Proto header with http or https value. Your software should either use relative links if possible, if not, you can use the value of this header to check if your app was exposed by external load balancer as http or https and provide url's apropriately.
I am building a "proxy client" extension for chrome and i have following scenario:
Users can login to the extension and get a token from API. Tokens are valid for 2 hours.
After login users can select a proxy server from a list and that proxy is set with chrome.proxy api.
I am using Squid on proxy servers. When a user connects to a proxy server and lands on onAuthRequired i return email and token as authCredentials.
Chrome uses those credentials from cache until token is not valid anymore and proxy server responses "407, Proxy Authentication Required". Now the problem i am facing here is when i login with another username on same browser and connect to same proxy server it still sends old users credentials to the server because they are still valid. My question is how can delete chromes proxy auth cache so that it lands onAuthRequired again and i can return new users Credentials.
I tried to modify the response from proxy server to "407, Proxy Authentication Required" when user makes his first request over the proxy server to force a onAuthRequired but its not working. Chrome still uses cache and still returns credentials from old user to the proxy server.
Have you tried to hook up another event handler within the webRequest API in order to manipulate the http headers before Chrome takes on authentication?
E.g. onBeforeSendHeaders or onHeadersReceived
I have been trying to set up an Orion instance which would support subscription notifications to HTTPS (using Rush), but the handling of this seems to be a bit incorrect. Setting the notification url to e.g. https://www.example.com/path/ ends up at Rush as www.example.com:443/path/.
This is unsafe and not up to standards, as such a request could actually avoid https by using the same port over http. In our company we have a proxy set up which refuses such requests as "Bad Request: You're speaking plain HTTP to an SSL-enabled server port". The same error comes up in the Rush consumer output, while direct curl requests to Rush without the port work ok. See this discussion for another argument that the current requests are incorrect: https://security.stackexchange.com/questions/46015/speaking-plain-http-over-an-ssl-enabled-server-port. Google refuses such requests as well.
Our proxy is set up to redirect any http requests to https, but these do not work either, as Rush does not seem to follow the redirects.
How can we avoid this issue? Modifying our proxy would be unsafe and not following standards, changing Orion would require recompiling from sources and changing Rush to remove the port would be a bit hacky. Any changes (like adding the port or removing/changing the protocol) to the notification URL do not help.
EDIT: The command to run Orion was:
/usr/bin/contextBroker -port 1026 -logDir /var/log/contextBroker -pidpath /var/log/contextBroker/contextBroker.pid -dbhost localhost -db orion -rush localhost:5001
Rush (v 1.8.3) was installed with default values and Orion was updated from v0.14.1 to v0.23.0.
Since verion 1.7.0, Orion implements native HTTPS notifications (i.e. without needing Rush). This could help to solve the situation described in this question.
I have two websites functioning under Google Compute Engine VM instances. Both sites accept requests and communicate only via HTTPS and not on HTTP.
How can I properly set a Network Load Balancer forwarding rule under GCE for HTTPS? I have my forwarding rule set on both port 80/443 (HTTP/HTTPS) but my health check always shows unhealthy. It seems like it can't handle HTTPS forwarding.
The way I have my site only doing HTTPS is by having a mod header loaded in Apache and strict transport security enabled. I then have a rewrite rule from HTTP to HTTPS for all requests.
As stated here,
There are two types of health checks available:
HTTP health checks, which are required for HTTP and network load
balancing.
HTTPS health checks, which are required when setting up
backend services to use HTTPS.
Therefore, a network load balancer uses an HTTP health check and it can't handle HTTPS forwarding. You'll need to setup a website, at least for the health check, that allows HTTP and returns an HTTP response with code 200.