Failed to execute 'postMessage' on 'DOMWindow': The target origin provided ('https://docs.google.com') does not match the recipient window's origin ('http://localhost:3000').

[IliaDimchev]

Hi maintainers, I think we have a situation here!

The problem is that after an attempt to Authenticate it is forever showing 403 That's an error, and I know the credentials are fine because I'd created and deployed a fresh React App to test using the very same ones - client_id, apiKey and scope.

More about my setup, I am implementing an App using the Google Calendar API to manage events, for which I'm authenticating with Supabase Library:

package.json

    "@supabase/auth-helpers-react": "^0.3.1",
    "@supabase/supabase-js": "^2.21.0",

The issue seems to be that gapi.auth2 is already initialized by the time I attempt to open the Drive Picker, so it's raising an exception inside the Iframe leaving no trail or any clue to allow for debugging. Researching the subject led me to believe that the following lines inside picker.ts (#40-#47) are causing the bug:

await gapi.client.init({
                            immediate: false,
                            ux_mode: 'redirect',
                            apiKey: API_KEY,
                            clientId: CLIENT_ID,
                            discoveryDocs: DISCOVERY_DOCS,
                            scope: SCOPES.join(' ')
                        });

Because the clientId and scope tags are provided, the request makes an attempt to initialize gapi.auth2 but it already was, so it's going to fail inevitably. In this case, the token has to be retrieved by the session, in supabase that is the session.provider_token

More on the subject: Cannot run gapi.client.init multiple times

I found out that adding:

<script async defer src="https://apis.google.com/js/api.js"></script>

inside the index.html is kind of hacking the situation only that subsequent attempts to call Google Drive API are failing now rather than openPicker, here's a sample of such request:

    async function createFolder(folderName, client_id) {
        function initiate() {
            gapi.client
                .init({
                    discoveryDocs: ['https://www.googleapis.com/discovery/v1/apis/drive/v3/rest'],
                    client_id,
                    scope: 'https://www.googleapis.com/auth/drive.file',
                })
                .then(function () {
                    try {
                        return gapi.client.drive.files.create({
                            resource: {
                                name: folderName,
                                mimeType: 'application/vnd.google-apps.folder',
                                parents: ['15qAPZJwEjbR4nerQyutNelZHcVuWeBHh'],
                            },
                            fields: 'id',
                            supportsAllDrives: true,
                        })
                    } catch (err) {
                        console.log('not created')
                        return console.log(err)
                    }
                })
                .catch((error) => {
                    console.log('not created')
                    console.log(error)
                })
        }

        gapi.load("client", initiate);
    }

The function above works just fine without the script being imported inside the index.html, even more, the Drive Picker works just fine too in the empty React App, so that hack isn't quite cutting it. The best I achieved with it is to get the Picker opening Chrome browser with PC. Mobile never made it past the authentication but it did just fine in the empty React app as well.

Here comes the best part, what I believe is the solution is to handle the situation where the access_token is there already because frankly most of the time it is. Client_id and scope shouldn't be required to resolve that bug, or at least not included in the request unless there is no session, as there will be an access_token with the needed scope(s) issued to the related client_id. So it doesn't make sense to have the access_token as optional when most of the developers can get by just providing it simply by passing it from the session.

[IliaDimchev]

Going further down the rabbit hole, there seems to be a related topic covering the issue with the Migration to Google Identity Service, apparently, Google Picker API remains as is - Read More

Apart from the Authentication, I have 2 applications, both React Apps, and there's quite awkward behaviour, even though the setup is similar. Here is the first one coming - Test Google Drive Picker App with React-google-drive-picker in that one everything works just fine, using clientId and API key alone, together with the library.

Here's the second one - Actual App I'm building for client I have mirrored the setup, testing with exactly the same clientId and API key, yet the result is the opposite from the interaction with the Picker. What happens is both of those apps register under Manage Apps inside the Google Drive Account, even though one is granted access and the other is not. In other words, if I were to click cancel when I'm asked to authenticate the app and provide the scopes, I'd get exactly the same screen, even if I consented, which makes no sense, as that would've worked just fine in the first app.

Can someone explain, please? How is it possible to fail for one app, and succeed for another if the flow is exactly the same and the only difference is the URIs, which are both HTTPS?