-
Notifications
You must be signed in to change notification settings - Fork 630
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
Add support for new Firebase 3.x.x. authentication methods #764
Comments
We should also consider deprecating |
Unfortunately not, any async event will need to be wrapped. I think it's important to provide these methods to keep continuity for the developer, so I'm on board 💯. |
Well, technically we have lots of terrible choices available! We could monitor web sockets and trigger a compile when an incoming event is received (Angular 2 does some things like this internally; this one is actually not "terrible"). We could And also not a completely terrible idea, although not a perfect one: We could just provide a general wrapper that allows you to call pretty much anything that returns a promise and converts it to an Angular promise which trigger a compile. Thus you could do something like: For that matter, we could just provide some instructions in the readme for "calling other SDK methods" which uses $q.when( ... ) to achieve the same result. |
I'm not actually sure that promise idea would work Kato. I'm pretty sure (based on my experience upgrading the tests) that Promises resolving don't trigger digestion, in fact it's the opposite - |
I'm fairly sure that's only true of the mock promises, or maybe has to do with the fact that we have multiple layers of $timeout and promises, which requires multiple flushes of the mock $q library. I'm not sure why they behave so strangely. But $q does trigger an eval on root scope.
This is also in the docs but too dense to link to and summarize quickly, so this non-authoritative answer is a better tl;dr. But even if they don't trigger a compile (it's not necessarily a digest loop, btw) then a simple wrapper achieves the same end. |
Having issues using vanilla 3.0 authorization in AngularJS, any eta on having 3.0 auth support? |
@CTucker1327 this issue is about peripheral methods supported in the new auth SDK and not about vanilla auth. Auth is supported. Please submit a new issue rather than responding to a tangentially related thread. Be sure to include an mcve and any useful debug output from |
Is someone working on implementing the methods @jwngr mentioned (didn't see any PRs)? |
Nope, no one is working on this. But we would gladly enjoy some help and will take some PRs if you are willing to put them together! I think the first step would be putting together a proposal of all the methods to include. Once we have the API ironed out in this thread, the implementation can happen. Do you have a proposal for how we should organize all the new auth API methods? |
I haven't looked at the code yet, but I believe the |
Maybe. The thing is that AngularFire currently has all user auth methods off of the On a similar note, wrapping all 30 or so methods in a promise that works with the |
So to take the new About the wrapping thing, I don't think we have a choice. Writing an AngularJS module without handling change detection ( |
Let's not wrap the SDK if we have an alternative
A recipe or example of how to accomplish auth effectively would be a decent compromise on cost vs. value and take us most of the way to an answer here, while avoiding the excessive wrappage. A generic service that accepts an auth promise? Perhaps another alternative would be to provide an auth service that accepts an auth handler and handles the digest portion, without having to wrap all the methods. Usage might look something like this:
Maybe we don't need either? One other thought occurs to me here. If we simply monitor I think I like this answer the best. |
I looked at it the wrong way. @katowulf, I totally agree with your last point. Since there's already that beautiful listener for auth changes, we can depend on that for change detection. The generic service seems redundant since consumer can use So are you suggesting leaving the service as it is (keeping the |
Add the `linkUser` method. FirebaseExtended#764
Add the `linkUser` method. FirebaseExtended#764
Add the `linkUser` method. FirebaseExtended#764
Great, we just spent about one day running in circles while trying to figure out why getRedirectResult wasn't working / wasn't even there. Assumed it was an issue with require-js but as you understand that was a red herring. Ok. We'll throw out the angularfire module and just load firebase directly, it works perfectly and is always up to date with itself. |
Note that even though AngularFire doesn't have these methods implemented just yet, you can always drop down to the vanilla JavaScript library while using AngularFire. You don't have to choose between them and can instead use both in conjunction. |
The support for some new auth methods not found in the angularfire library Is saddening. I have a huge project in angular 1.x.x that need some of the new auth features provided by firebase 3.x.x . Are they ever gonna be implemented? |
Closing as stale. At this point we consider this library complete and are advising remaining developers move to Angular and |
There are a bunch of new authentication methods in the Firebase
3.x.x
SDK which are not found in AngularFire2.x.x
. These include the following:firebase.auth.Auth
applyActionCode()
checkActionCode()
confirmPasswordReset()
fetchProvidersForEmail()
getRedirectResult()
verifyPasswordReset()
firebase.User
getToken()
link()
linkWithPopup()
linkWithRedirect()
reauthenticate()
reload()
sendEmailVerification()
unlink()
updatedProfile()
The only reason we include the existing set of authentication methods is because those are the ones that were around in the Firebase
2.x.x
SDK. Now that we have a bunch of new methods, we should probably include them in the$firebaseAuth
service or else users will have to drop down to the vanilla Firebase SDK half of the time.The counterpoint to adding them is that we end up just re-implementing a bunch of existing functionality in the vanilla SDK. Is there a different approach we can take to handle the
$digest
loop issues that doesn't involve use wrapping every method in the underlying SDK?cc/ @katowulf, @AbeHaskins, @davideast - Thoughts?
The text was updated successfully, but these errors were encountered: