Premise: User reserved pages such as dashboards, profile settings etc. are only accessible to the “Logged In User” upon Log In (duh), and personal information such as “Logged in user > Full Name” or even “Logged in User > Stripe Account ID” etc. are dynamically rendered to reflect said user’s data.
If you copied, or one of these pages URL was saved in your browser’s history, you will be able to visit said page, even when no user is logged in.
Let me clarify that I have NOT encountered an instance where the information was accessible (though I did see some data flashing randomly from previous sessions…that might be the browser “remembering”, also input fields don’t always get reset…again, could be a browser thing) but you will effectively be able to go “inside” the app, even without being logged in. Probably won’t be able to do much (maybe), other than navigate the app internally, and your DB’s real data won’t be read or written (maybe).
I’ve had these same questions. I’m not sure how much of the data gets handled by the backend and how much happens in the front end. Your experience sort of confirms that the frontend has full access to the database which kind of confirms my curiosity here. Post
I wish they would clarify how some of this works because I really enjoy how intuitive Adalo is.
Hi,
I encountered the same but didn’t not test a new solution. What I thought was to add a new condition “User Logged in” = 1 that is set to 1 when user logins, when user logouts it is set to 0, this to ensure security using fields visibility. But still if it is a browser issue, I do not know if issue will continue. I will try to test today this behavior.
• These are two different users logged in at the same time, in 2 separate incognito windows, looking at their profile page.
• As you can see they have the same URL (assuming it’s the equivalent of “www.yoursite.com/profile” etc.?), so it would appear that there is no user-specific data in the URL i.e. “www.yoursite.com/profile/mickeymouse” - maybe that’s why we don’t have deep linking just yet?
POSSIBLE MAJOR ISSUE
• Pasted that link in Safari, Chrome, Brave and Firefox. I couldn’t always reproduce this, but though logged out, and visiting that URL for the very first time, I got “inside” the user’s profile, which would seem strange given there’s no indication of “uniqueness” in the URL…and could see all sorts of sensitive data.
• Most times I’d simply get inside that specific page (/profile or whatever) but see the empty state I designer with no data at all.
Hi,
I agree on with the deeplinking, I assume data is then generated according to the user logged via QUERY in, but URL is always the same.
For the one not related to URL
What I see related and potentially same issue is when I load a list from an external collection, by a millisecond seems to load all data and then only query regarding the parameters. So it seems to have a query running to load the external data and then it “pulls” our query in the list to filter data.
@damianoredemagni you’re right - in the webapps it is easy to get “inside” the app just by copying URL. There is no automated “user rights check”, unfortunately.
As I understand, Adalo was built primarily for app creation. In this case, copying URL is not possible, and if one creates the screen flow correctly - admin and user parts of the app could be separated.
For the web-based apps, the only way I found to protect them from unauthorized access is to do it manually:
set a check for “logged-in user” when entering each screen, like @sebastas suggested. I do it by checking via “email is not empty”
set a check for “admin user = true” when entering each screen
in addition, hide sensitive content using visibility rules (this protects in some cases, when screen-enter actions are not executed when entering the screen via “back” button).
that’s odd too! i only had the previous session’s data (logged in as Mary) show in my current session (logged in as John) for a flash, but again, we’re not sure if it’s cached in the browser (if even possible) etc.
To add to the solutions posed here what I also tend to do is set up different user groups as true / false boolean properties in the user collection. (Such as “Free”, “Paid” etc)… that way I can filter secure pages by adding a check on that property.
