I believe in the MIT Licensing, so everything I build on Bubble is open, and I love helping others who get stuck, so if anyone wants help, feel free to email me: me@nicholasrbarrow.com.
Yes it does! It creates the token in a one-step workflow and then you can authenticate it with an included second step (or authenticate on your own with a custom call).
So I’m the Technology Director for a nonprofit organization that uses GSuite for our user management.
From a functional point, this plugin is only useful for a person/company that (1) has GSuite and (2) needs to pull data from their GSuite in a workflow in Bubble.
To help picture this, here’s how we use this plugin:
Additional workflow actions make decisions based on the groups and org. units that are pulled in (assign administrator status, update custom fields in the user object, etc.).
Hope that makes sense! I’m happy to explain more if it’ll help you out!
Glad you think so! I was hoping to contribute to the community.
I save the token as its own object:
token: String
The plugin automatically generates the token for the maximum time google allows (1 hour). I use the creation date on the token object to determine if it is expired or not.
We use the same token for every user (since it is all just internal for us with minimal security risks). Thus, every time someone sign’s-in to our website, the workflow performs “Do a search for… {access_token object}.” In the search, it filters our requests that have expired. If the count is 0, it generates one; if the count is more than zero, it uses the first item.
Hi @philippe1
That error is usually thrown when there’s an issue with the key that you obtain for your service account. I have instructions for getting a key here: Prerequisites - Bubble Plugins
There are also instructions for what an API call can look like: Creating An JWT Assertion - Bubble Plugins
This all uses the following bubble app example:
Essentially, the no start line error is thrown when the plugin can’t find the -----BEGIN PRIVATE KEY----- lines, so make sure you copy and paste like the example I gave above. Hope this helps!
You’ll need to pass the API token as a result of a step in a workflow, because each key is time-sensitive. You’ll need to initialize your call with bubble, which requires you to send a key. My advice and how I solve this:
Create a dummy page in bubble called ‘test’ or whatever you want
Create a text element on the page.
Create a custom state in the text element called ‘output’ or whatever you want.
New workflow: when page is loaded… => create assertion with your fields => also authorize/get access token
As the third step in this workflow above, set element state => the text element, set ‘output’ variable to the result of step 2
Use this as your access token to initialize your calls.
I found my mistake, it’s scope related.
With a Drive scope and a Drive call it’s perfect!
Thank you again for the plugin and quick hand!
Now I have to understand the limitations / available scopes for Service Accounts, and see how I build with mixing the classic oauth and service account.
The main issue with classic oauth is using scopes that require the (very expensive) certification by Google…
Quick question though: I get an authentication error when i pass the access token as a parameter in the URL. But Bearer Token in header works - any idea why that could be?
Hi there! Not sure to be honest, I’ve had mixed luck passing it as a URL parameter. I believe the key needs to be accessToken, but I’m not entirely sure if it will work. I always use the header.
