[🐛] Missing firebase-js-sdk API

[Nantris]

Issue

Unimplemented JS SDK features include:

• storage.uploadBytes (This one is a blocker for us) uploadBytesResumable seems like a drop-in replacement, at least for us, but maybe not for everyone and probably is a bit heavier to run. Ideally uploadBytes would be supported still.
• storage.getStream
• storage.getBlob
• storage.getBytesSync
• database.forceLongPolling
• database.forceWebSockets
• auth.TotpMultiFactorGenerator (Required for authenticator-app-based multifactor)

Also possibly the following:

• auth.unenroll
• auth.addTokenListener

I located these by searching for the string not implemented in the portions of the project we use. I've also made an effort to document the others but this may not be comprehensive, or may contain false positives for the auth ones.

---

• 👉 Check out React Native Firebase and Invertase on Twitter for updates on the library.

[Nantris]

Originally mentioned in #7433.

[Nantris]

I also noticed uploadBytes is not implemented also. Is there anything else we can use in the meantime, or any plan to implement this in the immediate future? It would be a shame to have to revert adding react-native-firebase to our app.

Unfortunately I lack the knowledge and time to help implement it.

[mikehardy]

@slapbox we handle the non-modular put API which is very nearly uploadBytes by signature, it handles the same type of input which tells me that under the covers we are already doing all the necessary things from javascript to native and back

So my first take on it is that supporting/implementing uploadBytes is probably just exporting the correct symbol and API shape, and should be nearly trivial. Those are famous last words but it really does look that way to me

Need to get react-native 0.73 unexpected incompatibility #7500 fixed before I can take a look at uploadBytes but I'll check it out with priority tomorrow

[Nantris]

Those are famous last words but it really does look that way to me

Too true!

I really appreciate your attention on this a lot. Thank you for the great project and the great assistance!

---

Workaround:

I just came back to update that it seems that uploadBytesResumable is implemented and seems so far to be a viable workaround for us, but they return different types. We're just lucky to have an implementation that can readily support both without rewriting code. Always those famous last words though.

[mikehardy]

