LiveCode Forums.

A while back there was some discussion about schemes for app registration.

I've searched and cannot find them now. Don't know if it rolled off the board or if I'm just not using the right keywords in my search.

Anyway, this blog post: Identifying App Installations

...talks about the pitfalls of trying to tie an installation to a physical device, and in the "Conclusion" at the end, states: "For the vast majority of applications, the requirement is to identify a particular installation, not a physical device. Fortunately, doing so is straightforward."

I don't know if I'm being dense, but it doesn't seem so straightforward to me. As an example, lets say one has an enterprise type app where a "company" would pay, and allow each of its "contractors" to install and use the app. Each "company" would supply a list of user id strings, unique to each of its "contractors". When one of these "contractors" installs the app, the app would first ask the user for the "company" and their supplied "user id string". The app can then phone home to confirm that the user id is "not yet used", and activate. The server side database would mark the "user id" as "in-use".

In this type of unique scheme/need, if the "contractor" gets a new phone, they could not activate on their new phone....unless the server allowed it (figuring they got a new phone)....and if that were the case, the "company/user id" could be activated on many phones. *IF* the server did NOT allow it, then some sort of confirmation that the "contractor" did indeed get a new phone would need to be made, and then the server side 'record' for that "contractor" (user id) would have to be "reset" to allow another activation.....

Could someone help me with my screwed up thinking on how to implement "tracking an app installation vs a physical device"?

Thanks!

hi pkocsis,
I'm with you...

Fortunately, doing so is straightforward.

I don't see it that way.

I recall there were talks of various ways to do this, I think the easiest was to record "the milliseconds" at first run (install?), and used that as the unique identifier.
For moving to new devices one way may to be to add a "-n" to the end of the ident string. This does rely on internet connection to verify the current enabled version of the app, disabling previous installations?
No, this method is not 100% effective but pretty close.

There is the new UUID function which you might record.

oops... How to re-install after a factory reset?
I haven't seen an easy way to do that part. I guess a reg screen would be involved based on the original milliseconds and email address?
Lots of situations to think about.

Simon

Hi Simon,

Thanks so much for responding.

Yes, I remember that discussion about the milliseconds but can't find it.

I was playing with the UUID function, and I think the use of that is the way to go. I've been thinking about the following scenarios:

1) first time user

a) ask for username and password
b) generate UUID (using username/password/milliseconds) and save it to phone. Send username/password/UUID to server. Server marks username/password database entry with "in-use" and stores UUID, then responds "OK" to app.
c) app runs normally

Question on "1b": Is there a place to store the UUID so that if the user uninstalls the app, the UUID file stays around?


2) user factory resets phone OR user gets new phone

all same as above EXCEPT server will see that the username/password is "in-use". Server marks previous (in-use) UUID entry as "shut-off". Server stores NEW UUID with username/password and sends "OK" to app



The app would have to periodically "phone home" with username/password/stored-UUID. If server encounters username/password/UUID that is old, I.E. marked "shut-off", it sends "NOPE-shut-off" back to app. App refuses to run. If phoning home once a week or so, an app that SHOULD be shut-off might get an extra week's use, but that's no big deal.


Of course the above is conceptual, and I would take steps to try to obfuscate the "activation" and periodic "phone-home", but does the above sound reasonable?

Question on "1b": Is there a place to store the UUID so that if the user uninstalls the app, the UUID file stays around?

Nah, I think an uninstall would remove the Data (documents folder) as well, no reason to keep that around.

You didn't include a "Is this app registered to be used?" in your write up, it's somewhere in that "phone home".
Are you thinking it's also ok for the single app to be used on multiple devices own by the registered user?

Send username/password/UUID to server

Not sure how you intend to verify the user. Email addresses are unique (unless shared, blah), normally the email address is used to communicate and verify to the app owner.

Again much handshaking (hand-wringing? ) to be thought about.
But you are on the right track.

Simon

Hi Simon and thanks again for helping!

You didn't include a "Is this app registered to be used?" in your write up, it's somewhere in that "phone home".

Yes, when the phone home occurs, if all is ok server-database-wise with the particular user, then the server will respond "AOK-all is well" and app will continue to operate. Is this what you mean?

Not sure how you intend to verify the user. Email addresses are unique (unless shared, blah), normally the email address is used to communicate and verify to the app owner.

Well, the "companies" will pre-send in a list of userid's for their contractors. I'm thinking it'll be up to them on how they want to identify each contractor. Be it an email address, or contractor #, or whatever....as long as the user string is unique per each of their contractors. The app will collect this "userString" from the user and the server will use that to identify the user in a database.

Is that sounding OK?

Thanks again Simon!

Paul

Hi Paul,
The above 2 questions were the same idea, the Registered User.

I'm only going to suggest the email address again because it's available right now with no additional layers of work. They have a list of their contractors email addresses and in a professional environment they are unique. But heck... the client wants to use ID's then you use ID's. Simples

I'm not seeing any holes in your plan at the moment, for now you have a good idea of the steps needed for implementing registration.

Confidential Information? Check with the client on that. You might start thinking of a "Delete User Application" being a third action in your phone home, OK/In use/Delete application, this is for contractors no longer employed by the client. As contractors work for your client the legal stuff falls on your client not you, so if your app stores info that the contractor added they can't complain to you when you delete it.

Simon