AEROGEAR-2092 Add OIDCCredentials implementation #35
AEROGEAR-2092 Add OIDCCredentials implementation #35
Conversation
@@ -5,14 +5,47 @@ | |||
import AppAuth | |||
import Foundation | |||
|
|||
class OIDCCredentials { | |||
/// A class to represent the OpenID Connect state for an entity. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
let's use /**
format everywhere. (Rest of the changes use /** */
)
init(state: OIDAuthState) { | ||
authState = state | ||
public init(state: OIDAuthState) { | ||
self.authState = state |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That will break lint. Default rules are preventing from using self.
modules/auth/agsauth.podspec
Outdated
@@ -18,5 +18,6 @@ Pod::Spec.new do |s| | |||
s.dependency 'AGSCore' | |||
## Add other dependencies if needed | |||
s.dependency 'AppAuth' | |||
s.dependency 'SwiftKeychainWrapper' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We probably need to lock version as this third party library can be possible security threat if we will always get latest.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[Optional] Actually library seems to be just changing the api, but delivering no extra capabilities. It may make sense to just use plain apple api to simplify IOS versions support etc.
I'm not fully aware of the scope of this change so leaving decision to discussion.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@wtrocki The library makes it a lot simpler to set/read/delete data in the Keychain. The Keychain API isn't the easiest one to use in the world. What is the downside of using the lib?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@wei-lee Not a problem. Just better to specify the version range for dependency.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@wtrocki agreed.
} | ||
|
||
func testGetAccessToken() { | ||
XCTAssert(testCredentials?.getAccessToken() == OIDCCredentialsTest.paramAccessTokenVal) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[Optional] XCTAssertEqual
may look better
@aidenkeating Awesome changes! You need to run |
func load() -> OIDCCredentials? { | ||
return nil | ||
public class CredentialsManager: CredentialManagerProtocol { | ||
let AUTH_STATE_KEY = "authState" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
use reverse domain style key to ensure uniqueness of the key
/// | ||
/// - Returns: true if the credential is authorized. | ||
public func isAuthorized() -> Bool { | ||
return authState.isAuthorized | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So in swift, when you need to get a value from a class, if there is no parameter required to get the value, you normally have 2 options:
- Use computed properties, or
- Use a function that takes no parameters and return a value
Functionality-wise, they are the same, but there is subtle differences semantically.
Using computed properties means the value is a property of the class, while using functions means the value is an method/action of the class.
For this class, I think most of the values returned by the getters are actually properties (they are properties on the AuthState class as well). So from that point of view, it's better to use computed properties instead. It is also more concise to write.
WDYT?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes this makes a lot of sense. Good point.
9396f40
to
ca222e8
Compare
ca222e8
to
62f2ad5
Compare
|
||
protocol CredentialManagerProtocol { | ||
public protocol CredentialManagerProtocol { | ||
func load() -> OIDCCredentials? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[Optional] Comments are usually more important on the protocol.
Could we move comments from implementation to protocol
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch, moved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Motivation
We need a way to store and manage credentials.
JIRA: AEROGEAR-2092
Description
Create an OIDCCredentials object which is backed by an OIDAuthState.
Create a CredentialManager which takes the OIDAuthState from the OIDCCredentials and stores it using a Keychain storage library.
Progress