Re: [Firebase] Best way for 'Logout'?

[Michael "Kato" Wulf]

If you want no warnings then you'll need to track every on/once function and then call off on them before you unauth.

Some other ideas you might consider would be to a) reload the page after unauth or b) direct user to a new page telling them they have been logged out and where to go from there or c) ignore the warnings since they are perfectly reasonable and expected.

On Thu, Apr 4, 2013 at 8:50 PM, Alon <alon....@gmail.com> wrote:

Hi,

This is a question about best practice.

Assuming I'm managing the login/logout, when the user log out, I don't want to raise any more on/once events. I'm using an authentication token and on the logout procedure I call ref.unauth().

Is that the right way? (I'm getting warnings such as "FIREBASE WARNING: on() or once() for /abc/edf failed: permission_denied " for every listener I've set. I've seen on another thread that after these warning the FB will dispose the listeners (that is the desired behavior for me).

Or should I call off() for every on() I've set? (complicates severely the things for me. BTW, a proposal - can you add a method that will return all open listeners? I think  it can help, especially on cases where one should track and call off() on some listeners that were created dynamically).

And while here, if I will use the FB simple login, will the "authClient.logout()" do the work in a better way? (no warnings).

Thanks.

--
You received this message because you are subscribed to the Google Groups "Firebase Google Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firebase-tal...@googlegroups.com.
To post to this group, send email to fireba...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--

Michael Wulf
www.wordspot.org

[Michael Lehenbauer]

A couple additional notes:

1. You can do "ref.off()" without any arguments and we'll remove all listeners for that location.  So if you know everywhere you're listening, that might not be too bad.
2. We've been talking about adding a ref.offRecursive() or similar that would recursively do .off(), so it'd remove all listeners at that location and all deeper locations.  This came up explicitly because of your use case (wanting to remove all listeners when logging out).

That said, the warnings are harmless and we do automatically remove the listeners for you.

-Michael

[Michael Lehenbauer]

refs will only be canceled if you lose permission to read them when you log out, so if there aren't security rules that prevent anonymous access, they won't be canceled.

We have some ideas for features to make this easier (like the offRecursive() thing I mentioned), but right now the only way to remove them is to call .off(), so you'll have to track the refs you're listening on if you need to remove them.

-Michael

On Wed, Apr 17, 2013 at 11:53 AM, Alon <alon....@gmail.com> wrote:

Hi,

Apparently not all references are being cancelled upon unauth. Any idea why and how to force them? I have some processes in those refs that damage the overall behavior when activated while logged out...

comments:

1. It's a Phonegap app so I'm not sure how to refresh as suggested above or if it's even a good idea...

2. It will be complicated to track all dynamic opened refs in order to close them...

thanks.

On Tuesday, April 9, 2013 1:37:37 PM UTC-5, Alon wrote:

Thanks Michael and Michael. These Google Groups make me crazy - I'm not getting notifications on replies to my posts even though the option is checked!!

To the point, Michael Lehenbauer -  I like very much your 2nd suggestion. For the mean time I will live with the warnings. Please do let know once the feature is available.

Thanks.

[Michael Lehenbauer]

Hrm.  Then yeah, I'd expect all of your callbacks to be canceled.  I'll follow up off-list.

On Wed, Apr 17, 2013 at 12:11 PM, Alon <alon....@gmail.com> wrote:

That's clear but I do have very 'generic' rules that should catch such unauth:

{

  "rules": {

    ".read": "auth != null",

    ".write": "auth != null"

  }

}

besides, other refs do become cancelled (or actually unauthorized - "permission_denied")