I maintain a web application that lets users within our org to transfer their personal accounts to the official
Google Workspace organization. I use the following API [1] to programmatically send Transfer Requests from the app. Today
one of my users asked me for help to resolve an issue they experienced while trying to approve the transfer request they
received from Google. The actual problem happened when approving the request - user would see a browser error informing them
about a redirection loop.
After some time I realized that there were two unmanaged accounts linked to the user's email address (mail addresses are made up to
preserve anonymity):
- test.account@cern.ch (I think this doesn't correspond to an actual user)
- and Test.Account@cern.ch
These are identical email addresses (except for casing). It turned out that user sent a Transfer Request (using the app I maintain)
for test.account@cern.ch even though their actual username is Test.Account@cern.ch. Only once I sent a Transfer
Request for Test.Account@cern.ch did user manage to transfer their account. I would like to know if that is the expected
behaviour? Should casing matter when using the following endpoint [2].
What is even funnier is the following:
```
# https://cloud.google.com/identity/docs/reference/rest/v1/customers.userinvitations/isInvitableUser
isInvitableUser('Test.Account@cern.ch') == True
isInvitableUser('test.account@cern.ch') == True
```
But
```
# https://cloud.google.com/identity/docs/reference/rest/v1/customers.userinvitations/send
send('Test.Account@cern.ch') # will contain a valid invitation link
send('test.account@cern.ch') # will result in an email with link leading to browser redirect loop
```
[1] https://cloud.google.com/identity/docs/reference/rest/v1/customers.userinvitations
[2] https://cloud.google.com/identity/docs/reference/rest/v1/customers.userinvitations/send
LinkedIn
Twitter
