@bd808 should we ask for a VPS project to have a subdomain we can verify ourselves or is there a way to verify tools.wmflabs.org itself?
I would think of having a simple proxy to Toolforge with nginx if a project is indeed necessary.

Making the TXT record for tools.wmflabs.org is something that the WMCS admins can do technically.

My main open question about this is how Google treats this association on their side. It is not clear to me if they allow a one to many mapping for domains to OAuth grants/owners. This tool is the first to ask about integrating with Google OAuth, but it would be a bit sad if things work such that only one tool can take advantage of this before we figure out how to implement T125589: Allow each tool to have its own subdomain for browser sandbox/cookie isolation.

Sounds like this task is blocked on the road by https://phabricator.wikimedia.org/T215531 ? Atleast that is what I hear from #wikimedia-cloud. :-(

In T226052#5446738, @01tonythomas wrote:

Sounds like this task is blocked on the road by https://phabricator.wikimedia.org/T215531 ? Atleast that is what I hear from #wikimedia-cloud. :-(

What I actually said:

In T226052#5297316, @bd808 wrote:

Making the TXT record for tools.wmflabs.org is something that the WMCS admins can do technically.

My main open question about this is how Google treats this association on their side. It is not clear to me if they allow a one to many mapping for domains to OAuth grants/owners. This tool is the first to ask about integrating with Google OAuth, but it would be a bit sad if things work such that only one tool can take advantage of this before we figure out how to implement T125589: Allow each tool to have its own subdomain for browser sandbox/cookie isolation.

Unfortunately I have not been able to make the time to talk to Google about this. @01tonythomas if you have the time to do that research with them and report back it would be greatly appreciated.

@bd808 someone on #wikimedia-cloud told me that our task is blocked by T215531

arturo> tonythomas: I can give you some more concrete information if you are interested
16:27 <tonythomas> arturo: please yes! 
16:29 <arturo> tonythomas: first, I would point you towards this: https://wikitech.wikimedia.org/wiki/Wikimedia_Cloud_Services_team/EnhancementProposals/DNS_domain_usage#Resolution i.e, we plan to use `$tool.toolforge.org`. For implementing that, upgrading our kubernetes deployment is probably the first step, and we are working on that in this phabricator task: T215531
16:29 <•stashbot> T215531: Deploy upgraded Kubernetes to toolsbeta - https://phabricator.wikimedia.org/T215531
16:37 <tonythomas> arturo: thank you. I will keep an eye on those tasks! Thanks.

I will start a conversation with the Google team then. Lets see where it takes us.

I took a closer look at this today, and I see that we are currently able to serve our app on https://gdrive-to-commons.toolforge.org/google-drive-photos-to-commons/. This is great. However, I see a problem while completing the Google OAuth verification screen:

As soon as I add our domain https://gdrive-to-commons.toolforge.org/, it translates to toolforge.org and asks me to verify that domain:

Its funny they were happy with the subdomain tools.wmflabs.org from past though. Probably in our case, this is due to some DNS records pointing the subdomain to toolforge.org, I guess ?

+ TODO: Update Wikitech OAuth application to support our new subdomain. Right now, it redirects to the old app.

Okey, So I resubmitted after getting our new domain verified and stuff. Just received this one:

the good news about it is that its not complaining anymore about Domain Verification. Even though, its a bit strange that Google is not happy with our current homepage at https://google-drive-photos-to-commons.toolforge.org/

I have asked them why, and hope to hear something soon.