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

Initial integration with TidepoolKit #3

Merged
merged 1 commit into from
Mar 17, 2020

Conversation

darinkrauss
Copy link
Contributor

  • Include Carthage build to lessen impact to build time (like DashKit)

This is just the initial integration and only adds the login UI to the TidepoolService creation workflow. It does not yet do anything after login.

You can probably ignore the files in Carthage/Build. They are cached simply so as to not impact the build times.

- Include Carthage build to lessen impact to build time (like DashKit)
Copy link
Contributor

@nhamming nhamming left a comment

Choose a reason for hiding this comment

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

LGTM

Copy link
Contributor

@rickpasetto rickpasetto left a comment

Choose a reason for hiding this comment

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

This is temporary, right? It's not generally common practice to check in the Carthage/Build directory into source code control.

Copy link
Contributor

@ps2 ps2 left a comment

Choose a reason for hiding this comment

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

Just a question about the storage class for credentials. Otherwise, looks good to me!


extension KeychainManager: SessionStorage {
public func setSession(_ session: TSession?, for service: String) throws {
try replaceGenericPassword(nil, forService: service)
Copy link
Contributor

Choose a reason for hiding this comment

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

Is there a reason this is using generic password storage rather than internet password storage?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The TSession is a struct that contains an authentication token, user id, session trace, and environment. It is not an email and password that are implicit in the internet password storage. I felt it better fit into this, but I can switch it if you want. If so, what should go in the email field and what should go in the password field?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Actually, I'm going to pull apart the TSession struct and put much of it into UserDefaults (because I have other related things to go in there) and only put the authentication token in the keychain. I'll still use the generic password since it is just the token (and not email/password).

Copy link
Contributor

@ps2 ps2 Mar 16, 2020

Choose a reason for hiding this comment

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

At the point the user enters a username/password, and if it is the same as the pair that the user enters on the web, then we should probably keep it as an internet password.

Storing the returned session token I agree should use the generic class, or some other secure storage.

(removed comment about credential sharing with safari; not sure that's possible)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

TidepoolKit and TidepoolService are intentionally not capturing the email and password. The authentication token should suffice here and provides better security.

Copy link
Contributor

Choose a reason for hiding this comment

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

As long as we're careful about not expiring the session tokens and thus forcing the user to do password entry at times they haven't requested it (like overzealous/broken token refresh schemes), I think that makes sense.

@darinkrauss
Copy link
Contributor Author

@rickpasetto I just modeled committing the Carthage/Build directory after DashKit (which does the same thing) in order to not slow down build times. I'm fine with removing it at some point as long as folks understand it will jack up build times by a couple minutes just for this (as a Carthage build is terribly slow).

@rickpasetto
Copy link
Contributor

@darinkrauss but, it only slows the build down the first time, right? Are you talking about CI builds or user builds on their machine?

@darinkrauss
Copy link
Contributor Author

@rickpasetto Correct, CI builds are the main concern. Considering the LoopWorkspace build is already a drag on getting stuff merged into dev, I think we want to do everything we can to speed it up.

Locally, though, you'll only take the hit once (unless you clean your build folder).

However, I think this discussion can be taken out of this PR. I'm going to leave it as-is, particularly since this is all in development. We can remove if we decide to when it is more mature.

@rickpasetto
Copy link
Contributor

@darinkrauss sounds good to me.

@darinkrauss darinkrauss merged commit dfdb09b into dev Mar 17, 2020
@darinkrauss darinkrauss deleted the darinkrauss/integrate-tidepoolkit branch March 17, 2020 01:22
ps2 added a commit that referenced this pull request Apr 21, 2023
Updated translations from Lokalise on Thu Feb  9 13:30:18 CST 2023
ps2 pushed a commit that referenced this pull request Jul 26, 2023
* Remote handling rearchitecture

* Rename method

* Update names

* Remove Remote 2.0 parts
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.

4 participants