your server must track purchases and allow user to restore purchased subscriptions to all iOS devices owned by a single user
I also need to track purchases and allow user to restore purchased subscriptions to all iOS devices owned by a single user. However, I am not aware of any mechanism that will allow me to identify all iOS devices owned by a single user from the app. I am not even aware of any mechanism for identifying the AppleID used by the user from the app. So how am I supposed to do this?
If you are using auto-renewable subscription you can just use the restore feature of store kit. If you're using non-renewable you must allow users to share their subscription across their devices. There are several ways to accomplish this. If you own a server, you can generate a key with a purchase. Associate a number with this key that indicates how many times a user has restored to another device (say, 5). When a user then enters this key on another device, you decrease this number. You would thus have to add a "Share" button in your app that would give the user this key. And you would need an "Unlock" button where the user can enter this code. If you are interested I could also find a method for you that doesn't require a server (but this is less secure).
Hope this helps.
EDIT:
sorry, just noticed you're talking about auto renewable:
http://developer.apple.com/library/ios/#documentation/StoreKit/Reference/SKPaymentQueue_Class/Reference/Reference.html
restoreCompletedTransactions is what you're after
Related
Please help me architect the following case in Laravel:
Every instance of the Laravel app (ex. a company) will have a single username (super-user) who can control the sub-users. The super-user will log into the app once to allow the sub-users to log in and out many times throughout the day. The sub-users won't be able to access the app at all without the super-user logging in.
Example: A POS system that the manager logs into once a day. It doesn't log itself out all throughout the day. The cashiers simply tap in their password to gain access and it auto-logs out after 5 mins. There's a single system in the store so the cashiers have to keep switching on and off. The cashier wont be able to use the POS at all if the manager does not log in.
Im new to Laravel. I know I need multiple guards but how do I access auth so that it doesn't keep directing me to the super-user? Im thinking of using the default laravel authentication for the superuser. But what about the other users?
Any help or pointers in the right direction is highly appreciated!
Thanks!
Laravel cannot persist multiple authenticated users at once but you don't necessarily need that for this system, in fact you may be able to design a more robust system without it.
Defining the problem (rather than a solution) we'd say something like, "The system must allow for a manager to enable and disable the POS for cashiers so that they are only able to access it when authorised".
A system that achieves that goal can be built with a single Laravel authentication system, using different roles (manager, cashier) and the associated permissions. This is (fortunately) very straightforward with Laravel.
The user flow would be along the lines of:
A cashier visits the POS terminal
The cashier clicks "log in"
The cashier enters their identifying details
The system finds the user, identifies that they're a cashier, then checks if cashiers are allowed to log in
If yes, the cashier is logged in and able to access the POS functionality
If no, the cashier log in is rejected with an error
The manager flow would be along the lines of:
A manager visits the POS terminal
The manager clicks "log in"
The manager enters their identifying details
The system accepts their log in and sends them to the management dashboard
The management dashboard would be where the manager could control other users (create and manage cashiers (edit, delete, audit)) and set the system status as activated for cashiers, this would be protected with policies.
At the start of business the manager would log in to the POS and activate it for cashiers by setting the "active" flag to true, then the manager would log out. Through the day any cashier could log in and use it. At the end of the day the manager would log in and deactivate the POS for cashiers.
An added benefit of this system is that you could allow managers to also be cashiers so if they needed to use the POS during the day they would not need a separate account. A users manager status could be a simple is_manager database column. You could additionally implement programmatic scheduled POS availability, i.e: "allow log in from cashiers between 9am and 5pm".
Laravel is a great choice for this project as it provides everything you need out of the box, let me know if you have any other questions about your implementation :-)
I want to be able to make it so a registered user can only be logged into the DNN site from one device/browser at any one time.
I understand that the DNN core doesn't support sessions but does have a a users online table which is checked by the scheduler, however i have been unable to find anything available to use this method.
The main purpose is to stop a paid user from sharing their login details with multiple people and thereby diluting the potential revenue to the site. I would think this was not a unique use case and someone must have dealt with this previously.
Open to any and all ideas including commercial modules.
I suppose that you could create a custom login module, and reject logins from a user who appear as active in the UsersOnline table.
I haven't looked around to see what methods are available, but the old usersonline module should provide some hints.
I am designing a Node + MySQL backend for a service that requires two-factor authentication to be set up for all users as a part of the sign-up process. Users first submit a primary phone number and password (with the phone number being used for sign-in), upon which the server sends them an SMS with a six-digit code. Only after they enter the code is their account fully created.
This poses the problem of how to store data for users in the intermediate state after entering username/password but before verifying the code. Such "pending users" will not be shown in searches, do not need to store all the data a regular user would, and will be deleted after a few days if never verified. Furthermore, since every user must enable TFA to fully sign up, there will be orders of magnitude more users than "pending users". Thus, it does not seem sensible to me to have all users simply store an "isVerified" flag. I am familiar with SQL on a technical level but have no experience designing databases for production, and I am wondering what alternate mechanisms I should consider to solve the aforementioned.
My current idea is to have a separate table of pending users, having only those columns necessary to store intermediate signup information. When a user verifies, a row is created in the real user table, the signup information is copied over, and the corresponding is row deleted from the pending users table. However, this makes it somewhat ugly to ensure that the primary phone numbers are unique across both tables (which is an additional requirement of the service).
What methods/techniques should I consider to improve my solution?
You can store this data same way as store session information on server.
I am building a hybrid mobile app using AngularJS and Ionic as front-end.
Each user belongs to an organisation. But it is possible to change which organisation a user belongs to on the server and in a different web application.
The user can do some things in the web app:
Get data about the organisation
Post, put and delete data about the organisation
Each of these requires an API call to get the relevant information.
Now my question is, when and how should I check which organisation the user belongs to?
Should I send an API call before every get, post, put and delete to check which organisation the user belongs to?
If yes, then what it a nice way to organize this organisation checking without having it tangle up all my other code?
It sounds like what you're trying to get at is permissions for the user to edit, etc. the organization only when they belong to it. That should be done server-side for the following reasons:
It keeps the access control coupled to the operation, so the server can prevent disallowed reads/changes even if there's a bug in the client.
It stops malicious users from bypassing the membership check altogether, which they can do if the client is all that's enforcing the rules.
It avoids the API calls you're worried about that constantly need to recheck the user's membership, as well as the race conditions if membership changes between the check and the next call.
It handles both your Ionic client and your other web client, and lets you expand to more clients in the future, without each having to duplicate the checking logic.
Similarly, it lets you modify your permissioning logic in one place, for example if you wanted to differentiate users who can read the organization from admins who can edit it.
Once the server is solid, there are only a few places you'll need to sync the user's memberships:
At app startup, unless you keep a cache from the last use and that's good enough.
On some schedule as they use the app, if memberships change frequently enough that you want to sync quickly. Perhaps whenever they visit their list of organizations.
When the user does something in the app to invalidate the cache, like join or leave an organization.
When an API call about an organization fails, because the user may no longer be a member.
What's the best practice or the common way of keeping (or not keeping) Evernote users in your application's database?
Should I create my own membership system and create a connection to Evernote accounts?
Should I store Evernote user data (or only part of it) in my own app and let the user log in only with Evernote?
Summary: you must protect their data but how you protect it is up to you. Use the integer edam_userId to identify data.
I think the API License agreement covers protection in the terms:
you agree that when using the API you will not, directly or indirectly, take or enable another to take any of the following actions:...
1.8.4 circumvent or modify any Keys or other security mechanism employed by Evernote or the API;
If you cache people's data and your server-based app lacks security to prevent people looking at other's data, then I think you're pretty clearly violating that clause. I think it's quite elegantly written!
Couple that with the responsibility clause 1.2
You are fully responsible for all activities that occur using your Keys, regardless of whether such activities are undertaken by you or a third party.
So if you don't protect someone's cached data and another user is able to get at it, you're explicitly liable.
Having cleared up the question of your obligations to (as you'd expect) protect people's data, the question is how do you store it?
Clause 4.3 covers identifiers pretty directly although it's a bit out of date now that we are all forced to use oAuth - there are no passwords ever entered into anything other a web view. However, mobile or desktop client apps must provide a mechanism for the user to log out, which must completely remove the username and password from your application and its persistent storage.
For a web app, you can't even save the username: If your Application runs as an Internet service on a multi-user server, you must not ask for, view, store or cache the sign-in name or password of Evernote user accounts.
The good news is that you can rely on the edam_userId value which comes back to you in the oAuth token credentials response, as discussed here.
When you look at the Data Model, you can see the unique id under the User and going into the User struct, see the reassuring definition The unique numeric identifier for the account, which will not change for the lifetime of the account.
Thinking about the consequences, as you can't get the user id until you have logged into the service, if you want to provide a local login for people you will have to link your local credentials to the user id. That may irk some people if they have to enter a username twice but can't be helped.
You can allow users to log-in via OAuth. Here's a guide on how that process works.
But you'll probably also want to store a minimal amount of user data, at least a unique identifier, in your database so you can do things like create relationships between the user and their notebooks and tags. Refer to the Evernote data model for those relationships. If you're using rails, this will also help you take advantage of rails conventions.