We are using Auth0 integration to provide authentication for our spring boot application.
An application is deployed with docker in google cloud run.
But when I try to exchange tokens I receive an error from auth0 "Expected https://.. but go http://."
The reason why it is happening is that httpServletReuqest.getRequestURI() returns http instead of https.
The question is why getRequestURI returns http when our website deployed as https in cloud Run?
I also logged nginx headers and X-Forwarded-Proto = https.
Posting as Community Wiki since it is Based on the comments of #EmilGi and #GuillaumeBlaquiere.
As you can see in this documentation:
Cloud Run redirects all HTTP requests to HTTPS but terminates TLS before they reach your web service. If your service generates a web resources that refers to other web resources with unsecured URLs (http://), your page may be subject to mixed content warnings or errors.
And you cannot turn off this restriction since Cloud Run is deployed behind the GFE (Google Front End) in charge of the TLS communication.
Related
I have a vps, where my spring boot backend is running on. The frontend is a mobile app built with the ionic framework.
The backend is built this way: in the front there is an so called resource server, which is an graphql server, which redirects the requests to rest microservices which are behind the resource server. Every microservice has is own task, which he's responsible for. (e.g. an fileupload-server which uploads/downloads files to a database). The whole application, including the frontend is secured by an keycloak instance, which is running as an docker container like the whole application, except the frontend.
Now my questions is, we dont have a domain and for some reason they wont buy one, but we wont to secure the communications over ssl/lets encrypt. But lets encrypt isn't able to create ssl certificates for ip adresses. So finnaly my question is: do you guys, know a solution to my problem which fits?
So far,
Daniel
I have WebAPP and WEBAPI on same server. I have applied SSL certificate on both the sites under same server (both are separate applications under common IIS default website).
Now my point, Can I access same WEBAPI over http instead of https form 3rd intranet application on same server and which is not a secure application?
My intention to not hamper performance for 3rd site which is not secured and on the same server.
Actually It depends on your configuration.
Generally, when you apply SSL on web server your app can now be accessed over http and https both connections.
But, if you have configured it to redirect http version to https using CSP or server end configuration, then you can access http version as all requests will get automatically redirected to https version.
You should read IIS related materials to learn what is site binding. A web site can of course contain multiple bindings, both HTTP and HTTPS, so that clients (like web browsers) can access using both http:// and https://.
https://blogs.technet.microsoft.com/chrad/2010/01/24/understanding-iis-bindings-websites-virtual-directories-and-lastly-application-pools/
When we access the WEB API service methods from a web application through Ajax calls, will there be any access restrictions for the following scenarios
“HTTPS” Web application accessing an “HTTP” WEB-API
“HTTP” Web application accessing an “HTTPS” WEB-API
Will there be any impact on request application or context, either it Http or Https the web API will behave same.
Please advice.
When you trying to access the "HTTP" Api or any service from the HTTPS or SSL enabled client, then the security itself is compromised.
SSL certificate is enable to maintain the higher level of security, in any HTTPS enabled client, when you access the Non SSL or HTTP ApI then you have to specify the Transport layer explicitly to allow the process of data [example IOS client - Application Transport]
Even if you have requirement to access the HTTP API, please go through this reference.
Make Https call using HttpClient
I have java scripts web application calling my ASP.NET web API 2 Service under same web site in my AppServer. The application is working fine.
I setup Proxy Server and URL Rewrite to my Application Server. Everything is working fine with Http but can't call web api from JavaScript with Https
I put CROS and add the Proxy Server but still doesn't work.
But I can directly call web api with https
Kindly Advice!
Regards,
Si Thu
Finally, I found out that it is because of Mixed Content Issue between proxy server and application server. App Server also need to be HTTPS
Issue is solved by adding certificate in App Server.
I have developed a web app that does its own user authentication and session management. I keep some data in Elasticsearch and now want to access it with Kibana.
Elasticsearch offers a RESTful web API without any authentication and Kibana is a purely browser side Javascript application that accesses Elasticsearch by direct AJAX calls. That is, there is no "Kibana server", just static HTML and Javascript.
My question is: How do I best implement common user sign on between the existing web app and Elasticsearch?
I am interested in specific Elasticsearch/Kibana solutions, but also in generic designs for single sign on to web apps and the external web APIs they use.
It seems the recommended way to secure Elasticsearch/Kibana is to have an Apache or Nginx reverse proxy in front that does SSL termination and user authentication (Basic auth). However, this doesn't play too well with the HTML form user authentication in my existing web app. Ideally I would like the user to sign on using the web app, and then be allowed direct access to the Elasticsearch API as well.
Solutions I've thought of so far:
Proxy everything in the web app: Have all calls go to the web app (server) which does the authentication, and have the web app issue the same request to the Elasticsearch web API and forward the response back to the browser.
Have the web app (server) store session info that Apache or Nginx somehow can look up and use to authorize access to the reverse proxy.
Ditch web app sign on and use basic auth for everything.
Note that this is a single installation, so I don't really need any federated SSO solutions.
My feeling is that the proxy within web app (#1) is a common generic solution, but it seems a bit heavyweight to have everything pass through the possibly slow web app, considering that Kibana uses the Elasticsearch API directly.
I haven't found an out of the box solution designed for the proxy authentication setup (#2). My idea is to have the web app store session info in memcache or the like and use some facility in the web server (Apache or Nginx) to look up the session based on a cookie and allow proxy access if authenticated.
The issue seems similar to serving static files directly using the web server (Apache or Nginx) while authenticating using a slow web app. Recommendations I've found for that are however very specific to that issue, like X-Sendfile.
You could use a sessionToken. This is a quite generic solution. Let me explain this. When the user logs in, you store a random string an pass him back to him. Each time the user tries to interact with your api you ask for the session Token you gave him. If it matches, you provide the service he is asking for, else, you just ignore his call. You should make session token expire in a certain interval of time and make a new one each time the user logs back in.
Hope this helps you.