Allows a Titanium application to use the iOS Touch ID authentication mechanism.
Touch ID is a security mechanism that uses a fingerprint to authenticate the user. The fingerprint sensor is located in the Home button of the device. Users can use their fingerprint instead of entering their passcode for authentication.
The Touch ID module is available with the Titanium SDK starting with Release 3.4.0. This module only works with devices running iOS 8. You can only test the Touch ID module on a device.
The device must have a Touch ID sensor in the Home button and Touch ID must be setup in order to use the Touch ID authentication mechanism. You can set up Touch ID in iOS Setup Assistant or by tapping Touch ID & Passcode from Settings.
For information on setting up Touch ID, see iPhone 5s: Using Touch ID.
Add the module as a dependency to your application by adding a <module>
item to the
<modules>
element of your tiapp.xml
file:
<ti:app>
...
<modules>
<module platform="iphone">ti.touchid</module>
</modules>
...
</ti:app>
Use require()
to access the module from JavaScript:
var TouchID = require('ti.touchid');
The TouchId
variable is a reference to the module. Make API calls using this reference:
TouchID.authenticate({
reason: 'Verify to modify personal settings',
callback: function(e) {
Ti.API.info(e);
}
});
The current context will, once evaluated, be used until it's instance gets released or invalidated. You can you use the invalidate method to force the user to be prompted every time a new authentication is triggered. On iOS 9 and later, this can also be called to cancel a current evaluation of an auth-context, e.g. to hide the auth-dialoag.
For more infos regarding the keychain integration, check the
The module contains a sample application in the
<TITANIUM_SDK_HOME>/modules/iphone/ti.touchid/<VERSION>/example/
folder.
Item data can only be accessed once the device has been unlocked after a restart. This is recommended for items that need to be accesible by background applications. Items with this attribute will migrate to a new device when using encrypted backups.
Item data can only be accessed once the device has been unlocked after a restart. This is recommended for items that need to be accessible by background applications. Items with this attribute will never migrate to a new device, so after a backup is restored to a new device these items will be missing.
Item data can always be accessed regardless of the lock state of the device.
This is not recommended for anything except system use. Items with this
attribute will migrate to a new device when using encrypted backups.
Item data can always be accessed regardless of the lock state of the device.
This option is not recommended for anything except system use. Items with
this attribute will never migrate to a new device, so after a backup is
restored to a new device, these items will be missing.
Item data can only be accessed while the device is unlocked. This class is only available if a passcode is set on the device. This is recommended for items that only need to be accessible while the application is in the foreground. Items with this attribute will never migrate to a new device, so after a backup is restored to a new device, these items will be missing. No items can be stored in this class on devices without a passcode. Disabling the device passcode will cause all items in this class to be deleted.
Item data can only be accessed while the device is unlocked. This is recommended for items that only need be accesible while the application is in the foreground. Items with this attribute will migrate to a new device when using encrypted backups.
Item data can only be accessed while the device is unlocked. This is recommended for items that only need be accesible while the application is in the foreground. Items with this attribute will never migrate to a new device, so after a backup is restored to a new device, these items will be missing.
Constraint logic operation - When using more than one constraint, all must be satisfied.
Constraint logic operation - When using more than one constraint, all must be satisfied.
Security: Application provided password for data encryption key generation. This is not a constraint but additional item encryption mechanism.
Constraint - Device passcode.
Constraint - Device passcode.
Constraint logic operation - When using more than one constraint, at least one of them must be satisfied.
Constraint logic operation - When using more than one constraint, at least one of them must be satisfied.
Create access control for private key operations (i.e. sign operation).
Constraint - Touch ID (any finger). Touch ID must be available and at least one finger must be enrolled. Item is still accessible by Touch ID even if fingers are added or removed.
Constraint - Touch ID from the set of currently enrolled fingers. Touch ID must be available and at least one finger must be enrolled. When fingers are added or removed, the item is invalidated.
User presence policy using Touch ID or Passcode. Touch ID does not have to be available or enrolled. Item is still accessible by Touch ID even if fingers are added or removed.
Device owner was authenticated using a biometric method (Touch ID).
Device owner was authenticated using a biometric method (Touch ID).
Touch ID authentication is required. If Touch ID is not available or not enrolled, policy evaluation will fail. If Touch ID is locked out, passcode is required as the first step to unlock the Touch ID.
Touch ID authentication dialog contains a cancel button with default title
"Cancel" which can be customized using cancelTitle
property and a fallback
button with default title "Enter Password" which can be customized using
fallbackTitle
property. Fallback button is initially hidden and shows up
after first unsuccessful Touch ID attempt. Tapping cancel button or fallback
button causes evaluatePolicy call to fail, returning a distinct error code.
Biometric authentication will get locked after 5 unsuccessful attempts. After that, users have to unlock it by entering passcode.
Device owner was authenticated by Touch ID or device passcode.
Device owner was authenticated by Touch ID or device passcode.
Touch ID or passcode authentication is required. If Touch ID is available, enrolled and not locked out, user is asked for it first, otherwise they are asked to enter device passcode. If passcode is not enabled, policy evaluation will fail.
Touch ID authentication dialog behaves similarly as the one used by
AUTHENTICATION_POLICY_BIOMETRICS
. However, instead of "Enter Password"
button there is "Enter Passcode" button which, when tapped, switches the
authentication method and allows users to enter device passcode.
Passcode authentication will get locked after 6 unsuccessful attempts with progressively increased backoff delay.
Constant indicating that the app cancelled authentication.
Constant indicating that the app cancelled authentication.
Constant indicating that the authentication was not successful.
Constant indicating that the authentication was not successful.
Constant indicating that there is an invalid context.
Constant indicating that there is an invalid context.
Constant indicating that the key has been permanentely invalidated.
Constant indicating that the key has been permanentely invalidated.
Constant indicating that the passcode is not set for the device.
Constant indicating that the passcode is not set for the device.
Constant indicating that iOS cancelled authentication, for example, if another application enters the foreground.
Constant indicating that iOS cancelled authentication, for example, if another application enters the foreground.
Constant indicating that Touch ID has locked out.
Constant indicating that Touch ID has locked out.
Constant indicating that Touch ID is not available on the device.
Constant indicating that Touch ID is not available on the device.
Constant indicating that Touch ID does not have any enrolled fingerprints.
Constant indicating that Touch ID does not have any enrolled fingerprints.
Constant indicating that the user canceled authentication.
Constant indicating that the user canceled authentication.
Constant indicating that the user tapped the fallback button to enter their passcode.
Constant indicating that the user tapped the fallback button to enter their passcode.
The fingerprint image was too noisy due to suspected or detected dirt on the sensor.
The fingerprint image was too noisy due to suspected or detected dirt on the sensor.
The fingerprint image was too noisy to process due to a detected condition (i.e. dry skin) or a possibly dirty sensor.
Only a partial fingerprint image was detected.
Only a partial fingerprint image was detected.
The fingerprint image was incomplete due to quick motion.
The fingerprint image was incomplete due to quick motion.
The fingerprint image was unreadable due to lack of motion.
The fingerprint image was unreadable due to lack of motion.
The name of the API that this proxy corresponds to.
The name of the API that this proxy corresponds to.
The value of this property is the fully qualified name of the API. For example, Button
returns Ti.UI.Button
.
Sets the global authentication policy used in this Touch ID context.
You should set this property before checking the availability or
starting the authentication. By default, AUTHENTICATION_POLICY_BIOMETRICS
will be used to authenticate using the Touch ID sensor only. Using the
AUTHENTICATION_POLICY_PASSCODE
constant will still try to authenticate
with Touch ID first and use the passcode as the fallback.
This API can be assigned the following constants:
Default: Modules.TouchId.AUTHENTICATION_POLICY_BIOMETRICS
Indicates if the proxy will bubble an event to its parent.
Some proxies (most commonly views) have a relationship to other proxies, often established by the add() method. For example, for a button added to a window, a click event on the button would bubble up to the window. Other common parents are table sections to their rows, table views to their sections, and scrollable views to their views. Set this property to false to disable the bubbling to the proxy's parent.
Default: true
The Window or TabGroup whose Activity lifecycle should be triggered on the proxy.
The Window or TabGroup whose Activity lifecycle should be triggered on the proxy.
If this property is set to a Window or TabGroup, then the corresponding Activity lifecycle event callbacks will also be called on the proxy. Proxies that require the activity lifecycle will need this property set to the appropriate containing Window or TabGroup.
Adds the specified callback as an event listener for the named event.
Name of the event.
Callback function to invoke when the event is fired.
Applies the properties to the proxy.
Properties are supplied as a dictionary. Each key-value pair in the object is applied to the proxy such that myproxy[key] = value.
A dictionary of properties to apply.
Initiates the Touch ID authentication process.
A special note for Android:
When you call this method in Android, if you provide an incorrect fingerprint and receive an error message "Unable to recognize fingerprint", do not call authenticate. Instead, get the user to try again. If you call authenticate, it will end up in a bad state. This flow will be improved in the next update for Android.
Dictionary of arguments passed to the method, e.g. the reason to autheicate and the callback.
Checks to see if device is configured for Touch ID authentication.
On Android this takes into account the authenticationPolicy
.
Example:
var TiTouchId = require("ti.touchid");
var result = TiTouchId.deviceCanAuthenticate();
if (!result.canAuthenticate) {
alert('Message: ' + result.error + '\nCode: ' + result.code);
} else {
alert('Device can authenticate');
}
Fires a synthesized event to any registered listeners.
Name of the event.
A dictionary of keys and values to add to the Titanium.Event object sent to the listeners.
Invalidates the current Touch ID dialog.
The context is invalidated automatically when it is (auto)released.
This method allows invalidating it manually while it is still in scope. Invalidation terminates any existing policy evaluation and the respective call will fail with ERROR_APP_CANCELLED. After the context has been invalidated, it can not be used for policy evaluation and an attempt to do so will fail with ERROR_INVALID_CONTEXT.
See the "Lifetime Notes (iOS-only)" paragraph in the module paragraph for more infos.
Determines if the current device supports Touch ID.
Removes the specified callback as an event listener for the named event.
Multiple listeners can be registered for the same event, so the
callback
parameter is used to determine which listener to remove.
When adding a listener, you must save a reference to the callback function in order to remove the listener later:
var listener = function() { Ti.API.info("Event listener called."); }
window.addEventListener('click', listener);
To remove the listener, pass in a reference to the callback function:
window.removeEventListener('click', listener);
Name of the event.
Callback function to remove. Must be the same function passed to addEventListener
.
Sets the value of the authenticationPolicy property.
New value for the property.
Sets the value of the bubbleParent property.
New value for the property.
Sets the value of the lifecycleContainer property.
New value for the property.