square / reader-sdk-ios-quickstart

Reader SDK Quick Start Sample iOS App
https://developer.squareup.com/docs/reader-sdk/quick-start/start
Apache License 2.0
23 stars 4 forks source link

Request a mobile authorization code without server #4

Closed maulikpat closed 6 years ago

maulikpat commented 6 years ago

Hi,

Is it possible to obtain a mobile authorization code within app ? I mean without server implementation. App will have Location ID and application ID so can app create a request to obtain ?

If so any sample code ?

StephenJosey commented 6 years ago

The quick-start shows how to generate it via your Square Dashboard: https://docs.connect.squareup.com/payments/readersdk/quickstart/page3

maulikpat commented 6 years ago

@StephenJosey yes. But token will expires in predefine time right ? after that need to get new code ?

maulikpat commented 6 years ago

@StephenJosey or I can generate once and hardcode in app, will it work ?

StephenJosey commented 6 years ago

The Mobile Authorization Code will expire in 90 days if you haven't taken a payment while using it. Since you only need to authorize it once, there's not much point in hardcoding it, you should just pass it to your application somehow (in the demo we let you paste it in or use QR code from the Developer Dashboard). If you need to authorize again, you'll need to generate a new authorization code.

maulikpat commented 6 years ago

@StephenJosey ok.

  1. Is there any way to pass authorization code other than manual type and QR scan to SDK ? Like hardcode inside the app ?

  2. Authorization code will only expires if no transaction for 90 days ? If any transaction is made on 89th day, the same authorization code will work other 90 days from that day ?

  3. How can app know authorization code is expired and need new code ? Any notification when app starts or need to have manual logic for 90 days ? As same code will be used in more than 1 device at a time.

Currently, I am using Square POS sdk to accept payments and my app is something like Kiosk machine. So it will be hard to scan qr or input manually the code.

StephenJosey commented 6 years ago
  1. You can hardcode it, although it's not very advised because it's a one-time code (you can't use the code more than once, so there would be no reason to hardcode it).
  2. Yes, that is correct.
  3. You will receive an error after 90 days, as your application will become deauthorized and won't be able to do anything through ReaderSDK. You can check if it's currently authorized: https://docs.connect.squareup.com/api/reader/ios/Classes/SQRDReaderSDK.html#/c:objc(cs)SQRDReaderSDK(py)isAuthorized If your application becomes deauthorized, you'll need to re-generate a new mobile auth code.

Also, you cannot use the same code for more than 1 device. This code is a one-time use code (which is why we recommend a back-end solution). You'll need to generate a new code for every device you need to authorize.

maulikpat commented 6 years ago

@StephenJosey ok got it. So I will need to different code for each devices. So batter to have code via API call.

maulikpat commented 6 years ago

ok so now I am able to get Auth code from app itself without need of server. I have converted cURL to NSURL for objective C and getting proper response from Square.

@StephenJosey 1 more thing, is it ok if I call API to get code for multiple times before 90 days ? I am getting new code each time so I think its fine.

Please suggest.

StephenJosey commented 6 years ago

I strongly recommend you to not make API calls from your app directly, as that's a security risk to embed your personal access token inside of your application.

That aside, you shouldn't need to generate a new code every time. You can use the method I mention above to see if your ReaderSDK app is currently authorized. If it's not, then generate a new code.

maulikpat commented 6 years ago

@StephenJosey ok I will implement through server. Thanks.

Also currently we are supporting to POS sdk as well so location ID and access token is already there in app. So I used from that.

More, our apps are not for app stores. Still, there is any risk ?

StephenJosey commented 6 years ago

Since you're not widely distributing your application, it technically is a lower-risk, but I still encourage everyone to use a server-side implementation, as it's merely good practice.