I’m using a ‘send magic link’ action in my app that redirects a user to an error page on error and a confirmation page on success, today when looking at my logs, i see that a lot of people are navigating my error page, and the only ways to reach this are: 1) having the link and entering it (extremely rare) 2) Using a faulty link, with an incorrect confirmation uuid (it seems odd to happen, but can be possible) 3) Passing more time than the confirmation time provided (possible).
Is there any way to debug this issue, like what is the URL the user is entering the browser to access this page? Example: USER A = mypage.com/error?confirmation=faultyID. Or specifically to know the causes of when my users are being taken to this page?
I tried with the logs but i couldn’t find a way to know tje request the user is doing when accessing my page or the faulty magic links redirection.
I tried with the ‘HTTP Request’ and ‘HTTP Response’ filters in logs, but i’m only getting the flows from Sendgrid when sending an email.
All the ‘Magic Link’ Action behind scenes seems to be around shadows, is there any deeper explanation of what happens internally, how it communicates with Bubble’s Auth API and how does the Sendgrid encoded URL works? There are a lot of questions unanswered in the official announcement also @sam8@grace.hong
This is a possible issue, but it’s a hacky solution and not ideal, also i cannot find a way to debug if the links are being faulty or it’s another reason.
I’ve gone down this rabbit hole before. It looks s/t like this:
Store each magic link request / token
Add parameters to the magic link, IDing it as a magic link, whether it was successful or failed and the UID from Step 1.
On the page, if the url parameter tells you a magic link was used, update the record created in step 1 (or create a log associated with it) with the full url and success / failure, and timestamp.
You can then run a API workflow for all failures to update the failure reason on records from Step 1 by checking if the link was used already or if the link expired. Once this is run any failures that don’t fall into these categories are the issues you’lll want to debug and you’ll have the full url to tell you if the link got messed up somewhere along the way.
Yes! have seen that, but the problem persists, they should show what happens behind scenes, it’s very difficult to debug these situations and having to make a fix ton knowing what the problem is is not good at all.
That’s a good solution! i’m doing something like that without the last step. There is a possible bug where email providers transform the link and the user gets redirected incorrectly (the link received by the user is a sendgrid encoded link).
