Browser should not open on mobile if scanning for desktop login

[nick-verida]

There was work done on the "redirect after login" functionality where after logging in, the mobile app would open a new URL.

This should ONLY occur if the use is logging into an app on their mobile device. If they are scanning a QR code the app should return to the home screen.

Acceptance Criteria

• On desktop browser, go to https://vault-examples.demos.verida.io/connect and login. Mobile app should return to the Vault homescreen after logging in and not open an external browser.
• On mobile browser, go to https://vault-examples.demos.verida.io/connect and login. Mobile app should open new browser window with the app in logged in state.

[aurelticot]

@nick-verida I don't know how it works. Does the Vault recognise if it's coming from a deep link or from the QR code (particularly when scan from the Camera app rather than the Vault itself)?

I was thinking a different way, the client SDK adds the openURL parameter in the deep link (current implementation) but not in the URL encoded in the QR code (the evolution to fix this issue).

No evolution on the Vault itself, but on the client SDK instead.

[RochelleBondoc]

Hi @nick-verida @cmcWebCode40 , Is this a similar issue as this one? Zero-Data-Labs/demo-credential-issuer#83

[aurelticot]

Is this a similar issue as this one? verida/demo-credential-issuer#83

It is but it was open on the demo frontend while it is actually a bug in either the Vault or the SDK

[nick-verida]

Reassigning to @saadibrahim

[saadibrahim]

I have done the code changes required for this, and I have raised two PR's however I want @tahpot 's input on this as this requires a change in verida-js, just wanna know if proposed solution is okay by him.

For context, this related to the work I had done earlier, these are the two PRs from before (they have loom demos):

verida/verida-js#64
#559

The change is basically adding a mobile=true parameter to the URL on mobile and not doing the redirect if it's found when received by Verida Vault. Here are the PRs for these changes:

verida/verida-js#230
#721

@tahpot please advise, let me know if you wanna get on a call for this.

[aurelticot]

How about removing the openUrl property rather than adding a new parameter to handle on both sides (in the SDK and in the Vault)?

In this issue, it's not about mobile or desktop. The most generic characteristic is whether the App and the Vault are on the same device or not:

• When the user clicks the "Open in Verida Vault" button, it's on the same device, we should pass the openUrl property
• When the user scans the QR Code, we can assume it's a different device, we do not pass the openUrl property

No need to update the Vault, it redirects only if openUrl is there. No need to add a new param to handle. Also the name of the parameter mobile=true is restricting and may not be future-proof.

[saadibrahim]

That's a valid point however there's a technical limitation here, the app that is passing the openUrl isn't aware if the user has a mobile device or desktop device, hence I came up with this solution.

[tahpot]

I agree with @aurelticot. The protocol should remove openUrl if on the same device. As such, this issue requires no action in the Vault and should be a protocol issue.

the app that is passing the openUrl isn't aware if the user has a mobile device or desktop device, hence I came up with this solution.

@saadibrahim I'm not following what you say here. The app does no what device it's on, this logic is already used to show a Open in Verida Vault option or display the QR code.

[aurelticot]

the app [...] isn't aware if the user has a mobile device or desktop device

The App doesn't need to know and there's no need to have a difference between mobile and desktop either.

The SDK generates two things:

• A deeplink for the "Open in Vault" button. With the openUrl
• A QR Code with some properties. Without the openUrl

What matter is what the user actually uses, the QR code or the button.

[saadibrahim]

I agree with @aurelticot. The protocol should remove openUrl if on the same device. As such, this issue requires no action in the Vault and should be a protocol issue.

the app that is passing the openUrl isn't aware if the user has a mobile device or desktop device, hence I came up with this solution.

@saadibrahim I'm not following what you say here. The app does no what device it's on, this logic is already used to show a Open in Verida Vault option or display the QR code.

My bad, my knowledge of the protocol is limited, I will look into this again and get back.

[aurelticot]

Slightly related note:

The app does no what device it's on, this logic is already used to show a Open in Verida Vault option or display the QR code.

@tahpot this logic is actually a bit constraining. There are edge cases we are not covering (not a big priority tbf), for instance:

• Opening an App in a small window on desktop (without the Vault) will hide the QR code and display the button
• Opening an App on a tablet's browser with a big enough screen will display the QR code and hide the button, even though the Vault could be installed in the tablet
• Having the Vault on my main smartphone but opening an App on my secondary smartphone is not working because the QR code is hidden.

They are not the most common use cases. But just to say we have to stay flexible and not constrain ourselves too much.

We could improve the UI so that it provides both options (QR code + button) all the time (but still emphasising the most relevant one: button on mobile, QR code on non-mobile)