The implementation of uploadBytes (if necessary? Do let me know if uploadBytesResumable doesn't work out...) is likely to just internally do the UploadTask await for then -> then dereference final snapshot -> map final metadata + ref into an UploadResult -> return that

Which is to say it may reduce some boilerplate by handling that for you but it's just bending around the same information and should be working exactly the same under the covers in the native layer

[mikehardy]

Coming over from #4166 -

getMultiFactorResolver is definitely implemented and working, TOTP I don't think was a focus of the original implementer (and in fact I think it was actually added as a firebase feature after the implementation of MFA here but my memory is a bit vague on the timing, apologies if wrong)

It appears uploadBytes is actually not a blocker now, is that correct?

Auth-related things obviously would be though - no one is going to change their well-considered hard-won MFA auth flows without a serious (and unwanted) battle - I understand that

So the MFA Resolver should kick out a list of hints and TOTP should be included (I think?) despite not being implemented yet here

At that point I think an implementation of TotpMultiFactorGenerator is all that is needed, and I don't recall that being very difficult.

Auth unenroll and token listeners are already present and working (in fact, native has a super-listener beyond the JS SDK of a "user change listener" which is the superset of token changes and user changes, but token listening by itself is I think all implemented.

So if I'm following along on your migration feasibility audit correctly it sounds like the TotpMultiFactorGenerator is really the blocker at the moment? If so, an implementation of that is something I could schedule

[Nantris]

Thank you as always for your great work and assistance @mikehardy!

It appears uploadBytes is actually not a blocker now, is that correct?

I'm 99% sure it's not a blocker, but I've not done extensive testing of every part of our application. We're doing a major rewrite so nothing is headed to production yet. Right now I'm just calling it "Good enough to keep moving in development."

If I encounter any portion of our code that can't use uploadBytesResumable as a drop-in replacement, it should be possible to adapt it on our end, but it would be good to have implemented in RNF eventually.

---

Regarding TotpMultiFactorGenerator - it's not a blocker for us at present, but in the future it would be if not implemented. We're planning to add TOTP support in the next few months, so I was scouting ahead to make sure the path is clear. I wanted to highlight that one because, whether we were going to use it or not, it's a security method without any possible workaround.

I think you're right that it didn't exist when getMultiFactorResolver was added. It's a rather new method; I'm pretty sure it's less than a year old.

[github-actions]

Hello 👋, to help manage issues we automatically close stale issues.

This issue has been automatically marked as stale because it has not had activity for quite some time.Has this issue been fixed, or does it still require attention?

This issue will be closed in 15 days if no further activity occurs.

Thank you for your contributions.

[Nantris]

Not stale.

[mikehardy]

Not only not stale, there's progress :-)

[github-actions]

Hello 👋, to help manage issues we automatically close stale issues.

This issue has been automatically marked as stale because it has not had activity for quite some time.Has this issue been fixed, or does it still require attention?

This issue will be closed in 15 days if no further activity occurs.

Thank you for your contributions.

[Nantris]

Not stale. Thanks to the team for the continued progress on this!

[github-actions]

Hello 👋, to help manage issues we automatically close stale issues.

This issue has been automatically marked as stale because it has not had activity for quite some time.Has this issue been fixed, or does it still require attention?

This issue will be closed in 15 days if no further activity occurs.

Thank you for your contributions.

[Nantris]

Not stale.

[github-actions]

Hello 👋, to help manage issues we automatically close stale issues.

This issue has been automatically marked as stale because it has not had activity for quite some time.Has this issue been fixed, or does it still require attention?

This issue will be closed in 15 days if no further activity occurs.

Thank you for your contributions.

[Nantris]

Bump.

[mikehardy]

Yep - usually not a fan of bumps but this actually tracks a very worthwhile chunk of work and I want it to stay open as well
I am not sure our "pin" actually avoids the stale bot (separate issue...) but hopefully it does.

[aem]

Curious if there's an update specifically on the TotpMultiFactorGenerator compatibility, and if that work can be prioritized. Unfortunately I don't personally have native mobile experience so I'm hesitant to try and contribute it, but not having access to TOTP second factors is tough given the relative insecurity of SMS.

[aem]

Would it maybe be helpful to split that out into its own issue so its not tied to the Storage + Database module work? I'm happy to do a deeper write up on the multi-factor work if that would help move it along

[hoongtong]

Is there any other ongoing development on adding TOTP compatibility aside from #7718 (which seems pretty stale)?

[mikehardy]

I have not seen it and am not aware of TOTP or MFA in general at current no - biggest blocker for me when I was developing more actively in this specific module is that the auth emulator does not support it and that still does not seem to be on their roadmap

It is very problematic - as a library developer - to run against the "real" / cloud auth APIs because they rate limit, they require a payment plan, the messages themselves always have some fakery since SMS cannot work, etc. We moved to the auth emulator a long time ago because the flakiness made developing + maintaining very difficult against the real APIs.

So, converting existing test suite back to real APIs, then fixing all the flakes etc so we have a stable baseline to develop with was the first hurdle and that's where things are at the moment. I suppose an alternate path could be to patch the auth emulator so it supports TOTP, that may be the easiest way to go in fact. Then implementing it here is probably pretty straightforward

[mikehardy]

Alternate thought - just picking up the PR and developing it in the form of local patches in an app where you know you can test it, until you know you have it working, then updating the PR and saying "hard to test but this works..." may be sufficient ?

[mare95]

Hi @mikehardy, you mentioned that it's possible to unenroll phone number as a second factor using react-native firebase library, right?

I can't find anything related to this in the docs.

I guess docs are not up to date or it has to be done via JS SDK? If so, then there is a bigger issue => onIdTokenChanged is not being triggered in the react-native app once i remove/add second factor via JS SDK which leads to incorrect state in the react-native app.

[mikehardy]

@mare95 unfortunately no it is not possible, there is (or was) a PR in #7566 here but it closed out due to being stale, and it mostly went stale for all the reasons mentioned above (that is: we use the auth emulator vs the auth cloud APIs in our e2e suite, but the auth emulator doesn't support MFA or TOTP so it is really really hard to support these APIs)

And you are correct, in that since the react-native-firebase library (which uses the native SDKs) will not be aware at all of any work you do in the firebase-js-sdk - so no listeners will fire. I think a workaround could be (needs testing!) to call the react-native-firebase user reload method after doing something in firebase-js-sdk auth, in order to force the native SDKs to consult the cloud User auth status at which point they should see anything that was changed by firebase-js-sdk and persisted to the cloud