Anyone else seeing issues? I filed a bug report but any third party app i have been fetching JWT tokens successfully for years have now stopped being passed appropriately in the workflows to the next step, so I am seeing a rash of access denies or user expired etc… in my app. WTF did Bubble do? This looks to have started on October 9, seeing it globally, none of my previously working token passing workflows are working as expected….these tokens are set to private in the api connector and api calls have not been changed (they work manually).
Maybe it’s related?
It shouldn’t affect any existing WF…
Do you have more info from logs?
Sending support a ton of screenshots and theyre giving me BS about it being a 3rd party issue. Definitely not. They screwed something up with tokens that have been set to PRIVATE in the api connector IMO and now those tokens are not being passed properly. As far as logs go, the tokens are all fetched without issue they just are showing blank when the step that needs them has no token to pass…its like its using a default setting in the api connector instead of the actual token that was fetched. This is persisting across multiple API’s we have that work fine with the manual connector (cutting and pasting the fetched token to the call) but NOT in the workflow itself. It would be insane if there “new security” thing is required us now to set tokens to not private in api connector, to my knowledge that has never been a practice that is recommended.
1 Like
Maybe you can share more about your settings? There’s no report from my users about similar issue.
Did you do any Bubbe update (from settings) or change privacy rules…?
Literally nothing changed on our side. No bubble update or change to these api’s in months. We were flusk users before this was bought by Bubble. The workflow is fetch token-use token (pretty normal IMO). The use token step is showing blank or using a cached token from the api call setup, if i remove that token in the api connector it just shows blank
1 Like
You should always remove any test value from API connector.
Now, I will probably agree that the issue may be from something in the third party provider that could have change. It’s a little bit hard to know without checking each step and your settings. But I do agree with Support at this moment. However, this could also be a Bubble issue starting with update they made… Try to add some debug stuff to help you to validate that it’s not third party that have issue so you can help Bubble support to validate it’s on Bubble side…
1 Like
Maybe I’m not being clear, even with default value removed its passing blank, the token is saved at the user level and is attempted to be passed to be used in the following call, yet it remains blank. The third party expects the token, but bubble isnt passing it.
That’s not a thing
Share screenshots of your workflow action that fetches the token, the one that sends it, and the API Connector call involved and people here will be able to help.
1 Like
So I guess you are also fetching it from user DB…so privacy rules apply? You are running this in backend wf… again… share screenshots…
Nothing changed with privacy rules. This has been in place for months without issue. the token is being passed using result of (previous step). We save it in another step (which works).
We’re trying to help you, but if you won’t share screenshots of your setup it’s a bit difficult so… are you hear to rant or to fix it? Best of luck, I guess…
1 Like
Screenshots with private tokens don’t seem like a good idea. I have described the workflow, support has recognized the issue. No one is ranting.
You can redact them in the image…
Here ya go. API call in the connector that uses the fetched token, the workflow on the page after the button is clicked (i chose a non-backend one for ease) and finally heres the inspector view of it running. I can confirm the token is successfully fetched and saved without issue in the DB. In terms of privacy, this is a current user running the workflow and the current user has all permissions. The error received says access unauthorized, and in the logs i dont see the token passed. If i set the api connector call (parameter for the token to “not private”) then i can track this and it will work but that gives me concern for obvious reasons. Info redacted where appropriate.
Private API connector values don’t show in the logs by design. What’s this? I thought you were fetching the token from the Current User? You’ll need to provide some detail about which token is the one you’re trying to provide dynamically etc because when you cover up everything there’s no way to know if there’s a static value, dynamic data source or something else underneath.
1 Like
You have also an error on content-type that should be application/json
Are you calling your own app?
subcode is not an access token, its a private code we use related to the api were calling so i blurred it out. The access token is being fetched from the current user, but yes but by design i cannot see it in the inspector or logs. It is the current users token though. Here is a screenshot from dev environment without the private for the token checked so you can see. When the private setting is unchecked at the api call level, this works.
Hum… you need to set uncheck private checkbox! This has not changed. This is what you need to do! Don’t be scared, the call is made from server. However, you need to make sure privacy rules allow access only to the user that own this key.
If this was working before, it’s just because the call was using the token set in API connector and now this token is probable expired or revoked.
Not a Bubble issue but expected behavior that you probably didn’t use correctly.
2 Likes
Really? Flusk was giving me a ton of crap about that when they would audit my app, they suggested they could see the token. They recommended tokens be set to private. If thats not a thing I can certainly do that.
1 Like
Flusk is there to help checking any security thing that COULD be an issue. Nothing more.
If you can (for example, you are using only your own API key) you should set this to private. But when you can’t like your case, you need to use the correct privacy rules but leave the private box unchecked
1 Like