Feature Request – Ask for code on second page

Hi
I don’t think it’s possible to break up the loginflow in WordPress, but I may be wrong, I’ll do some reading on the subject.

I don’t think remembering devices is a good idea, I think it’s safe to say most WordPress installations run non-SSL, so any cookies giving special rights to one computer could easily become special rights on other computers.

Best regards
Henrik Schack

Funny, I’ve actually been thinking about doing SSL on my admin pages.. But I agree, the vast majority of WP installs will be non-SSL.

Maybe it can be a combination of cookie & IP address? And perhaps it could be a global plugin option to enable/disable that functionality?

As for breaking up the login flow, you’d probably have to get some redirection functionality in place, to intercept successful logons and then either ask for an authenticator code (or let them automatically bypass if they’re on a remembered device).

If you’re able to crack both of these, it’ll take the plugin to a whole new level of usability! ??

Thanks again,
Andrew

This is how WordPress.com does it. So you might be able to get some ideas from there, although I don’t know how customised WordPress.com is vs www.ads-software.com

WordPress.com can modify the core files, I can’t
But if you have any ideas on how to make it work with a plugin, please let me know.

Best regards
Henrik Schack

I second, asking for the code on a second page if one is needed for the user.

@henrik – Perhaps there’s some logic or code you could utilize from this plugin?

https://www.ads-software.com/extend/plugins/peters-login-redirect/

Or maybe there’s something useful in here?

https://itswordpress.com/tips-tricks/redirecting-wordpress-users-after-login/

Thanks!

– Andrew

what about something like this:

in check_otp see if user has google authenticator activated
if so check if user POSTed token and verify if he did
and log in with the username from session and unset the saved username from session
else remove the default wordpress login action,
replace the login fields with token field
and store username (or whatever is needed to log the user in later) in a session

i’ll try to get together an at least halfway working example as soon as possible

okay, here are some actions and filters that should really help implementing something like this

filter login_redirect
check if global $user is valid and if he has activated google authenticator return url to wp-login.php?action=go (whicht triggers login_form_go action; also log the user back out and save info for later)

action login_form_go
verify post if exists and redirect or echo form (see wp-login.php for code example) and exit at the end to prevent duplicate due to switch statement after do_action in wp-login.php

and this is what i got so far

function loginredirect($url) {
    global $user;
    if ( !is_wp_error($user) && isset($_POST['log'], $_POST['pwd']) && trim(get_user_option( 'googleauthenticator_enabled', $user->ID ) ) == 'enabled' ) {
        wp_logout();
        session_start();
        $_SESSION['cred'] = array(
            'log' => $_POST['log'],
            'pwd' => $_POST['pwd'],
            'rememberme' => $_POST['rememberme']
        );
        wp_safe_redirect( wp_login_url() . '?action=go' );
        exit();
    }
    return $url;
}

function loginform_go() {
    session_start();
    var_dump($_SESSION['cred']);
    exit();
}

and this in init

add_filter('login_redirect', array( $this, 'loginredirect' ) );
    add_action('login_form_go', array( $this, 'loginform_go' ) );

    #add_action( 'login_form', array( $this, 'loginform' ) );
    #add_action( 'login_footer', array( $this, 'loginfooter' ) );
    #add_filter( 'authenticate', array( $this, 'check_otp' ), 50, 3 );

it disables google authenticator for now, but now almost the only thing left is copying the ‘login’ case statement and changing the fields (either write the credentials to hidden fields or leave them in session and pass to wp_signon

+1 for a second page for authentication.

I’m running a multisite so everyone has its own blog. I activate this plugin site widely to make sure my users know it has two-factor authentication support.

But only some of them will use it, so I think the auth form should be disabled from the login page by default, and then show up for users who enable it in a second auth page is good idea.

I also see some other plugins uses this way: https://www.ads-software.com/extend/plugins/im-login-dongle/screenshots/

Thanks.

I would love to see this implemented too.

It is what is preventing us from using this plugin on our WordPress multisite installations.

We’d like to have some user accounts using Multi Factor authentication, and all other users shouldn’t see the third field on the login screen.

The way WordPress.com implements this is great.

okay,
i don’t really know if it’s the best solution, but it works and i wouldn’t know any other way to achieve this

google-authenticator.zip

i didn’t test if it passes through users who don’t have google authenticator enabled, but in theory that’s what should happen^^

it would be awesome if Hendrik could merge it into the plugin,
until then you could use the version above

i just fixed the bug that showed an empty error field, so here it is:

google-authenticator.zip

Rather than a second page, I would like to see something in the form of AJAX – when the username field is ‘blured’, run an AJAX call to see if that username requires OTP and if so, show the OTP box.

@slammeddime, a big reason for the second page is to duplicate the functionality of WordPress.com on the basis that they’ve done some usability studies on the best way to implement it.

I like the AJAX solution, since it doesn’t mess with the loginflow I supposed it would be much more likely not to break because of WordPress updates.