My App scenario:
I need to connect with multiple social networks like FB, Pinterest etc. & store tokens of respective platforms so that I can pull data & have some processing on it in another backend app(in python, Django).
I tried to log in with various
1)Social plugins available & also with
I am able to log in & connect with them(using both the methods above) but I have to store & need the token which I am not able to find anywhere in DB or can’t find any flow that can help me out to store those credentials.
Also have gone through the Lessons, documentation & forum questions but haven’t got anything satisfactory answer. Anyone having any idea please initiate the discussion & let me know your approach to this.
Storing a user’s access token in the database is generally a bad idea for security reasons, for example, anyone looking at your database can potentially post to someone else’s social media.
Passing on a token to another backend is also an unusual approach, normally another backend would either be fed with the data from your app, or have its own authentication path.
If you want to do it, you’d need to do manually do the OAuth2 steps instead of using the auth method built in, its tricky to get this right in Bubble. I’d guess there wouldn’t be much community help for this.
Thanks for sharing your thoughts .I am currently trying manual oauth2 steps but it’s not allowing me to do API calls on some action to get token !
Unfortunately, I have done this often. Two reasons… Off-line access and multiple accounts per user.
I’ve never cracked how to perform external calls using the vanilla oauth user agent flow, when the user is not present. Would love to hear how.
And then there is the use case of several accounts for one user. As soon as you try this, a new bubble user is created. Again, would love to hear I’m wrong!
Without these, I’m forced into doing the oauth dance step by step and storing in the database. This exposes the keys in the client, which is undesirable.
@Vikrant.g if you really want to do this, knowing the risk, post the details of your api connector calls for the community to comment and help. It’s also a good idea to get it working in postman first and then move it over.
Yeah, but kinda…no too :)
The token, without the secret is worthless.
The secret, without the token … is also worthless.
What is a bad idea is storing your token in the database, that has your API keys right there in the open for everyone to see.
Protected by the SAME password.
Hence many PaaS vendors offer an extra layer of security (AWS has secrets manager for example). Bubble takes away the token side for us, we never see them in “native” oauth.
Obviously it depends on the token, a short lived revokable token is not too bad, but an irrevocable refresh token … different game.
Anyway, a way to seperate your concerns is to move the actual API access off to another microservice, that way Bubble only has the token stored. And the microservice only knows the keys.
An alternative is to use a third party access management tool to manage it all (and not a bad idea anyway, if you ever want to shift your app).
Multiple social accounts with offline access is entirely possible, it is just pretty hard to do. The Bubble side is not that hard, it is managing a raft of different platforms who all do things just a little differently that is tricky. Hence looking at a unified solution might help.
First, you can configure privacy for all thing’s fields which means the system will hide their values.
Also, you are able to get user’s authentication object via API workflow. You can see Facebook’s authentication object for my user in the following example:
So, for instance, you can use “OAuth2 User-Agent Flow” authentication type and then be able to get its access token. By the way, do not forget to use “access_type=offline”. This action refreshes your token automatically in case if the third part uses the same standard.
Could you please add few detailed steps like starting of workflow with screenshots?
This topic was automatically closed after 70 days. New replies are no longer allowed.