Assigned
Status Update
Comments
go...@google.com <go...@google.com> #2
I have forwarded this request to the engineering team. We will update this issue with any progress updates and a resolution.
Best Regards,
Josh Moyer
Google Cloud Platform Support
Best Regards,
Josh Moyer
Google Cloud Platform Support
in...@codeweavers.net <in...@codeweavers.net> #3
This is not only useful for IP addresses, but also for many other resources. I understand that names are currently used as identifiers, so this request is probably not trivial to implement. Maybe distinguishing between a (numeric, automatically generated) identifier and a (textual) label is the way to go?
go...@google.com <go...@google.com> #4
Is it any hope? We have migrated our IP address to the server with different role, and now the name of this IP address resource doesn't match its role at all. It seems to be trivial enough to momentary reserve static IP address of the old named resource, drop resource, and immediately recreate it with the new name and the old IP address.
in...@codeweavers.net <in...@codeweavers.net> #5
This would also improve life when using the Google Deployment Manager (since it otherwise error's out if you've changed a name of an IP)
in...@codeweavers.net <in...@codeweavers.net> #6
Over 3 years to get something as basic as renaming a static IP address. Any progress here?
va...@google.com <va...@google.com> #7
Yes, I have a customer who has this exact issue too! Any updates or workarounds would be very appreciated!
in...@codeweavers.net <in...@codeweavers.net> #8
Any progress in here?
ma...@printful.com <ma...@printful.com> #9
I would like this feature as well.
in...@codeweavers.net <in...@codeweavers.net> #10
Hello, any progress in here? Please is very frustrating.
ne...@gmail.com <ne...@gmail.com> #11
Hi, open request for more than 3 years for a simple change. Please proceed that.
eo...@enugudisco.com <eo...@enugudisco.com> #12
+1. :(
mh...@shirokumapower.com <mh...@shirokumapower.com> #13
We need this.
ja...@gmail.com <ja...@gmail.com> #14
please add this!
em...@gmail.com <em...@gmail.com> #15
+1 !
va...@google.com <va...@google.com>
ro...@transcom.com <ro...@transcom.com> #17
+1
[Deleted User] <[Deleted User]> #18
We need this please
gs...@klue.com <gs...@klue.com> #19
+1
ga...@synspective.com <ga...@synspective.com> #20
+1
2018 =(
2018 =(
ga...@synspective.com <ga...@synspective.com> #21
+1
su...@google.com <su...@google.com>
ga...@synspective.com <ga...@synspective.com> #22
+1
su...@google.com <su...@google.com> #23
+1
in...@codeweavers.net <in...@codeweavers.net> #25
+1 (again) coming up to 5 years?
eb...@gmail.com <eb...@gmail.com> #26
+1
al...@tdtomdavies.com <al...@tdtomdavies.com> #27
+1
Description
Please provide as much information as possible. At least, this should include a description of your issue and steps to reproduce the problem. If possible please provide a summary of what steps or workarounds you have already tried, and any docs or articles you found (un)helpful.
Problem you have encountered:
When creating a oAtuh Client ID, we are expected to provide valid javascript origins. Recently a validation has to been made on this text field to check if the url is from a valid public domain like .com,.org etc. Any other domain is not accepted and it throws a validation error which blocks from creating the client ID. Note that most enterprise applications (which are valid javascript origins) are hosted internally within their network and their domain is usually ".corp". Hence improve the validation on "Authorised Javascript origin" text field to accept urls ending with ".corp" as valid entry.
What you expected to happen:
URLs ending with ".corp" are allowed as authorized javascript origins.
Steps to reproduce:
1. Go to
2. Select Web application as Application Type
3. Click "Add URI" under "Authorised JavaScript origins"
4. Enter a URL ending in .corp e.g "
5. The "Create" button is not enabled to create the credential.
Other information (workarounds you have tried, documentation consulted, etc): I have checked on stackoverflow for workarounds - they are not acceptable since the validation logic used to check the Top-private-domain has issues. This validation is currently blocking several application in my company from adopting Google workspace as a solution.