In my app sends invitations to users that should log them in and offer them a gift. I’m using magic links for these to make the process as smooth as possible for the recipients, but in my use case it’s likely that the user might wait a day or two to visit the link.
Is there any way to get around the 24 hour expiration limitation in bubble? I considered trying to roll this myself using unique ids of the invitation records as the key to get in, but I couldn’t figure out how to make that work without needing to look up a user as an anonymous user, and that seems like a privacy/security issue.
I also searched around for some plugins but didn’t see anything relevant.
Thoughts?
You cant extend the expiration time, cant you do it from the backend workflow?
Do what from a backend workflow?
I mean you cant e tend Token experiration time, but what you can do create a Token by your self, save it into user entity.
Send a link to user which open a page and confirm this code by looking to user.
This is lenghty process but you have the Luxury of control
This was my original plan, to let the gift invitations UUIDs function as the token. The problem is that there isn’t a good way to log the user in without exposing passwords to anonymous users.
Example:
User clicks on link and arrives at app, logged out
App uses the token to look up user
Run “log the user in” workflow, but this workflow requires password, which means password must be searched by anonymous users to make the whole thing work.
I suppose I could set it up like this:
Write an API endpoint to take a token and return the password
User arrives with token
Use bubble api connector to pass the token to my own endpoint and retrieve the password
Log the user in
Seems a bit roundabout but at least I can be sure I’m not exposing extra data to the user. Is this what you had in mind?
you can assign a temp password, and log the user in, the actual password remain untoch.
just search the user with which have the tokens, and the assign him a temp password, and then log him in. the user password get untouched. he can then login out with his own password.
if you are still confused, i can spare some minutes to discus your situation in a short call.
Thanks for the offer.
I eventually got this working but with a slightly different setup than you suggested. An added wrinkle is that we also support regular password login, so wiping out users passwords and replacing with temporary ones in this flow is not an option.
I settled on a backend wf api endpoint that validates the token and cross validates with a hash. If the validation passes, the backend api returns a magic link for the authorized user. On arrival to the router page, I call the workflow api endpoint from the api connector, and if a valid link is returned do an immediate redirect.
End result: functional custom magic login without exposing unnecessary data to the front end.
One slightly surprising thing: if you create a bubble workflow api endpoint that you intend to call with the api connector from inside your own app, this will still require the API endpoint to be exposed externally, as every call through the api connector looks external, even if it is your own app. Anyone else who wants to do this kind of thing: don’t forget to create the api key and require authorization on your endpoint.
@Steve_W You can achieve this without modifying or assigning any temp password or exposing any data.
Just create an empty page with a database type linked to that page. This datatype will contain 3 fields: User (User), Used link (yes/no) default it to no, and Magic link (text).
Set the privacy rules to allow visible for everyone: the magic link and the used link yes/no fields.
Creating the magic link (just the token, don’t send the email), the database entry and scheduling the workflow 24 later:
Now we manually send the email to the customer, using the unique id we generated for that data-type:
Overview: you will send a link to the user but not the magic link, instead we going to send a URL with the data-thing liked to it:
Example: https://yourapp.com/magiclink/1681488414196x852184615368523800
In the empty page/dummy page: Page is loaded → Make changes to the current page: Used: yes → Navigate to a link → Current page magic link:
Backend workflow to regenerate a magic link: Generate a new link as step 1 (just the token, don’t sent the email), and make changes to that scheduled thing as step 2, where you will replace the magic link field with the new one. Make sure you add only when data-type Used is no.
And don’t forget to re-schedule again this workflow in 24 hours:
So it doesn’t matter at what moment the User will click the link that he receives in the email because the “redirect” that will happen after he clicks on the “dummy/empty” page will redirect him always to an “alive” magic link.
If you don’t understand any step let me know,
Redu.
7 Likes
