Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Added URLCredential documentation #63

Open
wants to merge 4 commits into
base: master
Choose a base branch
from

Conversation

Chandlerdea
Copy link

Although it is not well known, URLCredential is a great way to store credentials. It works with URLSession, and also persists credentials on the user's keychain.

Copy link
Contributor

@irrelevantat irrelevantat left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like the addition - it's a good reminder to use NSURLCredential where possible.

I would even be open to recommend this as the default way and rewrite the previous paragraph.

README.md Outdated
@@ -454,6 +454,8 @@ Even in an age where we trust our portable devices with the most private data, a

If your app needs to store sensitive data, such as a username and password, an authentication token or some personal user details, you need to keep these in a location where they cannot be accessed from outside the app. Never use `NSUserDefaults`, other plist files on disk or Core Data for this, as they are not encrypted! In most such cases, the iOS Keychain is your friend. If you're uncomfortable working with the C APIs directly, you can use a wrapper library such as [SSKeychain][sskeychain] or [UICKeyChainStore][uickeychainstore].

There is also a way to store your credentials with [NSURLCredential](https://developer.apple.com/documentation/foundation/nsurlcredential) and [NSURLCredentialStorage](https://developer.apple.com/documentation/foundation/nsurlcredentialstorage). You create and store your access token in a `NSURLCredential`, and store that credential in a `NSURLCredentialStorage` instance. You will also need to specify a [NSURLProtectionSpece](https://developer.apple.com/documentation/foundation/urlprotectionspace), which represents a server or an area on a server, commonly referred to as a realm, that requires authentication. You can persist the credentials in the user's keychain, or for a single request.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Small typo in NSURLProtectionSpece 😊

@Chandlerdea
Copy link
Author

@sebastian-hojas I edited the previous paragraph to use NSURLCredential as the default. Let me know what you think.

README.md Outdated
If your app needs to store sensitive data, such as a username and password, an authentication token or some personal user details, you need to keep these in a location where they cannot be accessed from outside the app. Never use `NSUserDefaults`, other plist files on disk or Core Data for this, as they are not encrypted! In most such cases, the iOS Keychain is your friend. If you're uncomfortable working with the C APIs directly, you can use a wrapper library such as [SSKeychain][sskeychain] or [UICKeyChainStore][uickeychainstore].

There is also a way to store your credentials with [NSURLCredential](https://developer.apple.com/documentation/foundation/nsurlcredential) and [NSURLCredentialStorage](https://developer.apple.com/documentation/foundation/nsurlcredentialstorage). You create and store your access token in a `NSURLCredential`, and store that credential in a `NSURLCredentialStorage` instance. You will also need to specify a [NSURLProtectionSpece](https://developer.apple.com/documentation/foundation/urlprotectionspace), which represents a server or an area on a server, commonly referred to as a realm, that requires authentication. You can persist the credentials in the user's keychain, or for a single request.
If your app needs to store sensitive data, such as a username and password, an authentication token or some personal user details, you need to keep these in a location where they cannot be accessed from outside the app. Never use `NSUserDefaults`, other plist files on disk or Core Data for this, as they are not encrypted! In most such cases, the iOS Keychain is your friend. It is best to store your credentials in the iOS Keychain with [NSURLCredential](https://developer.apple.com/documentation/foundation/nsurlcredential) and [NSURLCredentialStorage](https://developer.apple.com/documentation/foundation/nsurlcredentialstorage). You create and store your access token in a `NSURLCredential`, and store that credential in a `NSURLCredentialStorage` instance. You will also need to specify a [NSURLProtectionSpace](https://developer.apple.com/documentation/foundation/urlprotectionspace), which represents a server or an area on a server, commonly referred to as a realm, that requires authentication. You can persist the credentials in the user's keychain, or for a single request. There are also wrapper libraries such as [SSKeychain][sskeychain] or [UICKeyChainStore][uickeychainstore], that let you interact with the keychain directly, but this is not recommended.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, that improves the paragraph really. Thanks for the addition.

I'd suggest to change the discouragement of using the keychain to a recommendation to only use it when NSURLCredential isn't sufficient.

- [You can also use tools] that let you interact with the keychain directly, but this is not recommended.
+ If using `NSURLCredential` does not meet your needs, you can also store credentials in keychain directly. To avoid using the C APIs directly, you can use wrapper libraries such as [...]

@hlung
Copy link

hlung commented Sep 26, 2018

Is there an example on how to use NSURLCredential ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants