I'm trying to work with Kubernetes API server from Angular JS front-end app. The API server uses https endpoint. The front-end app is deployed to the other server.
Despite the --cors-allowed-origins=.* (or --cors-allowed-origins=["http://*"]) param for kube-apiserver I can't access API because when I try to make GET XHR request, pre-flight OPTIONS request failed with 401 response without CORS headers.
However, when I switch from https to http, everything works fine.
Looks like I'm facing this issue, which is already fixed and merged in the version of Kubernetes I'm using.
Versions are Kubernetes 1.2.4, Angular JS 1.5.4 and Chrome 51.
Could you tell me why it happens and how to fix this? I need a working solution for https.
The issue you linked to was fixed, but a regression in CORS handling was introduced by kubernetes/kubernetes#18113 and has yet to be fixed (see kubernetes/kubernetes#24086). It is currently marked as a known issue for the imminent 1.3 release, which means that it is an outstanding bug.
You can edit kubernetes API server yaml file, to get CORS working.
Location: /etc/kubernetes/manifests/kube-apiserver.yaml
Add - --cors-allowed-origins=http://www.example.com,https://*.example.com this line under kube-apiserver
spec:
containers:
- command:
- kube-apiserver
- --cors-allowed-origins=http://www.example.com,https://*.example.com
Coma separated domains or regular expressions you can add.
No need to restart kube-apiserver, once file saved kube-apiserver will automatically restart.
it will take 5 to 10min time to get API server up.
Related
exact issue:- call POST https://postman-echo.com/post API from react js Axios give cors error, is it possible? or any other frontend do this?
code sandbox:- https://codesandbox.io/s/axios-forked-gjj82c?file=/src/index.js:257-264
NOTE:- check error in network
I am working on some tasks where I need to call some other APIs from different domains and some of the APIs give me cors error.
my boundaries are
localhost, local IP, other IP, domain with port or subdomains
EX:-
http://localhost:5000/test
http://192.168.0.111:5000/test
http://3.91.432.163:5000/test
https://postman-echo.com/post
Any frontend language I can choose.
I have tried multiple ways but can not solve it
but find 1 way to do this stuff using cors-anywhere
I have created 1 server using this package and called blocked URL by using it
EX:- as in question call API using Axios with URL
http://localhost:6000/https://postman-echo.com/post
HERE http://localhost:6000 is my cors-anywhere server
and it works for me
NOTE:- you can use https://cors-anywhere.herokuapp.com/ hosted server too(it is the demo of this package)
I have a locally hosted wordpress installation using woocommerce, and a separate locally hosted react webapp that will be used to manage the products. I'm using the woocommerce-rest-api react plugin to call the end points.
GETs work fine and don't have any issues, however PUT and DELETE I'm having issues with CORS.
I've updated the wordpress htaccess:
and call the endpoint like so:
and this is what I get in dev tools:
Here is the preflight headers and response and then the failing call:
Any ideas what I'm doing wrong or what I've missed?
Your preflight response from (what i assume is the wordpress server) appears to be missing the Access-Control-Allow-Origin header in the response (sent back from the OPTIONS request).
To match your other requests this should be *. However it is not best practice to use * for security reasons and should instead use the domains you want to be able to access this from browsers.
I am trying to enable HTTPS on my Go App deployed to GAE flex environment. I have my custom domain successfully mapped, and am using Google-managed SSL certificates. I have app.yaml configured to redirect HTTP to HTTPS as follows:
handlers:
- url: /.*
script: _go_app
secure: always
Now there are two problems that I haven't been able to resolve so far.
First, the above configuration is supposed to redirect HTTP traffic to HTTPS, but apparently it is not happening.
Second, when I add https:// in the url box, I see three different behavior on Firefox, Chrome, and Edge. Edge identifies the website as secure, Firefox marks the website as secure connection, but says that it "has blocked parts of this page that are not secure", and surprisingly Chrome marks the website as Not secure (though it says certificate is valid!).
With these symptoms I was wondering if I should take additional steps to make redirecting and SSL work for my website? Specifically, I would like to know with App Engine, and managed SSL enabled:
Should I continue serving pages on HTTP using http.ListenAndServe(..), or need to switch to http.ListenAndServeTLS(..)?
In my Go app should I redirect HTTP to HTTPS? or the above setting is expected to work just fine?
Thanks in advance for your help and advice.
PS:
Trying out with different suggestions, I added Strict-Transport-Security: max-age=31536000; includeSubDomains to handlers' response. Does not seem if this helped with redirection either.
EDIT/PARTIAL ANSWER:
According to this documentation, under Authentication changes, the secure and login handlers are deprecated. The documentation suggests using Strict-Transport-Security or X-Forwarded-Proto instead.
I am using Strict-Transport-Security on the server side to enrich my response header:
func (h *STLHandler) ServeHTTP(w http.ResponseWriter, req *http.Request) {
w.Header().Add("Strict-Transport-Security", "max-age=63072000; includeSubDomains")
h.nextHandler.ServeHTTP(w, req)
}
I was wondering if I am using this header in the right place?
For the second set of my problems I realized I have mixed content on my page. My mixed content was a http link to a set of fonts. When I fixed the mixed content, i.e. changed http to https, both Chrome and Firefox security warnings disappeared. You may also find this page Avoiding the Not Secure Warning in Chrome useful on this matter.
You need to check your app using:
http://[YOUR_PROJECT_ID].appspot.com
Or if you nedd HTTPS:
https://[YOUR_PROJECT_ID].appspot.com
If you want your own certificate you will need to upload it and then be available to use: https://your-domain.tld
From the docs:
For APIs that will be hosted on App Engine flexible environment, you must use the appspot.com domain, and the service name must be in the following format:
YOUR_PROJECT_ID.appspot.com
When you deploy your API to App Engine, a DNS entry with a name in the format YOUR_PROJECT_ID.appspot.com is created automatically.
For APIs that will be hosted on Compute Engine, Kubernetes Engine, or Kubernetes, you must use the cloud.goog domain, and the service name must be in the following format:
YOUR_API_NAME.endpoints.YOUR_PROJECT_ID.cloud.goog
Or you could just put a CDN in front like Cloudflare which will do all the SSL termination for you and if required redirect all HTTP to HTTPS
I'm using ReactJs and Axios to send API requests to my server but I keep getting the same error:
Failed to load http://***: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost:3000' is therefore not allowed access. The response had HTTP status code 400.
I'm trying to perform a POST request. I've also tried to download a Chrome Plugin to allow CORS. It did work for the GET requests, but not working for POST it looks like.
If I try to make requests to https://jsonplaceholder.typicode.com/users it's working fine. So I guess there's something wrong with the server.
My server is using Nginx and is on a CentOS 7 OS.
Q: How is it possible to enable CORS just for my local development (localhost) or specific websites?
EDIT: I have already tried using this config on my Nginx server - without luck: https://enable-cors.org/server_nginx.html
While I can't answer you with some specific code, here's what happens (at least what happened last time I tried Angular and had similar issues):
Before sending any further requests, there'll be a header only OPTIONS HTTP request sent to the server URL. When answering this call, the server is supposed to send a header field Access-Control-Allow-Origin containing a whitelist of domains allowed to do further calls using the API. To whitelist all requests in your dev environment it should be enough to set Nginx to answer with Access-Control-Allow-Origin: *.
For development I use the Firefox extension CORS Everywhere. It modifies all web traffic, to include the correct CORS headers. (It works at least with the somewhat dated Firefox in Opensuse 42.3.)
https://addons.mozilla.org/en-US/firefox/addon/cors-everywhere/
Note, that this subverts a security mechanism of the browser.
For deployment you must configure the server, to send the correct CORS headers. (I did never do this, the finished website is planned to work in a single IP.)
If you have access to the server and the server is using Nodejs, this should work for you:
CD into your server folder:
cd server-folder
Then run this command in order to install the 'cors' package:
npm install cors
In order to access this package, go into your server file in your IDE and in the next available line:
const cors = require('cors');
Next, add this line to use the middleware (assuming you are using Express):
app.use(cors());
I'm starting to use cloud endpoints in my GAE project but have been running into issues with the api not updating on the server.
localhost:8888/_ah/api/explorer is ok.
But when I deploy, nothing changes.
myapp.appspot.com:8888/_ah/api/explorer is bad
Further investigation shows the url end points update
example: https://myapp.appspot.com/_ah/api/myapp/v1/foo/list
But the loaded client api is still incorrect.
example: gapi.client.load('myapp', 'v1', callback, url);
gapi.client.myapp.foo.list();
If I changed the call from foo/list to foo/list2, the rest url would update, the api package would not.
I'll try to cover the two cases people could run into:
Client Side:
The Google APIs Explorer web app aggressively caches, so you'll need to clear your cache or force a refresh when you update your API server side to see the changes in the client.
Server Side (In Deployed Production App Engine App):
If you're having deployment issues, there are two places to look when debugging:
Check your Admin Logs (https://appengine.google.com/adminlogs?&app_id=s~YOUR-APP-ID) after deployment. After a successful deployment of your application code, you should see the message:
Completed update of a new default version
and shortly after that you should see:
Successfully updated API configuration
If you this message indicates the API configuration update failed, you should deploy again. If said error is persistent, you should notify us of a bug. If you don't see any message about your API configuration, you should check that the path /_ah/spi/.* is explicitly named in your routing config (app.yaml for Python, web.xml for Java).
Check your Application Logs (https://appengine.google.com/logs?&app_id=s~YOUR-APP-ID) after deployment. After the deployment finishes, Google's API infrastructure makes a request to /_ah/spi/BackendService.getApiConfigs in your application so that your API configuration (as JSON) can be registered with Google's API infrastructure and all the discovery-related configs can be created. If this request does not complete with a 200, then your API changes will not show up since Google's API infrastructure will have nothing to register.
If you are consistently getting a 302 redirect for requests to /_ah/spi/BackendService.getApiConfigs, it is because you (or your generated API config) have specified a "bns adapter" that uses http: as the protocol in your API root, but your web.xml (Java) or app.yaml (Python) is required that paths through /_ah/spi are secure. This will make requests using http: as the protocol be redirected (using 302) to the same page with https: as the protocol. This was discussed on the Trusted Tester forum before going to Experimental.
This is what happened to me.
I tested my endpoint on localhost and it worked fine.
I deployed my endpoint on appspot and when I made requests to it I received in the browser the message 'Not found'.
So I looked in the logs and when I made requests to the endpoint I saw a 404 http error code on favicon file. And in effects I forgot to put that file in my deploy.
So I redeployed my war with the favicon file, the 404 http code disappeared and the endpoint worked fine on appspot too!
I realize that this may sound silly, but it is what I experienced. (I apologize for my poor english)
I noticed that if you upload your app for the first time without the following in your web.xml:
<security-constraint>
<web-resource-collection>
<url-pattern>/_ah/spi/*</url-pattern>
</web-resource-collection>
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
</security-constraint>
Then your bns adapter will be set as http going forward. When I add the above afterwards, I get 302 http code on /_ah/spi/BackendService.getApiConfigs and the endpoints never update.
So now I have reverted to not use https on /_ah/spi and my endpoints are updating. I guess for those that see their endpoints not being updated revert back to the first configuration they had for ssl on /_ah/spi/.
Yaw.
I had the same error Not Found (the 404 error code) when I was calling my API using this URL
https: // MY_APP_ID.appspot.com / _ah / api / MY_SERVICE / v1 / user
I tried everything and finally fixed it by removing the discovery files from WEB-INF and kept only MY_SERVICE-v1.api and then redeployed the API. It works fine now.
I was also getting stale API discovery doc after deploying new version, it took a couple of minutes for GAE to start serving the new one to me.
I had the same problem, and I checked the admin logs, other logs etc... but still my API wasn't updating to the latest version.
So I decided to check in the API code for the last method I had written (I am writing in Java 7). And I found out that GAE doesn't like statements like:
if (!blocked){ .... }
I switched that to:
if (blocked == false) { ... }
And it worked like a charm. So by the looks of it, GAE scans the new API methods and doesn't accept some shortcuts.