I am developing an iOS app, where I would need to access the phone number of the user logging in, query the DB to check if the phone number exists as an entry & finally display an alert to the user. Is it possible?
Read Apple response on this kinda app rejection..
"For security reasons, iPhone OS restricts an application (including its preferences and data) to a unique location in the file system. This restriction is part of the security feature known as the application's "sandbox." The sandbox is a set of fine-grained controls limiting an application's access to files, preferences, network resources, hardware, and so on."
so its not possible to read the user number by your application, best way to ask him to enter and validate at your server end!
More detail about SandBox here
It's not possible to detect phone numbers from an app.
However, there are solutions that allow phone number verification (after the user inputs his phone number) by placing missed calls.
I have used such a solution provided by an India-based company named ZipDial.
Check the section titled "Mobile Number Verification" in the link above.
Related
My project have a case: one account user can only log on to one device ( if user log on to app in device A, user can't log on to app in device B). My Idea is: when user login, I'll get the imei Iphone (like android) and send it with request login to server. But I can't get imei. I try with UUID, but UUID will change when re install app. Keychain does not solve the problem. Please help me.
You have to use Keychain to store Unique Id , this will not change even if user delete app
You can use any wrapper Source code to do this
here is an example
https://github.com/Joe0708/KeychainUUID
At the beginning I'd like to mention that I do not know any method that directly answers your question, especially that Apple does not allow you to read IMEI and other similar stuff due to privacy concerns. This has been answered here.
The workaround might be as follows
Take a look at the UIDevice class, especially at the identifierForVendorProperty which provides you (according to documentation ) with a device specific value.
The value of this property is the same for apps that come from the same vendor running on the same device. A different value is returned for apps on the same device that come from different vendors, and for apps on different devices regardless of vendor.
As far as i know some financial apps are secured this way to permit only one device to access the account. This however requires registering a device each time application is reinstalled.
Alternatively you can use UUID you generate within your app (first run) and then you assign it for the user online. It might take the form similar to two step verification process. Be aware however that with such restrictions user will have to be online all the time to use your app.
I am getting started with Xamarin iOS and writing an app that requires the user to log in, using their phone number (which can hopefully be pulled from the phone via API). What I would like is the first time they use the app, to see log in and sign up buttons. Sign up takes them through a storyboard to enter information which ends up saving their details in my server database so their account is now open. Log in will check if their phone number is registered and if so, sign them in to the app based on their phone number.
However if the app closes or the phone restarts, I would like them to be automatically logged in the next time they open the app, if they have previously created an account.
I am reading a lot of tutorials on sign up/login screens but none talk about how to have an "automatic" log-in option once they have authenticated, at least until they manually click the log out button. Lots of apps do this so Im sure it should be trivial, can anyone point me in the right direction? Do I have to store a value in the iOS file system or preferences folder structure? Maintain a local iOS DB with these settings?
iOS has a NSUserDefaults class that let's you store small bits of user configuration data in a persistent manner.
You can also use the iOS Keychain to securely store user credentials.
This question already has answers here:
Programmatically get own phone number in iOS
(9 answers)
Closed 7 years ago.
all
I'm developing app and it contains function which gets phone number and email from device.
I've looked at some samples on internet but all of them are about unique id.
How can i get phone number and email from device?
Is there anybody who has experience in this area?
Apple has removed access to this data from inside your app. You may not access the user's phone number from the device. You instead must require them to enter it in a text field or something.
"For security reasons, iPhone OS restricts an application (including
its preferences and data) to a unique location in the file system.
This restriction is part of the security feature known as the
application's "sandbox." The sandbox is a set of fine-grained controls
limiting an application's access to files, preferences, network
resources, hardware, and so on."
The device's phone number is not available within your application's
container. You will need to revise your application to read only
within your directory container and resubmit your binary to iTunes
Connect in order for your application to be reconsidered for the App
Store.
This is not possible from the iOS APIs, you will need to query the user for phone number or discover it through other means.
I have an app that is uniquely branded for each customer (think restaurants, etc.) I need to have the user be able to click on a link to my server that contains a unique code, stores that temporarily on the iOS device (cookie, etc.) and then directs them to the app store to download the app. Then when it is downloaded, the app grabs that cookie or temp. data on launch and brands the app for that customer. I know this is possible on Android, but is it on iOS?
Downloading the app first and then selecting the brand (or restaurant) is not feasible in this case, as the url wil be shared with other customers of the same business and we want to create a fluid experience, where they won't be able to "see behind the scenes" and choose a different branding.
Thanks
Edit
Thank you for all the replies. We've reevaluated and are considering having the url be opened on the device and grabbing the IP address or another unique id, and saving that along with the correct brand to a database. The app will then connect to the database on launch, and if the IP's match, will brand accordingly. We're looking for a more reliable identifier than IP, however. Now that UDID is deprecated, are there any other identifiers we can use?
I think the design you propose of a webserver link creating the code that needs to be read by the iOS app later is the issue. You should have a solution that is entirely app based. Perhaps you can have the same services on the website be available as one app which then sets up the code in pasteboard. The user then launches the actual app that looks at the pasteboard and skins itself accordingly.
That being said, data can be shared between apps from the same app seed ID by using UIPasteboard in addition to a few other ways.
I use the pasteboard to share info between apps quickly and easily using this class.
You can use identifierForVendor (UDID replacement) to identify individual devices. Are you planning on harvesting those identifiers prior to the end user "registering" the device at the final location? If not you'll never be able to determine which device belongs where.
What about having the end-user logging into your server as that restaurant? It can be a somewhat generic login per restaurant like "Wendys/Wendys5?" and "McDonalds/McDonalds7!" to determine their App Store URL. As long as the password is easy and non-programmatic to guess it would be unlikely they figure out how to register as a different restaurant. You could also do a simple restaurant selection screen coupled with a password specific to each chain but this would expose the user to which other restaurants are using the app. This way you won't have to continually add IPs if they expand locations and can revoke credentials if the login is compromised.
One question, though: Do all of your clients understand that they'll have to have an AppleID tied to each device? You can only shared a single AppleID across 20 devices.
We are building a web based system where there are money involved and we want to avoid fraud implementing a system that is able to identify the IOS device from where the requests are sent.
The reason of this security is because we offer money for execute actions from a mobile and we only want the user to obtain the money once, if we are not able to identify the device the user can execute the action several times.
This unique identifier can use any HTML, JS, server side technique, but not any native IOS call due the application is web based and it runs in a normal Safari instance.
The unique identifier is not needed to be the official UUID.
The system doesn't need to be bullet-proof just a few more difficult to cheat than a normal cookie.
The system should works in separate sessions, like if the user comes back after one week.
Heuristic based systems are welcome, also any combination of LocalStorage with Cookies, ...
The only ways you can identify a unique user/device in a web application is to use cookies and or track the user's IP address.
Of course, the IP address of a device will change as the owner moves around and cookies can be cleared/disabled or will expire after a set time.
Letting web sites access a device unique identifier such as the UDID would be a huge security risk / privacy invasion. If you were to find such a way, I would say that you found a severe security hole in iOS.
If you are only interested in triggering i.e. an email alert when an account is suspected of being stolen, you could use a heuristic based on device type (user agent string) and geo-ip-lookup to detect if the user has suddenly changed device type and continent and ask the user to confirm that this is really the case. I believe this is what e.g. Google and Facebook does.