Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

[Feature request] New UX Flow for email and password signup

See original GitHub issue

Wiki says:

FirebaseUI includes the following flows:

Interaction with Identity Providers such as Google and Facebook Sign-up and sign-in with email accounts . .

I was expecting sing up with email and password button somewhere in the page but I see none. I use the following code same with the example:

<!DOCTYPE html>
<html>
    <head>
        <meta charset="UTF-8">
        <title>Sample FirebaseUI App</title>
        <script src="https://www.gstatic.com/firebasejs/ui/live/0.4/firebase-ui-auth.js"></script>
        <script src="https://www.gstatic.com/firebasejs/3.1.0/firebase.js"></script>

        <link type="text/css" rel="stylesheet" href="https://www.gstatic.com/firebasejs/ui/live/0.4/firebase-ui-auth.css" />
        <script type="text/javascript">
                // FirebaseUI config.

                var config = {
                    apiKey: "****",
                    authDomain: "****",
                    databaseURL: "****",
                    storageBucket: "****",
                };
                firebase.initializeApp(config);

                var uiConfig = {
                    // Query parameter name for mode.
                    'queryParameterForWidgetMode': 'mode',
                    // Query parameter name for sign in success url.
                    'queryParameterForSignInSuccessUrl': 'signInSuccessUrl',
                    'signInSuccessUrl': 'http://local.host:9000/',
                    'signInOptions': [
                        // Leave the lines as is for the providers you want to offer your users.
                        firebase.auth.EmailAuthProvider.PROVIDER_ID,
                        firebase.auth.GoogleAuthProvider.PROVIDER_ID,
                        firebase.auth.FacebookAuthProvider.PROVIDER_ID,
                        firebase.auth.TwitterAuthProvider.PROVIDER_ID,
                    ],
                    // Terms of service url.
                    'tosUrl': '<your-tos-url>',
                    'callbacks': {
                        'signInSuccess': function(currentUser, credential, redirectUrl) {
                            // Do something.
                            // Return type determines whether we continue the redirect automatically
                            // or whether we leave that to developer to handle.
                            return true;
                        }
                    }
                };

                var ui = new firebaseui.auth.AuthUI(firebase.auth());
                // The start method will wait until the DOM is loaded.
                ui.start('#firebaseui-auth-container', uiConfig);
        </script>
    </head>

    <body>
            <!-- The surrounding HTML is left untouched by FirebaseUI.
         Your app may use that space for branding, controls and other customizations.-->
        <h1>Welcome to My Awesome App</h1>
        <div id="firebaseui-auth-container"></div>
    </body>
</html>

Issue Analytics

State:
Created 7 years ago
Reactions:2
Comments:6 (2 by maintainers)

Top GitHub Comments

6reactions

araknafobiacommented, Aug 13, 2016

@bojeil-google thank you for you quick and clear answer. I think it should be documented on wiki.

Also, It is a bit out of context but do not you think that it is a bad user experience? I mean, I know how things work on the Internet more than an average user and I could not think the way it works.

You are Google and what you do is always ‘per-calculated’ in many perspectives but I just wonder that you do really think that it is the way how it should be.

Note: It is me @endertunc. Mixing the accounts 😦

1reaction

bojeil-googlecommented, Jul 19, 2017

Hey @siegerts and others, we have a bunch of features in the request pipeline that are higher priority. At the moment, I don’t see this as blocking. There are many ways the flow can be tweaked or customized. This is one of many. It is hard to accommodate every one of them. Our UX designers recommended our current flow during the design stage. I will relay this request and your supporting arguments to the relevant parties and update this thread on this.