Session variables

Is there a preferred way to store a session variable? If so, how are they controlled?

Cookies, maybe?

I think this covers your question

Hmmmmm. Could this be done with javascript? What data is saved for non logged-in users?

No that won’t be accessible from code. If you want to go that low level maybe an HTML element with some script tags could do it?

1 Like

Are there limitations on what we can use as far as Javascript is concerned?

Bubble is (not) yet designed with the idea that people will type code (when we’ll push plugins that’ll change a bit). So at this stage the best is to experiment :slight_smile:

But again, using Bubble actions will get you pretty far (including saving on non signed up users, but we delete these users after 3 days).

Great. I just didn’t want to try and bug-check for something that wasn’t enabled/possible.

What is “saving on non signed up users”?

Is “saving” the same thing as auto binding to bubble-only fields that get washed?

If so,

Is the data app specific or bubble-account specific?

Is it the same washing time every three days, or is it revolving per user or visit?

How would someone access that washed data? It would be a great start for cookies or affiliate timeouts.

Hey @scottb50 , I just implemented Browser canvas fingerprinting in bubble today using the native JS bridge method ( Native JS Bridge - two way bridge for Javascript addons in Bubble ).

With this we could identify non-logged in users, and it gave us the possibility of not letting a user watch more than X minutes of video before he has to register. Even if he would try incognito mode it would recognize his browser.

You could use the same method just using: https://github.com/js-cookie/js-cookie or https://github.com/localForage/localForage to store cookie data.

If you start storing lots of data based on cookie ID`s, make sure you make a workflow for cleaning out after X days.

Let me know how it goes :slight_smile:

1 Like

Thank You so much! I can’t wait to try this.

Hello,

As soon as a Bubble web app is opened, a user is created in the database, and it’s using the cookie to represent him/her, until he signs up. So if you modify the current user that isn’t logged in, it’ll modify that object in the db (the 3 days are revolving)

2 Likes

So smart. That clears it all up.

:slight_smile:

Besides an ID, what is/can be stored in that cookie? Is there a naming convention that could be considered when creating a condition?

You shouldn’t think of it as a cookie (it’s too technical for bubble). Think of it as a user and you can store anything that can be stored in a field.

I would find variables useful - my use case is this…

I have pages where sometimes I want to open them on a particular record and so send data to them and other times I want them to open with the first record. I have this working with workflows dealing with the selection based upon whether the pages’ record is empty or not. Unfortunately this leaves me with some errors (and the app doesn’t seem to work in Live mode - although this may not be the reason).

Global variables in an app would be very useful to deal with passing data around a solution. We, as Bubble users, don’t need to know how they are stored (presumably session variables) - we just need a simps way of creating, setting and referring to them. I am coming from Access Web Apps where this feature is available and very useful.

have you tried using URL parameters ? The only way to send data to another page without going through the ddb

I haven’t tried that yet - it seems a bit messy somehow. However, I think it’s probably got to be next on the list and thanks for the suggestion!

(Unless there is a better way!!)

You’re right. More the last solution to try. You have to play with the action “Go to page…” to update the URL parameters. A pain if you deal with more than two.

I decided to take a different approach to the problem - i am recording the value against the Current User (a field for Current Company and Another for Current Contact so far). This is actually a benefit because it means that when the user returns to a screen it can sync back to the last record they viewed (haven’t implemented that bit yet but am thinking about it). Any way this works well with a workflow moving to the record requested if the field has contents and staying on the first record if it’s empty. Works well as far as I can see.

@gurun. That bridge looks great. I’m still digesting it. Delicious!

@julian1, are all your users logged in to your bubble app when you’re tracking them?