Firebase-ios-sdk: [auth] anonymous auth missing 'firebase' providerData

[Salakar]

[READ] Step 1: Are you in the right place?

• For issues or feature requests related to __the code in this repository__
  file a Github issue.
  
  
  
  • If this is a __feature request__ make sure the issue title starts with "FR:".
  
  
• For general technical questions, post a question on StackOverflow
  with the firebase tag.
• For general Firebase discussion, use the firebase-talk
  google group.
• For help troubleshooting your application that does not fall under one
  of the above categories, reach out to the personalized
  Firebase support channel.

[REQUIRED] Step 2: Describe your environment

• Xcode version: Any
• Firebase SDK version: 4.0.2
• Library version: Any
• Firebase Product: auth (auth, database, storage, core, messaging, etc)

[REQUIRED] Step 3: Describe the problem

FIRUser.providerData array is empty when signed in anonymously, however the android sdk returns 1 array item when signed in anonymously with the following properties in the map/dictionary:

Steps to reproduce:

Sign in anonymously. See code below.

Relevant Code:

FIRApp *firApp = [FIRApp appNamed:@"foobar"];

[[FIRAuth authWithApp:firApp] signInAnonymouslyWithCompletion:^(FIRUser *user, NSError *error) {
  // user.providerData array is empty
}];

Have found this issue whilst working on the react native firebase implementation, library specific code is as follows:

• Android
  
  
  
  • iOS
  
  

[XiangtianDai]

@Salakar I'm sorry that Firebase Auth's implementations for the list of providers are inconsistent between platforms. On both iOS and Web this implied "firebase" provider (which is represented as the user object itself) is omitted from the array, while on Android it is listed as an explicit provider in the array. At this moment I don't see how we can change any of the implementations without breaking existing developer code that may have already depended on them, so my suggestion is:

• If you are on Android and want iOS behavior, filter out the "firebase" provider from the result array returned bygetProviderData() method.
• If you are on iOS and want Android behavior, add the FIRUser instance itself to the beginning of the result array returned by providerData property getter.

[Salakar]

@XiangtianDai ok, makes sense, will work around it to match the ios & web implementations,

Another couple inconsistency queries if I may:

• FIROptions vs FirebaseOptions:
  
  
  
  • On the iOS implementation (FIROptions) it's possible to get and set the clientId.
  
  
  • On the android implementation (FirebaseOptions) there's no way to get the clientId on an initialised app, and, there's also no way to set the clientId via FirebaseOptions.Builder.
  
  
• FIRApp vs FirebaseApp:
  
  
  
  • On the iOS implementation (FIRApp) it's possible to delete an initialised app via deleteApp.
  
  
  • On the android implementation (FirebaseApp) there's no way, or at least a documented way of deleting an initialised app.
  
  

I have some other inconsistency issues between ios & android and am unsure where to address these? (sorry if this is the wrong place 🙈 ) Right now though the ones above are my main concern - could you perhaps if possible advise on solutions/workarounds please?

[XiangtianDai]

@davidair for FirebaseCore

[Salakar]

@XiangtianDai @davidair any updates on my previous comments?

[morganchen12]

@Salakar there's no workarounds for the two things you mentioned. It's likely that we can change Android to suit iOS behavior as a non-breaking change, since it just involves adding API stuff.

This is tracked internally at b/67354438, and isn't likely to be a priority for the time being.

[ryanwilson]

@protocol86 - can you address whether or not the Android solution or iOS solution is the correct one here? If iOS is correct, we should close this bug and address it internally on the Android side since there's no actionable items for this repo.

[protocol86]

The iOS library exhibits the expected functionality. A bug has been filed against the Android SDK, who will release it as soon as is feasible (though they are somewhat limited due to this being a breaking change).