Appendix - Dealing with Idle Lock (iOS)

(New in DAF SDK version 1.9.13)

Previous versions of the DAF SDK would not correctly handle the GD runtime's Idle Lock timer expiring, if this happened whilst a "change password" sequence was in progress. The correct behaviour is for this sequence to be cancelled, and for the UI to return to the "locked" state.

Background

In the DAF SDK for iOS, a change-password sequence is started when the application calls requestChangePassphrase: in the DAFAppBase class. In response, core code will send GetAuthToken, GetOldPassword and GetNewPassword requests (see enum DAFUIAction) to the application delegate's getUIForAction: method.

These requests will normally show a view to the user and await for some action. Most simple applications will send GetOldPassword and GetNewPassword requests to the default getUIForAction: implementation in DAFAppBase; this will show the DAF SDK's built in password-entry views.

When old and new passwords have been entered, the password-change operation is attempted, and a DAFUINotification - either ChangePasswordSucceeded or ChangePasswordFailed - is sent to the application's eventNotification: receiver.

Lock during change password

The GD runtime's Idle Lock timer can expire at any time during the change-password sequence. Other events (including the DAFAppBase deauthorize: call) can also trigger the application becoming locked. When this happens, it is important that the change password sequence is not completed: if the idle timer expires, it is unsafe to assume the authenticated user is still in control of the device. If the device was displaying an 'enter new password' prompt at the time, anyone who now has possession of the device would be able to set a new password without first being authenticated.

To deal with this situation, the DAF core code will send a new ChangePasswordCancelled DAFUINotification to the application's eventNotification: function. Your app *must* handle this notification correctly.

To do this, refer to eventNotification:withMessage: in the DAFSkelAppDelegate.m in the DAF 'Skeleton' example. This does the following:

• Passes the notification to DAFAppBase's notification handler. This is necessary so that, if the DAF SDK's built-in password-entry screen is showing at the time, it can be removed.

      [super eventNotification:event withMessage:msg];
  

• Passes the notification to any other view controllers which could be showing at the time:

      [self.mainViewController updateUIForNotification:event];
      [self.firstTimeViewController updateUIForNotification:event];
      [self.unlockViewController updateUIForNotification:event];
      // ...
  

Each of these view controllers should cancel the current user operation. If the view controller is being used to handle the GetAuthToken action, the DAFWaitableResult object used to return the auth token value should have an error set.

The code in DAFSkelUnlockViewController which does this is as follows:

    if (event==ChangePasswordCancelled && result != nil)
    {
        [self dismissViewControllerAnimated:NO completion: ^{
            [result setError:[NSError errorWithDomain:"DAFSkelUnlockViewController"
                                                 code:101
                                             userInfo:NSLocalizedDescriptionKey:"Change password cancelled"} ]];
            result = nil;
        }];
    }

Setting this error will cause the change-password sequence to be completed in an orderly way (note that no ChangePasswordFailed notification is sent). As soon as this is done, the DAF core code will begin a new authentication sequence, beginning with a GetAuthToken DAFUIAction request.