#Nyxi
main basin
worldly lava
Hi there
placid musk
If you inspect the return_url of pi_3MqaWxK31833OsWF1d1gsJoc, you'll see it contains a JWT used to authenticate on redirection. It is now expired, as it's short-lived, but it's not super great to log
It's the only reliable way to maintain the session across redirects
as iOS may switch to a different browser
worldly lava
Hmm no you can't redact info in request logs yourself.
You are concerned about the merchant seeing this in their Dashboard?
placid musk
No, I'm just concerned about it being stored anywhere
I mean, you can see it
And I guess the connected account could too, yes
Not sure how to solve this problem
worldly lava
I see, what about using cookies instead?
placid musk
Cookies belong to the browser
If you switch browser, you don't have a cookie
This happens if you start the flow from within say Instagram or Snapchat (in-app browser) on iOS, then appswitch to a payment method (in this case MobilePay); iOS will open the default Safari when redirecting back from the MobilePay app
And they don't share cookies
And we cannot control this behavior at all
Hence the need for the JWT to maintain the state, or the user will end up on the login screen instead of "your payment was successful"
I guess we could blacklist the JWTs once consumed, but it's a fair amount of extra work
placid musk
I guess we *could* blacklist the JWTs once consumed, but it's a fair amount of e...
This still leaves a window where the token is un-consumed though, especially if the payment intent is abandoned
So redaction would definitely be the safest approach
worldly lava
So this is for a web app specifically. Like you aren't redirecting back to an iOS app
worldly lava
Okay give me a minute
placid musk
I mean, in general, a user-supplied array of "keys to always redact" would be a good security feature
In this case I would then pass ["redact" => ["return_url"]] or something
worldly lava
Yeah we don't have a redaction feature like that right now. I'll log a feature request as it is good feedback. I'm not thinking of another good way to handle this currently other than exposing the JWT for a very short amount of time and then consuming it after it times-out (if it isn't consumed before then). Otherwise, you are going to have to have your customer log back in.
placid musk
Okay cool
Logging back in is not an option, as they've already paid at this point so it will be super confusing
And we need to have it work for 5 minutes because it's the timeout of mobilepay
so there's not much to do here
I guess we live with it for now
the exp on the token is already limited to 5 minutes
worldly lava
Gotcha then yeah that is going to be the best state currently
placid musk
Thankfully, the way it's designed right now it's only Stripe, us and the merchant that can theoretically access it
None of those parties should be interested in abusing it
The session only grants you access to purchasing additional tickets (it's a ticketing site)
you can't access anything else, so you'd essentially just be attacking yourself as a merchant