Hey all,
I’ve run into a puzzle in one of my projects I’m trying to sort out.
I’m running a retainer model on a project for a client, so the whole system in make.com will be under my own account.
One of the steps is to create an event in a Google calendar. Up until now, I’ve just been using a test account calendar as I tested it.
But the time has come to have it go live and start creating the events in HIS calendar, not the test one.
So my question is: how can I link HIS Google calendar within the scenario that remains in MY account?
I’ve walked him through the steps of creating his Google Client ID and Client Secret, and I’ve entered them under the ‘Advanced’ tab when creating the Google Calendar connection.
But from there, the only option is to ‘Sign in with Google’, which only lists my accounts…
And I’ve tried proceeding by selecting one of my accounts and it doesn’t work.
Still, it’s not like I’m the first dev to have a retainer model, so I’m sure this is a thing that people do… somehow.
If anyone could provide any guidance I’d really appreciate it. Thank you!
1 Like
Hi @Robert_Wynn,
Welcome to the Make community.
The OAuth2 framework is primarily based on safe connections. At any point in time, either the service, the app, or the user must be able to revoke access to the resource. To set up a connection in the first place, several ‘handshakes’ exists. This is something to keep in mind.
In short, you have created the client ID and client Secret, which will identify the app. However, the user itself must give this app access to the resource. Without authorization of the user (i.e. login credentials), your app will not get access. The app does a handshake with Google, asking for access, Google does a handshake with the user, asking for permission and if the user OK’s the access, Google confirms access to your app.
So, it is a must that the users signs in with their credentials. When I work in a customers’ Make account, this is pretty straightforward. However, I also manage some scenarios in my own account. So far, my customers have no problem sharing their credentials with me. They know that if they agree with an integration, some form of access exists anyhow.
Cheers,
@Henk-Operative
2 Likes
Hmm that’s not ideal. We can’t use ‘Oauth 2.0’ module to request Oauth to the user when the scenario is being ran (in case of a webhook) or just provide authorization bearer key to create a connection on an app ?
Thanks a lot for the reply - very informative. Obviously I thought the client ID/secret were enough.
I’ll see if the client is cool with giving me his login credentials.
If you have created a Make Organization for your client, then get them to insert the client id/secret, then perform the sign in.
You can always add your account to your client’s organization as an app developer.
Hope this helps! Let me know if there are any further questions or issues.
— @samliew
P.S.: Investing some effort into the Make Academy will save you lots of time and frustration using Make.
1 Like
Thanks for the clarification. I guess one thing I’m not understanding is why the Client ID/secret are needed at all if the client is going to perform the sign in themselves.
For example, when I link my scenarios to my own Google calendar, I don’t need an ID/secret from Google. I just enter my email address, my password, give it permissions, and that’s it.
When you link your own scenario’s with the default GCal modules, Make is using the ID/Secret that Make has created with Google, which is not visible to you. So in the grant scheme of the connection, there is still an App (albeit Make) with an ID/Secret and a User (You) that grants permission to setup the connection.
Make offers you the possibility to use your own set of ID/Secret credentials, if you want.
Cheers,
Henk
1 Like
