Temporary Access for Non-Logged-In Users: Security Implications?

Questions
1

Hey everyone,

I’m considering allowing non-logged-in users limited access to certain data currently restricted by privacy settings. Here’s a quick outline:

  1. On page load, an API call is triggered.
  2. A random string from the URL (secure key), combined with the non-logged-in user’s ID and page item’s ID (this item has a hash for that matches the secure key), are sent to the back-end.
  3. If the key from the URL matches the page item’s hash in the database, the non-logged-in user’s parameters are updated (e.g. access = level 1).
  4. This update parameter ‘access’ then is then used in privacy settings (This User’s: Access IS level 1), granting the user temporary access to the data.

Essentially, I want to non-logged in users parameters in the background based on a secure key without requiring users to log in. My main concern is that this API call will just create additional privacy loophole. Does this sound secure to you? Any insights or potential pitfalls?

I am happy to elaborate. Thanx!

2

It feels a little overcomplicated - if I needed to do this, I might:

  1. Have data type ‘Access Token’ with a text field (token) and an option set list which contains the data that should be provided just so we know which data to return, expiry date, number of times used etc
  2. Get access token from URL
  3. Make API call to backend workflow
  4. Backend workflow checks access token exists in database. If yes, return the desired data from API so it can be used in the front-end. If no, just return nothing.

This is how I’d approach stuff like finding a user’s order given only their email if they don’t have a login. Of course, your use case may differ so the above might not be appropriate.

You mean Current User :slight_smile:

You’ll of course need to consider access expiry management. Also, remember that privacy rules are evaluated when the data is first loaded onto the page, so depending on how you implement this it might require a page refresh.

3

If planning to using a url parameter, why not a magic link that handles all of this?

4

Hi @code-escapee & @georgecollier, thank you for delving into the topic.

@georgecollier, I can absolutely see how your approach would be appropriate for granting access to a specific data type. However, in my use case, I need to provide temporary access to multiple data types. Let me illustrate with an example.

Imagine a non-logged-in user is granted access to a shared dashboard. I want them to be able to see all the necessary (and very limited) data, which includes multiple data types. This is the reason I am considering updating the Current User’s parameters, so that the user aligns with the conditions set in the privacy settings. This way, they can access the restricted data more freely, and there is no need to check Token per each datatype. As you pointed out, I definitely need to think about expiry management :slight_smile:

@code-escapee, thank you for the suggestions. In my situation, a) non-logged-in users don’t have a user account (I’m not 100% sure if this is required for a magic link), and b) my token needs to remain valid for more than 24 hours, which seems to be the maximum duration for a magic link. Your comment hits the mark; I’d really prefer to use a magic link since relying on custom processes for authentication appears error-prone.

If anyone knows of insightful articles or sources discussing the authentication of non-logged-in users, I’d be eager to check them out! Thanks!

5

How do you have a user ID without a user? How can you identify who the visitor is? Assuming you have email address so Crete a user

Reg 24h expiration you can set user to remain logged in so unless he switches devices or doesn’t click the link initially before it expires he’s good.

And of course if it expires just regenerate a new magic link.

6

Hi @code-escapee.

I am using unique id created for temporary user - you can it out from here: User accounts - Bubble Docs

“Bubble sets up temporary users whenever non-logged in users visit your site. Data stored on that user is automatically transferred when the user completes their sign-up (this is useful to store a a new users shopping cart for example)”

This is pretty new thing for me as well. I am considering temporary user more like a “session” and so updating users parameters so that privacy rule grant access, is more like giving session access to certain data. Hope this clears things up a bit :smiley: