In Progress
Status Update
No update yet.
Comments
ja...@gmail.com
Hello
This feature request has been forwarded to the product management team. You can track this thread to post any further comments or check the updates regarding this feature request. However we can't provide you with any ETA at this point.
This feature request has been forwarded to the product management team. You can track this thread to post any further comments or check the updates regarding this feature request. However we can't provide you with any ETA at this point.
uc...@google.com
+1, We cannot create AJAX requests to APIs on a subdomain that are behind IAP because of this. The IAP seems to ignore the "Allowed JavaScript Origins" in the OAuth Client ID settings, it should be sending an Access-Control-Allow-Origin: <list of allowed origins> on the 302 redirect.
Example:
Failed to loadhttps://api.staging.example.com/endpoint : Redirect from 'https://api.staging.example.com/endpoint ' to 'https://accounts.google.com/o/oauth2/v2/auth?client_id=.. .' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'https://staging.example.com ' is therefore not allowed access.
Example:
Failed to load
bu...@google.com
ni...@gmail.com
We ran into the same problem, which seems to make IAP unusable when serving an API.
Hopefully this can be solved quickly
(GCP support ticket [#16518176])
Hopefully this can be solved quickly
(GCP support ticket [#16518176])
is...@google.com
im...@google.com
ja...@gmail.com
Hi, I also ran into the problem of CORS not supporting IAP. Here's my workaround, in case anyone else finds it useful.
In the same GCP project I have two App Engine services:
- A UI server
- An API server
The UI server makes calls to the API server. To get around the CORS problem, I use Routing with a dispatch file:
https://cloud.google.com/appengine/docs/standard/python/how-requests-are-routed#routing_with_a_dispatch_file
Normally, when the UI server wants to call API server, it callsapi-dot-MY_PROJECT.appspot.com
In this workaround, the UI server calls itself with a specified path ("/api"):MY_PROJECT.appspot.com/api
Since the UI server is calling itself, CORS does not apply.
In the same GCP project I have two App Engine services:
- A UI server
- An API server
The UI server makes calls to the API server. To get around the CORS problem, I use Routing with a dispatch file:
Normally, when the UI server wants to call API server, it calls
In this workaround, the UI server calls itself with a specified path ("/api"):
Since the UI server is calling itself, CORS does not apply.
im...@google.com
:+1:
yo...@gmail.com
+1
bu...@google.com
ra...@gmail.com
+1. The dispatch rules workaround is helpful but obviously not ideal and doesn't handle Kubernetes use cases.
im...@google.com
lu...@google.com
[Deleted User] <[Deleted User]>
+1. This is a big problem for us. We're trying to hit our API server (which is behind IAP) from embedded JS hosted on a domain that we trust but do not control. Currently impossible even with the suggested workaround.
Description
While tools like ProGuard and R8 will removed unused code, it's always a good idea to only depend on the minimal subset of required dependencies. So aside from manually poke-testing this by removing dependencies, it would be great to have Lint check this.
This is probably something that would be disabled by default as I suspect it involves quite a bit of work to validate. I assume it's just visiting every type reference in the module (both in classes, layouts, drawables, and manifest) and aggregating into a set and then validating that at least one type in each dependency is in that set.
Bonus points for supporting Class.forName() usage with a string literal argument!