# TOPasscodeViewController **Repository Path**: idoing/TOPasscodeViewController ## Basic Information - **Project Name**: TOPasscodeViewController - **Description**: https://github.com/marinofaggiana/TOPasscodeViewController - **Primary Language**: Swift - **License**: MIT - **Default Branch**: master - **Homepage**: None - **GVP Project**: No ## Statistics - **Stars**: 0 - **Forks**: 0 - **Created**: 2022-04-25 - **Last Updated**: 2022-04-25 ## Categories & Tags **Categories**: Uncategorized **Tags**: None ## README # TOPasscodeViewController > A modal passcode input and validation view controller for iOS.
`TOPasscodeViewController` is an open-source `UIViewController` subclass that will overlay a full-screen passcode UI over an app's content. The user must enter the correct password into it in order to proceed, or hit 'Cancel' to exit the private part of the app.
This sort of UI is useful for certain apps that contain highly sensitive information (such as banking or health) where users may indeed want an extra level of security beyond the standard iOS passcode.
## Features
* Prompts users to enter a passcode in order to proceed.
* May be presented as a translucent overlay, partially showing the normal app content behind it.
* Supports 4 different passcode types, from 4-digit passcodes, up to full alphanumeric passcodes.
* Supports 4 base themes, including translucent/opaque and light/dark.
* Supports Touch ID validation.
* Provides an additional settings view controller for letting users change their passcode.
* Passcode validation is handled by the parent app through a variety of delegate callbacks.
* A custom animation and layout when the device is rotated to landscape mode on iPhone.
* Custom 'opening' and 'dismissal' animations.
## System Requirements
iOS 8.3 or above
## Installation
#### As a CocoaPods Dependency
Add the following to your Podfile:
``` ruby
pod 'TOPasscodeViewController'
```
#### As a Carthage Dependency
Coming soon. :)
#### Manual Installation
Download this project from GitHub, move the subfolder named 'TOPasscodeViewController' over to your project folder, and drag it into your Xcode project.
## Examples
`TOPasscodeViewController` operates around a very strict modal implementation. It cannot be pushed to a `UINavigationController` stack, and must be presented as a full-screen dialog on an existing view controller.
### Basic Implementation
```objc
- (void)showButtonTapped:(id)sender
{
TOPasscodeViewController *passcodeViewController = [[TOPasscodeViewController alloc] initWithStyle:TOPasscodeViewStyleTranslucentDark passcodeType:TOPasscodeTypeFourDigits];
passcodeViewController.delegate = self;
[self presentViewController:passcodeViewController animated:YES completion:nil];
}
- (void)didTapCancelInPasscodeViewController:(TOPasscodeViewController *)passcodeViewController
{
[self dismissViewControllerAnimated:YES completion:nil];
}
- (BOOL)passcodeViewController:(TOPasscodeViewController *)passcodeViewController isCorrectCode:(NSString *)code
{
return [code isEqualToString:@"1234"];
}
```
## Security
`TOPasscodeViewController` does **not** perform any password management on your behalf. Any passcodes the user enters are forwarded to your own code via its delegate, and it's up to you to perform the validation and return the result back to `TOPasscodeViewController`.
This was an intentional decision for security reasons. Instead of every app using `TOPasscodeViewController` implementing the exact same validation and storage code path, you're free to custom tailor the way passcodes are handled in your app as you see fit.
No matter which passcode type, all passcodes in `TOPasscodeViewController` are handled as strings. When storing them in your app, they should be given at least the same level of scrutiny as full passwords. As such, I would strongly recommend you generate a salted hash of any user-defined passcode, and store both the hash and the salt in a protected location, like the iOS secure keychain, or an encrypted Realm file.
Because passcodes are treated as generic strings, if the user has selected a different passcode type (like an arbitrary numerical or alphanumeric one), you should also store that setting alongside the hash as well.
## How it works