Referring to the admin SDK APIs, I don't see anything that would allow me to list the subdomains defined for the google apps domain (via the CPanel in Domain Settings->Domain Names).
Is there any way to collect this information directly? Even the older provisioning API doesn't support any listing of subdomains and/or domain aliases.
There are no domain-specific API calls that allow you to list out secondary domains and domain aliases. However, you can try listing all users (with aliases) and groups (with aliases) in order to see which domains are in use. Technically, this may not be all domains (some may not have any users/groups associated with them yet). But for practical purposes it should serve.
Obviously the performance would be much better if you could perform a single API call and get all domains but there's currently no method for that. This is the only workaround I'm aware of.
Related
We are web developers building a deployment preview service with Google Cloud Run. Not a lot of experience with this... ;-)
We have mapped a custom domain to the service and the problem is that when the developers are pushing revisions, GCP returns the revision URLs assigned by GCP, not revision URLs using the custom domain.
This is problematic for us because of the cross-origin, and the way we whitelist apps that can call our APIs, etc.
So my questions is: Is there a to have revisions URLs be subdomains of our custom domain or something like that?
Would like...
https://branch-name---service-name-123456.a.run.app
if possible to become something like...
https://branch-name---service-name-preview.customdomain.com
We've recently introduced Google Single Sign-on to our platform. It works well, except for one issue. All our development branches are automatically assigned a url that looks something like https://{branch-name}.ourdomain.com. As of right now, we have to manually add the authorized origin for each environment, which is not scalable for us.
Is there a solution, such as an API we can use in our deployment process, that doesn't require us to authorize from the same origin for all our branches and doing a redirect dance? The ideal solution would be the wildcard solution where we could add https://*.ourdomain.com as an authorized origin, but that doesn't seem to be allowed in the Google Cloud Platform.
There is no API for adding authorized origin dynamically in the Google console; it must be done manually. The OAuth engineering team is still evaluating the best way an API could be deployed as this carries many security risks that need to be properly assessed. JavaScript origins cannot contain certain characters including: Wildcard characters ('*') to ensure the security and privacy of accounts. You need to add the exact URIs the application is gonna use as JavaScript origins. Unfortunately, there is no good alternative workaround in regards to your use case, the only workaround is that you need to add each environment manually.
Note : There are several feature requests like Can't update Google Cloud Javascript Origin domains via API for this, but unlikely that will be implemented soon.
Refer Google API: Authorized JavaScript Origins for information.
Alternatively, you can redirect the user to the base domain which is registered in the google cloud console, and redirect back to the original site with the token post-authentication.
Please take a look at this article. https://www.kcoleman.me/2016/12/28/wildcard-google-auth-for-multiple-subdomains.html
I want to give my customers an option to put their website (HTML, CSS, PHP (optional) ) in a custom domain.
By default, customers will get a basic subdomain like: their-site.mydomain.com
If they upgraded to Pro, I wanted to give an option to use custom domain by adding A record or CNAME.
After some google research, I found that lot of companies are using Amazon AWS for this task. However after checking different article, I did not get any idea how this would work with amazon or any other server.
All stuff needs to be done from the my Application UI by customers. There should be atleast 100s or 1000s of domains. I wanted to redirect each of them to their own website.
Any Idea how this will work? Please add all details if possible.
I'm developing a SPA with html5 routes.
Ex: https://app.example.com/restaurants/<restaurantId>/menu etc
Basically the app creates dynamic websites for multiple restaurants, hosted at https://app.example.com/restaurants/<restaurantId>
The requirement is to allow the restaurant owners to host the site in their own domain name.
Ex: if the restaurantId of Example Pizza Shop is xxx
then www.examplepizza.com should serve the contents of https://app.example.com/restaurants/xxx along with all the sub-routes.
The project is hosted on firebase, I'm looking for ideas on how to achieve this (even if I have to use services outside firebase it's okay)
Thanks in advance.
Firebase Hosting is not well-suited to these kinds of multi-tenant use cases, and you'll find the same is true for most "platform-as-a-service" style hosting providers.
To host arbitrary custom domains, you'll need:
Dedicated IP addresses that customers can point their DNS providers to (A records).
A web server capable of dynamically changing what it serves based on the Host header of the incoming request.
An automated SSL certificate provisioning system to create certificates for each customer's custom domain.
This is generally a major undertaking and requires quite a bit of both general and specialized knowledge. I don't think Stack Overflow is going to be the right place to find a specific solution, but I hope this guides you on your journey.
If I want a multi-tenant environment where customers can create subdomains, what are the pros and cons of creating those subdomains under myexample.com if my main company domain is example.com?
I noticed that Shopify uses myshopify.com under which their create subdomains for their customers.
Coupled with the fact that this is better for security,, it certainly appears that there's a pattern and good reason why companies do this.
Here are some examples:
Shopify
Uses shopify.com for marketing and myshopify.com for subdomain.
Basecamp
Uses basecamphq.com for marketing and basecamp.com for subdomains.
Intercom Articles
Uses intercom.com for marketing and intercom.help for subdomains.
Harvest
Uses getharvest.com for marketing and harvestapp.com for subdomains.
Status.io
Uses statuspage.io for marketing and statuspagestaging.com for subdomains.
Also this article points out the issue with untrusted content (as is the case with Shopify:
Although cookie domains do help to limit the scope of your cookies, it
is still best to avoid having untrusted hosts under your domain. This
is why GitHub pages are hosted under github.io, not github.com, for
example.
I suspect the web domain name prefixed by 'my' is purly emotional rather than technical. It's in the back-end that the domains need to be different, as a resource for enforcing security. There needs to be at least a production and an internal domain. A full suite might be Dev, DevQA, UAT, production and internal domains, with a limited number of people being able to transfer code and/or data across domains.