How do you fake a role from the client device?
But there literally is. I can modify the database in the backend to show stuff in the front end for non-logged in users.
You canāt view or modify a temp user from the Bubble editor in the User table ā User doesnāt exist yet in the manner that Bubble wants in order to check conditions/expressions that use the Current User. Itās likely they have some kind of temp user value saved, but the technical details of that arenāt published anywhere.
There are a few approaches but details are probably best not publicised for the sake of making sure it isnāt out in the open for any malicious user to findā¦
1 Like
Super.
That is a lot of additional work adding && IsLoggedIn to all my constraints.
I donāt see bubble addressing this any time soon.
2 Likes
Just dropping by to acknowledge this. I shared with the team. They are looking into everything said here.
Thanks everyone.
7 Likes
Out of interest, do your page redirects not already protect against this case?
for many of them yes, but i do have a large portion of my pages that are public supporting both loggedin and anonymous users.
As the original creator of this post I can share a video recording of my initial setup later on if it helps.
1 Like
Send me a PM then. Would be good to know so as to perform robust testing, and donāt be afraid to put it out publicly, youāll only actually help the community if you do so more users can test robustly against what they would come to learn as a potential security concern that any malicious user likely already knows to attempt.
Not sure but I think itās already posted on the forum, Iād be curious to compare the approach you use against whatās already outlined on the forum to see if they are any different.
@georgecollier would these google search results be outlining the steps to take in order to āfake a roleā from client device so that we can do some security tests?
Iām not sure if this link from Google is giving the step by step instructions on how to do what has been discussed on the thread as āfake a roleā but google describes as override web content and http response headers locally.
2 Likes
Sorry for taking a tangent here, but if this is the case, then using āCurrent Userā should not be costing extra WUs as is highlighted in this post, right?
Using the SQL Connector will invariably accrue some WU cost, the Current User is only āfreeā to the extend that itās downloaded on the client upon login. Your use case is separate.
1 Like
I think SQL connector mentioned in that post is just incidental. As you can see from other replies in that thread and even from original poster itself in this sentence Bubble seems to be charging for every time we use Current User's field at any place unless we store current user in a custom state etc and then use. 
Hey @fede.bubble, any update from the team? Itās been almost a week now.
Bumping this @fede.bubble - also interested if there has been any headway or acknowledgement by the engineering team at bubble if they can improve possible vulnerabilities here, as using group variables is kinda essential these days in bubble. Thanks
btw.
According to another post on this forum, locking down the page by redirect doesnāt protect the unprotected workflows as the application is still loaded.
I know, I made that post 
This part was incorrect (which is the topic of my other post about server-side redirects)
1 Like
We still need these answersā¦
These must necessarily be server-side as they run in the backend (there is no client).
These should also be evaluated server side and any server side actions in the workflow will not run if the condition is not met.
2 Likes
What? These arenāt conditions, these are states of users.
You can use backend workflows to modify non-logged in users. Did you forget what this thread was about?
They are conditions.
Is Current user logged in? = Is the person making this request is authenticated with Bubble as a user?, which would be checked by Bubble.