How many authenticators can I implement in my Oomph app?
An Oomph application can make use of at most one authenticator.
How many devices can use an authenticator login?
We place no limit on the number of devices that can log in via authenticator. Since we pass through a unique identifier for each device with each call to your verify API, if you wish, you could provide some lock-out functionality through your authenticator. For example, if there have been more than a certain number of devices using a single redeem token (that number being totally at your discretion), you could reject that user.
Once a user signs into the application, do they have to sign back in the next month?
This will depend if the authenticator is time based or purely just an unlock. The app requests the list of available issues from the Oomph server at launch and at various other times. When the authenticator is an unlock authenticator, all issues will be provided to the client, the user will have access to everything, and will not have to log in again.
When the authenticator is time-based, the server will provide all issues that fall within that time period. Once the time period has elapsed, the user will have to log in again, to either be provided with further access to the content or denied access to the content. If the issue is not unlocked, then rather than placing the issue into the user's My Issue screen, they will be moved back to the Downloads screen, and the app will display the Redeem or Purchase through Apple buttons again.
Do my Msite pages need to be full HTML pages or just fragments?
They need to be fully self contained HTML pages, with HTML, HEAD, BODY, etc. tags.
Can I test my authenticator Msite pages in a browser?
Does the msite need to maintain a user's login state?
No. Your msite should not maintain any state in session variables, cookies and so on. It is very important that your msite behaviour is consistent each time it is accessed, even when it is accessed by the same user.
What format does my verify API endpoint need to return?
How do I validate the JSON my API returns?
We recommend using a JSON library to produce your output (as this will ensure it is well formed), or, run it through a JSON validator. A great online validator is http://jsonlint.com. Our Authenticator Tester iPad app will also verify your JSON for you. Please contact support if you require access to this app.
Regarding the API endpoint - how long should the token be valid? For example, if the user's subscription expires, the API endpoint for validating the token should reflect that, so should the endpoint also check the status of the user's subscription every time it's called?
It depends on the kind of authenticator you create: - Time-based: It needs to be valid forever, i.e. return a user's details forever. The reason being that a user may wish to download issues they were previously entitled to, at a date in the future. - Non-time-based: As this is a lock/unlock scenario, it should reflect the user's current status, so if they're no longer entitled to access they should not validate successfully.
What happens when a token is no longer valid, or a subscription runs its course?
If the authenticator unlock is revoked, access is removed to issues that have not been downloaded, but the downloaded issues are not removed. However, if the user deletes any downloaded issues, they will not be able to restore them.
In the case of a time-based subscription expiring, access is removed to issues that have not been downloaded, but the downloaded issues are not removed. The user will continue to be able to restore issues downloaded as part of the subscription, even if they have deleted them.
How often is the verification API called?
The authenticator unlock token is checked at launch (after a hard-close). It may also occur at various other times, such as when the "Redeem" button in the menu is tapped or when the "Redeem" button is tapped from within the purchase view of an issue that is not recognised as being part of a valid subscription period.
Is an SSL certificate required for our authentication page?
This is up to you, our API will work fine with both secured and unsecured pages.
What information do we need to pass back on approval?
Our servers will be expecting back JSON with the following:
Required Keys: status: [ok|invalid] Optional Keys for subscription receipts [start_date]: timestamp [end_date]: timestamp
What format is the timestamp returned from the verify API endpoint?
The timestamp is he difference, measured in milliseconds, between the current time and midnight, January 1, 1970 UTC. Note that the timestamp must be passed as a numeric type (not a string) in the JSON object returned to our server.
Note that the timestamp is a numeric value and should not be sent as a quoted string in the JSON payload.