So, I have an App where the user needs to sign up to access the app. I'm planning to run an offer where user can order that item only once in a day. But I have the doubt that he may change login Id (if have multiple emails) and can place the order with Different ID's.
I'm thinking of registering the device with an email id:
Pros: - Not able to login with a different email Id.
Cons: - Not able to use the app on a different device ( if changed) as it may give an error email Id already registered with another device.Which leads to deregister from the previous device (Chances device may not be available).Or raise a ticket which is time-consuming. this may lead to customer loss.
Have also, read about IP tracking, Phone number, and Credit card details but not satisfied with the answers (somebody already raised for same). So what will be a good method to avoid multiple logins/sign up from the same device?
You can get the MAC adress from device using WifiInfo.getMacAddress()
Related
The company I am working at offers a web based calculation tool which has to be paid monthly (a fixed price for a license).
Normally, users go to our website and authenticate themselves with their credentials and then can use the application. When they cancel their subscription they are not able to use the tool anymore, obviously.
Now another company called us because they want to provide our application for their own clients. We have already fixed that they have to pay a license fee for every of their clients. But there is also a restriction: their users should not have to log in on any of our websites (only on the website of our client). But the web application is hosted on our server and is loaded as an iframe.
Now there is that problem that we are not sure whether our client tells us the correct number of people who use our application wherefore we would like to verify that in some way.
One of my ideas is the following:
Our client has to call an API for every users who would like to use our application in order to submit some information like name or an unique ID of that user
When the user would like to access our application, an ID parameter is appended to the iFrame URL
I think that this is not a very good solution because our client could use the same ID for every access and pretend that only one users uses the application. By saving the ip address and id of the accesses it is possible to determine fraud in some cases because ip address will not change frequently.
We even do not have to know WHICH user accesses the application but only the NUMBER of users per month.
I am interested if there is a cryptographic solution where it is hard to cheat. Something like an authentication method which does not require any interaction of the user.
Well you can't. You should require the partner to issue a token for each user so you know they came from the partner.
You could have the partner call an api you expose to issue a one time token for a user and specify user id and IP. You could alternatively have the partner digitally sign such a login request.
If you bill the partner per user, and the partner decitfull he could claim less users.
You can fingerprint the users, you can give long term coockies, you can check IP and fonts installed etc. These will allow you to detect most types of fraud.
If you give a declared userId a cookie and then see him again without it, you assign him a new cookie and then later see the first cookie again while the partner is always declaring same id that is a very strong indicator of fraud.
If I was the decietfull partner I would pair up geographicly close users and merge their IDs. it would look no different from a user with two devices. But this still limits the extent of fraud possible. Two devices per user is plausible. 10 less so.
Find business partners you trust.
I have my app running on a Nexus 5 (Marshmallow) which has 2 active registration ids. Just want to know if that is normal by GCM behavior?
Here's how it's causing me trouble:
Android M has come up with Group permissions - which means the user chooses whether or not he wants the app to have access to his device identifiers (Android ID). Let's assume he denies it and I can't identify the device. The way my app functions is that a user can log in from multiple devices, all of which remain in sync. Because a user can be on mulitple devices, I must handle multiple registration IDs to send push messages (and I cant be sure of the number of devices the user is on, as they can deny providing the device identifiers). This means that I cant delete/update any registration ids on the server side, but only send every push message to all recorded IDs against a user, in the hope that all the devices on which that particular user is signed in will receive the messages.
Because I have a device which has two active registration IDs, I am getting 2 notifications for everything.
On the client end, we were noticing frequent changes in the Registration IDs, we have a class that keeps generating registration ids and updating the server.
Having multiple registration Ids can be a bug in the client app (which you have to deal with).
And the only way to ensure that there will only be one notification being sent per device is to implement canonical IDs on the server side. It is included in the webservice response as "canonical_ids".
Canonical IDs
If a bug in the client app triggers multiple registrations for the same device, it can be hard to reconcile state and the client app might end up with duplicate messages.
Implementing canonical IDs can help you more easily recover from these situations. A canonical registration ID is the registration token of the last registration requested by the client app . This is the ID that the server should use when sending messages to the device.
If you try to send a message using an old registration token, GCM will process the request as usual, but it will include the canonical ID in the registration_id field of the response. Make sure to replace the registration token stored in your server with this canonical ID, as eventually the old registration token will stop working.
Here is a related issue
android GCM get original id of canonical id which tackles how canonical ids work in the actual code
Imagine an iphone app that automatically registers users on the first start according to their phone identity (e.g. phone number*) on a server database.
Afterwards, users should see which of their friends already use the app, i.e. which of their contacts are registered on the DB.
An obvious solution would be to always send a select-request to the DB containing all of the users contacts, everytime the user refreshs his or her friend list. As a result, the user retrieves the list of their registered contacts (friends).
Is there any better way to realize this synchronization between the user management on the server and the contacts in the user's address book. Sending multiple select-requests (each user for every refresh) with dozens of phone numbers might not be performant at all.
Example:
WhatsApp is actually a good example for this scenario. You can add new contacts to your address book and WhatsApp automatically refreshs your WhatsApp friend list according to your phone book. I really like this idea because the user don't need to create an account manually.
*I know about the problems of using phone numbers in AppStore apps, so this question really focusses on the architectural problem.
EDIT
this comment (Whatsapp contacts syncronization) describes the mentioned simple approach. but is this really the smartest way?
I am implementing a simple server-side verification for Windows 8 IAPs and I'm slightly baffled on how to handle this. Basically what I do know is I verify the receipt using the code that was included in the example
http://msdn.microsoft.com/en-ie/library/windows/apps/jj649137.aspx
In the example, there is a AppReceipt and ProductReceipt. If I understood it correctly, having a simple IAP to buy, for example, gold in the game, I am only interested in the ProductReceipt. However, I don't understand why "AppReceipt" is included here at all. Is the initial app purchase always included in the receipt or is it an optional field?
So an unified way of making sure the user cannot "cash in" the same receipt twice would simply to save the ProductReceipt ID in the back end database? And that this would be a valid approach for both durables and consumables, of which the latter is not yet implemented?
AppReceipt is just an example that you can ignore. In most cases game will send you receipt (ProductReceipt XML) and you will have to verify it on server side.
If you look at: http://social.msdn.microsoft.com/Forums/windowsapps/en-US/8b3cf68d-897d-4a47-ace0-2c42355bf688/protecting-your-windows-store-app-from-unauthorized-use?forum=windowsstore
You will notice:
The ID of each receipt element is unique per user (and device) and you can validate it on your server to confirm that the transaction is legitimate for that user and not a fraudulent transaction. This is especially valuable when your app has its own authentication mechanism because it allows you to validate that each user that appears to have purchased your app is, in fact, a unique customer.
So if you want to, you can extract IDs from this XML.
I want to make an application that has some views for information display. If I install my app on my iPhone then it should display the info. If I then install that app on my iPad then the app should recognize the device and display the info related to my account.
Is there any way to find the single user of two devices without the user's iTunes credentials, or is it possible to generate a key that can identify the common user of both devices?
No, currently there is no way to associate multiple devices to a single user owning those devices given the information you've provided.
However, if you added, "the information I want to display in the views, pertains to the same user account in Game Center for both devices", then you could use the player's identifier from Game Kit API.
https://developer.apple.com/game-center/
This is being added well after the fact, but:
You could use iCloud APIs to accomplish this. These are distinct from iTunes credentials, but obviously the same type of prerequisite in that the user must have an account and it's not under your control.