Skip to content

Conversation

@SUPERCILEX
Copy link
Collaborator

@samtstern We currently throw an exception, but I think we should be smarter about this. Now, everything gets merged together into one unique set of providers and scopes.

Signed-off-by: Alex Saveau <saveau.alexandre@gmail.com>
Copy link
Collaborator Author

@SUPERCILEX SUPERCILEX left a comment

Choose a reason for hiding this comment

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

@samtstern I feel like this is a good change, but since I didn't create an issue first I'd be fine with you telling me no.


IdpConfig config = (IdpConfig) o;

return mProviderId.equals(config.mProviderId);
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

@samtstern Identifying providers by provider id only and completely ignoring scopes makes sense to me, do you agree?

private int mLogo = NO_LOGO;
private int mTheme = getDefaultTheme();
private LinkedHashSet<IdpConfig> mProviders = new LinkedHashSet<>();
private List<IdpConfig> mProviders = new ArrayList<>();
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

This is much better, we were converting this to a list anyway which seems kinda pointless.

*/
public SignInIntentBuilder setProviders(@NonNull List<IdpConfig> idpConfigs) {
mProviders.clear();
Set<String> configuredProviders = new HashSet<>();
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Less memory usage if you don't overlap providers! 😄

return this;
}

private boolean isIdpAlreadyConfigured(@NonNull String providerId) {
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I moved it to where it's being used (in the deprecated setProviders).

assertTrue(emailScopes.size() == 2);
assertTrue(emailScopes.contains("A") && emailScopes.contains("B"));

assertTrue(providers.get(1).getProviderId().equals(AuthUI.GOOGLE_PROVIDER));
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

@samtstern Did I get all the possible cases?

Signed-off-by: Alex Saveau <saveau.alexandre@gmail.com>
Signed-off-by: Alex Saveau <saveau.alexandre@gmail.com>
@samtstern
Copy link
Contributor

@SUPERCILEX what is the use case for specifying the same provider multiple times in the builder? I think throwing an Exception is good since I doubt the developer meant to specify duplicate providers and we are probably helping them catch a mistake.

@SUPERCILEX
Copy link
Collaborator Author

@samtstern If a user enables a setting in the setup of the app, they get logged in with different permissions than the standard setup. This means I have to take my default configuration, remove the IdpConfig for Google, and add it back with the new permissions by doing an addAll to my existing permissions. Whew! It's kind of a pain, but also not that big of a deal. It would just be easier to add another IdpConfig with the extra permission I need and have FirebaseUI merge it for me.

@samtstern
Copy link
Contributor

@SUPERCILEX my personal opinion is that there will be more people saved from doing the wrong thing by the error-throwing behavior than there will be people who appreciate the merging of IdpConfig.

# Conflicts:
#	auth/src/main/java/com/firebase/ui/auth/AuthUI.java
Signed-off-by: Alex Saveau <saveau.alexandre@gmail.com>
@SUPERCILEX SUPERCILEX changed the title Make AuthUI.SignInIntentBuilder#setProviders(List<IdpConfig>) smarter Bug fixes and perf improvements for setting providers in AuthUI Feb 16, 2017
@SUPERCILEX
Copy link
Collaborator Author

@samtstern Okay, that makes sense. I made some improvements to increase readability and reduce memory thrashing along the way so I'll leave this PR open and focus its changes on that instead.

public FlowParameters getFlowParams() {
if (mProviders.isEmpty()) {
mProviders.add(new IdpConfig.Builder(EMAIL_PROVIDER).build());
}
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

This is why we should always do this kind of thing in the build method: if people call setProviders(Collections.emptyList()), we will start the auth flow with no providers. Now, we can guarantee that at least the email provider is provided.

@samtstern
Copy link
Contributor

@SUPERCILEX SGTM, we can move forward with the general improvements.

@googlebot
Copy link

So there's good news and bad news.

👍 The good news is that everyone that needs to sign a CLA (the pull request submitter and all commit authors) have done so. Everything is all good there.

😕 The bad news is that it appears that one or more commits were authored by someone other than the pull request submitter. We need to confirm that they're okay with their commits being contributed to this project. Please have them confirm that here in the pull request.

Note to project maintainer: This is a terminal state, meaning the cla/google commit status will not change from this state. It's up to you to confirm consent of the commit author(s) and merge this pull request when appropriate.

@SUPERCILEX SUPERCILEX changed the base branch from version-1.2.0-dev to version-2.0.0-dev February 23, 2017 03:23
@samtstern
Copy link
Contributor

Forgot that you had updated this, but LGTM. Squashing and merging.

@samtstern samtstern merged commit 9d09ce8 into firebase:version-2.0.0-dev Feb 24, 2017
@SUPERCILEX SUPERCILEX deleted the providers branch February 24, 2017 17:15
@SUPERCILEX
Copy link
Collaborator Author

@samtstern Oops, I forgot to ask you to wait for @amandle's PR to be merged since this one caused a bunch of merge conflicts. I created amandle#1 to fix the conflicts. Sorry about that!

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.

3 participants