I've come up with an issue using google auth login with a firebase.

When the user logs out i call $unauth() which correctly returns the user to
the login screen and kills the current session.

However when the user then logs in again they are not prompted for a
username and password, it seems the auth session is still cached somewhere
and the user is automatically logged back in using the old credentials.

If the user goes to www.google.com and signs out the login to firebase does
prompt for username & password as expected.

I am unable to see where the session is being persisted, I presume there is
a localStorage or cookie stored somewhere but I cannot see one in a debug
session.

Is this expected behaviour? Is there something else I need to be doing to
entirely kill a users login when using oauth? Also, not sure if this is a
firebase or angularfire issue.

Any advice appreciated!


--
You received this message because you are subscribed to the Google Groups "Firebase + AngularJS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firebase-angular+unsubscribe@googlegroups.com.
To post to this group, send email to firebase-angular@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-angular/260439f9-2125-413f-9e9b-f117999ffa86%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

  • Rob DiMarco at Nov 26, 2014 at 6:43 am
    Hi Phil -

    This is indeed expected behavior. The authentication flow is intended to be
    as frictionless as possible, and it is completely normal that the session
    with the OAuth provider remains active despite the unauth from Firebase.
    Two notes on the topic -

    First, keeping you logged-in to the OAuth provider (Google, Facebook,
    GitHub, Twitter, etc.) was a fundamental design decision that I strongly
    advocated for. In general, we found that users are very surprised - and
    frustrated - when applications attempt to log them out of what they often
    consider to be core services with persistent sessions, especially when
    those services require two-factor authentication. Additionally, it is worth
    noting that I'm not even sure you can consistently due this across all of
    the providers, though there used to be tricks to make it happen for some of
    them on an individual basis. In general, their view, and one that I agree
    with, is that users should be in control of their own sessions, and that
    should means that sessions should only be created or destroyed on the
    domain / app of record.

    Second, we have seen some requests over time for options that ensure some
    OAuth authentication UI is always shown to the user so that steps to
    reauthenticate are not so fast or transparent. Twitter often does this by
    default, and Facebook supports an 'auth_type' which can be set to
    'reauthenticate' and similarly force UI with required user interaction.
    I've been considering how to add something like that in our API, but it
    remains fairly low priority at the moment, and would depend on our ability
    to provide this functionality across all providers.

    Hope that helps, be sure to reach out if you have any other questions.

    Rob
    Engineer @ Firebase


    On Tuesday, November 25, 2014 1:50:07 AM UTC-8, Phil Hodey wrote:

    I've come up with an issue using google auth login with a firebase.

    When the user logs out i call $unauth() which correctly returns the user
    to the login screen and kills the current session.

    However when the user then logs in again they are not prompted for a
    username and password, it seems the auth session is still cached somewhere
    and the user is automatically logged back in using the old credentials.

    If the user goes to www.google.com and signs out the login to firebase
    does prompt for username & password as expected.

    I am unable to see where the session is being persisted, I presume there
    is a localStorage or cookie stored somewhere but I cannot see one in a
    debug session.

    Is this expected behaviour? Is there something else I need to be doing to
    entirely kill a users login when using oauth? Also, not sure if this is a
    firebase or angularfire issue.

    Any advice appreciated!

    --
    You received this message because you are subscribed to the Google Groups "Firebase + AngularJS" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to firebase-angular+unsubscribe@googlegroups.com.
    To post to this group, send email to firebase-angular@googlegroups.com.
    To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-angular/ff7a4988-916d-4117-9efa-aa518ec7faf0%40googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Phil Hodey at Nov 27, 2014 at 11:08 am
    Thanks Rob, this does make sense. Its a general oAuth issue generally where
    I suspect very few users realise that logging out of a third party system
    doesn't necessarily log the user out from the browser.
    On Wednesday, 26 November 2014 06:38:19 UTC, Rob DiMarco wrote:

    Hi Phil -

    This is indeed expected behavior. The authentication flow is intended to
    be as frictionless as possible, and it is completely normal that the
    session with the OAuth provider remains active despite the unauth from
    Firebase. Two notes on the topic -

    First, keeping you logged-in to the OAuth provider (Google, Facebook,
    GitHub, Twitter, etc.) was a fundamental design decision that I strongly
    advocated for. In general, we found that users are very surprised - and
    frustrated - when applications attempt to log them out of what they often
    consider to be core services with persistent sessions, especially when
    those services require two-factor authentication. Additionally, it is worth
    noting that I'm not even sure you can consistently due this across all of
    the providers, though there used to be tricks to make it happen for some of
    them on an individual basis. In general, their view, and one that I agree
    with, is that users should be in control of their own sessions, and that
    should means that sessions should only be created or destroyed on the
    domain / app of record.

    Second, we have seen some requests over time for options that ensure some
    OAuth authentication UI is always shown to the user so that steps to
    reauthenticate are not so fast or transparent. Twitter often does this by
    default, and Facebook supports an 'auth_type' which can be set to
    'reauthenticate' and similarly force UI with required user interaction.
    I've been considering how to add something like that in our API, but it
    remains fairly low priority at the moment, and would depend on our ability
    to provide this functionality across all providers.

    Hope that helps, be sure to reach out if you have any other questions.

    Rob
    Engineer @ Firebase


    On Tuesday, November 25, 2014 1:50:07 AM UTC-8, Phil Hodey wrote:

    I've come up with an issue using google auth login with a firebase.

    When the user logs out i call $unauth() which correctly returns the user
    to the login screen and kills the current session.

    However when the user then logs in again they are not prompted for a
    username and password, it seems the auth session is still cached somewhere
    and the user is automatically logged back in using the old credentials.

    If the user goes to www.google.com and signs out the login to firebase
    does prompt for username & password as expected.

    I am unable to see where the session is being persisted, I presume there
    is a localStorage or cookie stored somewhere but I cannot see one in a
    debug session.

    Is this expected behaviour? Is there something else I need to be doing to
    entirely kill a users login when using oauth? Also, not sure if this is a
    firebase or angularfire issue.

    Any advice appreciated!

    --
    You received this message because you are subscribed to the Google Groups "Firebase + AngularJS" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to firebase-angular+unsubscribe@googlegroups.com.
    To post to this group, send email to firebase-angular@googlegroups.com.
    To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-angular/a432a696-ef10-4e60-8bc8-b851f7abad8b%40googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Paul Harvey at Apr 30, 2015 at 12:14 am
    Is there a way of forcing the user to have to put their username / password
    in again? At the moment I’m testing an app and I have to log out and in as
    different users. It would make my life easier if I could temporarily
    activate this option during testing.
    On Wednesday, 26 November 2014 06:38:19 UTC, Rob DiMarco wrote:

    Hi Phil -

    This is indeed expected behavior. The authentication flow is intended to
    be as frictionless as possible, and it is completely normal that the
    session with the OAuth provider remains active despite the unauth from
    Firebase. Two notes on the topic -

    First, keeping you logged-in to the OAuth provider (Google, Facebook,
    GitHub, Twitter, etc.) was a fundamental design decision that I strongly
    advocated for. In general, we found that users are very surprised - and
    frustrated - when applications attempt to log them out of what they often
    consider to be core services with persistent sessions, especially when
    those services require two-factor authentication. Additionally, it is worth
    noting that I'm not even sure you can consistently due this across all of
    the providers, though there used to be tricks to make it happen for some of
    them on an individual basis. In general, their view, and one that I agree
    with, is that users should be in control of their own sessions, and that
    should means that sessions should only be created or destroyed on the
    domain / app of record.

    Second, we have seen some requests over time for options that ensure some
    OAuth authentication UI is always shown to the user so that steps to
    reauthenticate are not so fast or transparent. Twitter often does this by
    default, and Facebook supports an 'auth_type' which can be set to
    'reauthenticate' and similarly force UI with required user interaction.
    I've been considering how to add something like that in our API, but it
    remains fairly low priority at the moment, and would depend on our ability
    to provide this functionality across all providers.

    Hope that helps, be sure to reach out if you have any other questions.

    Rob
    Engineer @ Firebase


    On Tuesday, November 25, 2014 1:50:07 AM UTC-8, Phil Hodey wrote:

    I've come up with an issue using google auth login with a firebase.

    When the user logs out i call $unauth() which correctly returns the user
    to the login screen and kills the current session.

    However when the user then logs in again they are not prompted for a
    username and password, it seems the auth session is still cached somewhere
    and the user is automatically logged back in using the old credentials.

    If the user goes to www.google.com and signs out the login to firebase
    does prompt for username & password as expected.

    I am unable to see where the session is being persisted, I presume there
    is a localStorage or cookie stored somewhere but I cannot see one in a
    debug session.

    Is this expected behaviour? Is there something else I need to be doing to
    entirely kill a users login when using oauth? Also, not sure if this is a
    firebase or angularfire issue.

    Any advice appreciated!

    --
    You received this message because you are subscribed to the Google Groups "Firebase + AngularJS" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to firebase-angular+unsubscribe@googlegroups.com.
    To post to this group, send email to firebase-angular@googlegroups.com.
    To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-angular/15a6f8db-fef0-4eeb-8dc0-b139a9d54696%40googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Jacob Wenger at Apr 30, 2015 at 6:53 am
    Hey Paul,

    This is intentionally outside the scope of the Firebase authentication
    library. As noted above, $unauth() only ends the current Firebase
    authentication session. If the user is logged into the OAuth provider, then
    you will need to log them out yourself. You can probably do this via the
    OAuth provider's own SDK or clearing your cookies during development. You
    could also see if the provider offers a logout endpoint which you can just
    hit with a REST request. That shouldn't be too hard to shoehorn into your
    app or website.

    Jacob
    On Tue, Apr 28, 2015 at 1:20 PM, Paul Harvey wrote:

    Is there a way of forcing the user to have to put their username /
    password in again? At the moment I’m testing an app and I have to log out
    and in as different users. It would make my life easier if I could
    temporarily activate this option during testing.
    On Wednesday, 26 November 2014 06:38:19 UTC, Rob DiMarco wrote:

    Hi Phil -

    This is indeed expected behavior. The authentication flow is intended to
    be as frictionless as possible, and it is completely normal that the
    session with the OAuth provider remains active despite the unauth from
    Firebase. Two notes on the topic -

    First, keeping you logged-in to the OAuth provider (Google, Facebook,
    GitHub, Twitter, etc.) was a fundamental design decision that I strongly
    advocated for. In general, we found that users are very surprised - and
    frustrated - when applications attempt to log them out of what they often
    consider to be core services with persistent sessions, especially when
    those services require two-factor authentication. Additionally, it is worth
    noting that I'm not even sure you can consistently due this across all of
    the providers, though there used to be tricks to make it happen for some of
    them on an individual basis. In general, their view, and one that I agree
    with, is that users should be in control of their own sessions, and that
    should means that sessions should only be created or destroyed on the
    domain / app of record.

    Second, we have seen some requests over time for options that ensure some
    OAuth authentication UI is always shown to the user so that steps to
    reauthenticate are not so fast or transparent. Twitter often does this by
    default, and Facebook supports an 'auth_type' which can be set to
    'reauthenticate' and similarly force UI with required user interaction.
    I've been considering how to add something like that in our API, but it
    remains fairly low priority at the moment, and would depend on our ability
    to provide this functionality across all providers.

    Hope that helps, be sure to reach out if you have any other questions.

    Rob
    Engineer @ Firebase


    On Tuesday, November 25, 2014 1:50:07 AM UTC-8, Phil Hodey wrote:

    I've come up with an issue using google auth login with a firebase.

    When the user logs out i call $unauth() which correctly returns the user
    to the login screen and kills the current session.

    However when the user then logs in again they are not prompted for a
    username and password, it seems the auth session is still cached somewhere
    and the user is automatically logged back in using the old credentials.

    If the user goes to www.google.com and signs out the login to firebase
    does prompt for username & password as expected.

    I am unable to see where the session is being persisted, I presume there
    is a localStorage or cookie stored somewhere but I cannot see one in a
    debug session.

    Is this expected behaviour? Is there something else I need to be doing
    to entirely kill a users login when using oauth? Also, not sure if this is
    a firebase or angularfire issue.

    Any advice appreciated!


    --
    You received this message because you are subscribed to the Google Groups
    "Firebase + AngularJS" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to firebase-angular+unsubscribe@googlegroups.com.
    To post to this group, send email to firebase-angular@googlegroups.com.
    To view this discussion on the web visit
    https://groups.google.com/d/msgid/firebase-angular/15a6f8db-fef0-4eeb-8dc0-b139a9d54696%40googlegroups.com
    <https://groups.google.com/d/msgid/firebase-angular/15a6f8db-fef0-4eeb-8dc0-b139a9d54696%40googlegroups.com?utm_medium=email&utm_source=footer>
    .

    For more options, visit https://groups.google.com/d/optout.
    --
    You received this message because you are subscribed to the Google Groups "Firebase + AngularJS" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to firebase-angular+unsubscribe@googlegroups.com.
    To post to this group, send email to firebase-angular@googlegroups.com.
    To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-angular/CAGcMwsC7JbomCm78AqQT80v97csgUi-M3NSXz4nKgAdOU6Cj0A%40mail.gmail.com.
    For more options, visit https://groups.google.com/d/optout.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupfirebase-angular @
postedNov 25, '14 at 9:50a
activeApr 30, '15 at 6:53a
posts5
users4

People

Translate

site design / logo © 2021 Grokbase