search

iZettle / sdk-ios

Add card payments from Zettle to your own app
https://developer.zettle.com/docs/ios-sdk
Other
82 stars 38 forks source link

SDK version 1.1 and "enforcedUserAccount" property #7

Closed ticketco closed 8 years ago

ticketco commented 9 years ago

Is it possible to apply a lit of several UserAccounts when this is applied? Like a whitelist of accounts (including sub-accounts)?

jensutbult commented 9 years ago

No, the enforcedUserAccount property is just one single user account.

ticketco commented 9 years ago

How will the login process work with this property? Obviously we do not want hundreds of users to be given both a user ID and password that is similar. Can we supply the user name hidden in the login process so the SDK only asks the user for the password?

jensutbult commented 9 years ago

You set the property to e.g "john@doe.com". When set no other user will be able to login or take payments through the SDK. One use case for this is to force the SDK to use a specific iZettle account. The login process is the same as without the property set.

bensebborn commented 9 years ago

We would really like to be able to 'hide' the login process from the user completely.

In many cases, the person using the app should not have any access to the izettle account, including the mobile app. They are often just operators and should not have any access to information, which is currently available using the same login credentials on the izettle app. Revealing the password to them could mean they could log into the izettle account and refund payments.

Instead, we would prefer to pass their credentials through our API securely, and login the user through the SDK when it initializes without them having to know the details. This way the app can be used by operators without revealing the password to them, which is much more secure.

mattiasjahnke commented 9 years ago

Hello @skiddle

We're aware of this being a requested feature and it's something we're looking into.

ticketco commented 9 years ago

I second skiddle´s comment.

Also a scenario, which allow the SDK partner to control the login, will add security to the SDK usage. We as an SDK partner can then enable og disable access to the iZettle SDK from our own technology platform. We have experienced a few cases where our customers are "dual" iZettle users. Meaning they use our app and iZettle´s app in the same environment (but for different tasks). This has lead to "incorrect" accounts beeing used in our app which again have triggered support cases. Summarised, I think it is important that the SDK partner have the ability to control iZettle user account access to the iZettle SDK when beeing used in the SDK partner app.

Hless commented 9 years ago

@mattiasjahnke

Is there any update on the 'hide login process' feature? I'm currently in need of such a feature for my project.

I'd also like to know how long sessions are kept before they expire. How long does it take before the user has to login again and does frequent use prevent the session to expire?

mattiasjahnke commented 9 years ago

@Hless

At the moment we're focusing on the release of iOS 9 and making sure our product and SDK are ready for the it.

Regarding 'hide login process', we're having internal discussions about how we can improve the flow for both our integrators and the user. What we're aiming for is a solution that gives the integrators greater control over the authentication, but at the same time don't compromise the users credentials (solutions where the users credentials are stored and handled by an integrator is out of the question for obvious reasons). The change will most likely impact our backend architecture, making it a rather big project - but it's definitely something that we will address.

The sessions does not have a TTL, hence frequent use does not have an impact on it at all.

Hless commented 9 years ago

Thanks for the response :). We'll wait patiently then until a solution of some sort is implemented.

Great that sessions don't have a TTL, this will be sufficient for us in the meantime I suppose.

Rauleinstein commented 8 years ago

We were able to hide the login process by remembering the password but this feature seems not to work anymore.

mansbernhardt commented 8 years ago

@Rauleinstein not sure I follow you. Could you elaborate?

If using enforcedUserAccount and the same user is already logged in, no login screen will appear. However, if no user is logged in or the logged in user is not the same as the enforced user, a login screen will appear with the enforced user account pre-filled and read only.

jensutbult commented 8 years ago

The new behaviour of enforcedUserAccount was released in version 1.2.0 of the SDK. The documentation has also been updated. Closing issue.