question

ben-m avatar image
ben-m asked David Marginian Deactivated commented

Oauth2 return url being ignored for merchants installing during Oauth2 flow

Hi Clover Community,

I was doing some tests earlier to isolate a specific bug where our Oauth2 return URL was not being followed for certain users. It specifically affects new merchants with no current app subscription. We use this URL when it comes back from Clover

  • To validate that it is a legitimate request.
  • To know the UUID of the UI to update if the origin is from our app UI and not the Clover App Market.


The return URL is being constructed with query parameters on our end for the above reasons. ( It could be a URL path, it would do the same, and the results of these tests are exactly the same. )

If the merchant has boarded once with any employee, it redirect to the redirection URL fine, and if query parameters were passed in, it appends them at the end of the usual merchant, app and employee UUID that is returned by Clover.

However, if the merchant has NOT boarded on the app yet, or has uninstalled it. The Oauth2 return URL is ignored and the new window being opened after selecting a subscription is the App Config's "Site URL".

This is the only time I've implemented Oauth2 where my return URL is completely disregarded.

If there is an undocumented way, or if I've missed documentation documentation added within the last year, I would really appreciate being pointed in the right direction.

App MarketOAuth
10 |2000

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

1 Answer

·
David Marginian avatar image
David Marginian Deactivated answered David Marginian Deactivated commented

By return URL I assume you are talking about redirect_uri, is that correct? So that I am clear, you are saying that a merchant that has not previously installed your app (or has but has uninstalled it) is redirected to the Site URL instead of the redirect_uri when they first install your app, is that correct?

9 comments
10 |2000

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

ben-m avatar image ben-m commented ·

Yes, that is exactly it.

0 Likes 0 ·
ben-m avatar image ben-m David Marginian ♦♦ commented ·

Thank you for your reply David. That is a VERY unfortunate and crippling design choice in some cases, made only by Clover as far as I know. I'm having a hard time believing this is actually intended as it provides no security benefits and quite frankly makes a lot of the features of Oauth2 unreliable the developers, since we have no way to know if a merchant installed our application before they authenticate.


I have a few solutions in mind, but I'd like to know your take on this. Maybe I'm focusing on the wrong thing;

Should a developer want to RELIABLY keep progress on an app authentication in a UI, how would they?
Given that:


- Users are guests on the app ( Only access is the login with Clover page ) until they authenticated with Clover as an account provider.

- Authentications always begins on our app server before going to the /oauth/authorize endpoint ( Access to both browser data + server for pre-auth setup )

- Authentications callback sometimes comes back with zero way to know if it originated from the merchant clicking the "open app" from a random tab, or if it was part of the authentication that the UI is still waiting for.


As per the thread linked, would it be possible to update the documentation so it reflects this behaviour?

0 Likes 0 ·
Show more comments

Write an Answer

Hint: Notify or tag a user in this post by typing @username.

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Welcome to the
Clover Developer Community