Feature Request P0
Status Update
Comments
ar...@google.com <ar...@google.com> #3
Hi, this error only affects Cloud SDK version 186. It was previously reported in Issue 72407295 and a fix for it should be released in Cloud SDK version 187.
In the mean time, you can downgrade to Cloud SDK version 185 as a workaround by running the following command:
gcloud components update --version 185.0.0
In the mean time, you can downgrade to Cloud SDK version 185 as a workaround by running the following command:
gcloud components update --version 185.0.0
de...@derekperkins.com <de...@derekperkins.com> #4
I didn't set it to Restricted on purpose, so feel free to make it public.
Thanks for the feedback. I'm aware of the state parameter, but that still requires a lot of redirects that defeats the purpose of white labeling.
Thanks for the feedback. I'm aware of the state parameter, but that still requires a lot of redirects that defeats the purpose of white labeling.
de...@derekperkins.com <de...@derekperkins.com> #5
In terms of user feedback for this issue, I filed an issue on the App Engine tracker a year and a half ago, but the scope of the issue has now moved out to GCP. As of today, there are 38 stars there for this issue:
https://code.google.com/p/googleappengine/issues/detail?id=11796
ar...@google.com <ar...@google.com> #6
[Comment deleted]
ar...@google.com <ar...@google.com> #7
[Comment deleted]
ar...@google.com <ar...@google.com> #8
Thanks, I've updated the issue and submitted your request. It seems that adding the 'Security' tag automatically sets the issue to 'private', so I've removed it.
ar...@google.com <ar...@google.com> #9
I have forwarded this request to the engineering team. We will update this issue with any progress updates and a resolution. Note that for feature requests there is no guarantee of any time frame for updates or that the requested feature will be implemented.
al...@gmail.com <al...@gmail.com> #10
Guys, almost a year passed from the last comment, any movements in the direction to solve issue which doesn't allow to use your services in SaaS? You lose huge market not solving this problem.
gr...@classexception.com <gr...@classexception.com> #11
I need to enter 2136 entries into the Authorised JavaScript Origins section, which is making life rather unpleasant =(
[Deleted User] <[Deleted User]> #12
Please allow the domain to be entered without the subdomain (example.com ) or allow wildcards. Same as facebook auth --- Additional 'vote' to suggest the current limitation of not allowing 'blanket subdomains' to be making life very unpleasant
ne...@skywardapps.com <ne...@skywardapps.com> #13
This also makes life difficult for continuous integration scenarios, where we deploy to a new subdomain with each revision. We were using google sign in for our projects, but since it cannot be used on these dynamically generated subdomains it is pretty worthless, and we're backing it out and using alternatives.
al...@gmail.com <al...@gmail.com> #14
Same boat.
th...@gmail.com <th...@gmail.com> #15
While this would make life way easier, i don't believe this should be a P0 issue personally i think its more of a P1 or P2 issue.
zh...@gmail.com <zh...@gmail.com> #16
My company is unable to fully automate provisioning of our app environments because this operation needs to be performed manually, via the web console. Come on, Goog! You're better than this...
de...@giantthinkwell.com <de...@giantthinkwell.com> #17
I'd also like to see wildcarding for whitelisting subdomains
sh...@gmail.com <sh...@gmail.com> #18
I am not able to add enter the web site's address with 'http' in the Credentials section of Google Sheets API. I am receiving this error - Not a valid origin for the client: http://xxxx.xxxx.net has not been whitelisted for client ID xxxxx.apps.googleusercontent.com . Please go to https://console.developers.google.com/ and whitelist this origin for your project's client ID.
Please help me to sort this weird issue which does not allow me to whitelist the website's address starts with http.
Please help me to sort this weird issue which does not allow me to whitelist the website's address starts with http.
mi...@datanova.com.au <mi...@datanova.com.au> #19
Another year goes by. Any progress on this?
[Deleted User] <[Deleted User]> #20
Hello,
It's also been two years that I'm confronted with this problem when deploying a test branch (as a GAE version). I have to add the unique url by hand each time and wait an hour for the cache to be invalidated ...
The API would be good to do automatically in a CI, the wildcard even better.
II think you could consider at least the wilcard for your own AppEngine domain:
https://PROJECT_NAME.appspot.com
https://*-PROJECT_NAME.appspot.com
https://*-PROJECT_NAME.appspot.ew.r.com
This would be very practical and would avoid wasting a lot of time.
we...@thenounproject.com <we...@thenounproject.com> #21
What a bummer. Either allow wildcard subdomains OR allow updating the list via an API. It seems the API Keys API only allows managing API keys and not clients.
ho...@eano.com <ho...@eano.com> #22
Come on, Google! You're better than this...
ba...@gmail.com <ba...@gmail.com> #23
ma...@magnetcustomer.com <ma...@magnetcustomer.com> #24
+1
th...@ae.studio <th...@ae.studio> #25
+1
Description
1. Authorized JavaScript origins
2. Authorized redirect URIs
Without that, I can't built an auto-onboarding flow for new users because I have to manually enter the same subdomain in two separate input fields.
The workaround that we've considered is embedding an iframe from
Another option is to do multiple redirects on every login, but that isn't an ideal end-user experience, especially if we are running any white-label options.
Facebook solves this problem by allowing wildcards for their OAuth callbacks and CORS. Either that or an API is necessary to make Google login a competitive option.