Yes, privacy rules are set up correctly and this is all at the user level thankfully. I will ask support but appreciate the comment and thoughts. Thanks
1 Like
Donāt forget to clear any test data used in API connector that are not private. Anyone else could see theses values (but not if they are set to private). From what I remember, Flusk should give a warning about that too.
Did you mark the token as private but need it to not be private because you are passing it in the workflow?
Yes, i thought best security practice was to set any token in an api call to private based on what the flusk folks had been telling me since last year. The actual token is being passed via a current user value and those privacy rules are in place. The token is passed in the workflow as above.
But you canāt pass a dynamic token if it is marked as private. Is the token dynamic or static, just one token that doesnāt change?
1 Like
Doesnāt look like a token is being passed in the workflow. It looks like the condition didnāt work. It looks like your search for premier profiles is coming up empty? Is that what you are seeing as the issue?
1 Like
No, the token was not being passed when the api connector was set to private, unchecking that solves it.
3 Likes
Cool. Glad that helped. 
Just make sure to not have the api token still in the API connector. Only pass it in the workflow.
1 Like
You should at least mark at the post by @Jici as a solution instead of marking your own post.
4 Likes
Same issue, I had workflows working fine with token in private. Now they are broken, and if I uncheck private it works.
So Bubble did change something !
1 Like
I donāt think. If this was working, this is because you set a token in API connector that was working until now. In fact, if this was working before, this was an issue! You cannot pass dynamic data into a private parametersā¦
Sorry to say guys - We have the same issue here. All our workflows broke on 12/10 - We had spent hours troubleshooting and wasnāt informed at all.
Bubble did change something, at least how API Connectorās private value is handled with dynamic content. Ours worked with no problems for 2 years ( and we also manage to do this recently from time to time ) - and it just broke 2 days ago.
Although that was what we thought bubble intend for us to be able to do, since it was working fine , the idea is being able to set dynamic content and be able to āprivateā the value ( which was pretty useful tbh ) while Flusk also recommends keeping our URL endpoints private.
2 Likes
@fede.bubble can you investigate on that?
You should all submit bug reports at Contact | Bubble
1 Like
Iām a bit confused - you canāt have private content with dynamic values. Do you mean that when you made the API calls, you added the dynamic content in the action, and then made it private?
Maybe it was a bug that was actually fixed? You canāt have a dynamic field also be private. Once you mark it as private, it should no longer be visible in the workflow. Maybe a glitch allowed it to work before but was actually a security flaw. 
Yeah, it reads to me as follows:
- These users set up an API call with dynamic data
- They later made that parameter private
- Because of how Bubbleās app JSON logic works, the non-private data the user provided in a dynamic expression would be invisible in the editor but still technically being passed to the API call (thereās lots of places in the editor stuff like this can happen).
- The expected behaviour then shouldāve been that the private value gets passed, not the dynamic value.
-
- mustāve been patched recently which is causing these users to experience issues
2 Likes
And all of this, because the warning that users get in Fluskā¦. Flusk need to explain more about when and how to use private key (or not)
2 Likes
The change clearly affected more than one user now, I notified support and they said they made no changes but I find that hard to believe. The fix is setting the token to not private and clearing the parameter value in the API connector but this needs to be done across multiple API calls depending on your setup so it can be a pain.
2 Likes
Update from Bubble Support: Our team investigated this further, and was able to determine that a recent change to API Connector functionality was unintentionally deployed that caused the behavior you reported. Prior to this deployment, if an API callās parameter was marked as not Private, and a dynamic expression was used to set the value of this parameter in a workflow action, the API call would continue to reference this dynamic expression even after marking the parameter as Private ā despite the dynamic expression becoming hidden in the editor.
While the change to eliminate this behavior aligns with our teamās intent moving forward, we understand that this change was disruptive in certain cases which relied on this behavior, such as yours. Our team has since reverted this change, and plans on rolling out this change in a less disruptive manner in the future to avoid breaking any existing functionality. In the meantime, you can safely resume using any API calls that relied on the prior behavior.
We greatly appreciate your understanding here, and for submitting this bug report to the team. Please let me know if you have any further questions at this point and Iāll gladly assist however possible!
My Thoughts: Great that they investigated and acknowledged. Not great that they continue to push things to production without an adequate understanding of how this works across their existing systems. The past couple of months have seen some nasty side effects of pushes and this doesnāt give me a ton of confidence that they have cleaned up their internal processes around that side of things.
2 Likes