Hello,

First, thanks for the amazing work you've done.
I've installed wp-cli-login as well as the server plugin the recommended way but it looks like it's not the latest version (I get the "Unknown --redirect-url parameter" error message when using that parameter)
Please could you advise on how I can get it done ?
Thanks in advance !

Hi, is it possible to create a flag for the install command so that instead of always putting the file in plugins we have an option to use mu-plugins instead?

Current:

wp-content/plugins/wp-cli-login-server/wp-cli-login-server.php

Preferred:

wp-content/mu-plugins/wp-cli-login-server.php

Cheers!

Thanks for this great package!

I've found that it fails when CiviCRM is installed on a site. I tracked it down to this line, which checks that the $_GET supervariable is empty. CiviCRM sets an element in that array on every page load.

What is the use case that this line is trying to prevent? Is it necessary, or can I submit a PR to remove it?

We've implemented wp-cli-login-command on several hundred sites to test and for most its great! But we are seeing also a fair amount of cases where the generated link brings you to a 404 page, we are unable to determine the cause, some of the sites are just fresh installs of WordPress.

Running the latest package:

# wp package install aaemnnosttv/wp-cli-login-command
Installing package aaemnnosttv/wp-cli-login-command (dev-main || dev-master || dev-trunk)
Updating /root/.wp-cli/packages/composer.json to require the package...
Using Composer to install the package...
---
Loading composer repositories with package information
Found 146 package versions referenced in your dependency graph. 31 (21%) were optimized away.
Updating dependencies
Generating rules
Resolving dependencies through SAT
Looking at all rules.
Something's changed, looking at all rules again (pass #1)

Dependency resolution completed in 0.000 seconds
Analyzed 115 packages to resolve dependencies
Analyzed 119 rules to resolve dependencies
Nothing to modify in lock file
Installing dependencies from lock file
Nothing to install, update or remove
Generating autoload files
1 package you are using is looking for funding.
Use the `composer fund` command to find out more!
---
Success: Package installed.

# wp login install --mu --yes
Success: Companion plugin installed.

# wp login create bigscoots
Success: Magic login link created!
-----------------------------------------------------------------
https://SOMEDOMAIN.com/3bfa7aec/0d6f91-07fe7213-ab178ce1
-----------------------------------------------------------------

# curl -IL https://SOMEDOMAIN.com/3bfa7aec/0d6f91-07fe7213-ab178ce1
HTTP/1.1 404 Not Found

WP Core 5.9.3

Temp disabled all plugins and set to a default twentytwentytwo

Outside of trying to rule out problematic themes/plugins what other ways do we have to troubleshoot whats causing these 404s. The sites affected are completely random, it could be one site out of 10 on the same server using same configurations.

Just looking to get some possibilities / ideas on how to troubleshoot this further, thanks!

Hi there!

I'm attempting to install the server plugin via Composer using Composer v2.

Currently, the plugin can only be installed by Composer v1 due to its version dependency on composer/installers.

I've made a basic change that allows the plugin to be installed by either Composer version thunderdw/wp-cli-login-command@1bd5699

If it would be welcome I'm happy to submit a PR

Hey guys, I'm planning to start on v2 of the login command here pretty soon.

I've got a few ideas for it, and any feedback or requests are welcome :)

• Move all core functionality to the server plugin (no interface). This should make things a bit simpler implementation-wise and the CLI will be more of a "client" for using the plugin. This will also allow for programmatic creation of logins via your own plugin 🎉
• Move magic login data to a custom table to allow for some new features that aren't possible with the current transient-based persistence.
• Probably rewrite a bunch of stuff.
• GitHub Updater?
• Punch & pie.

Hello,

First of all, congratulations on the great tool - I have always been looking for something similar. I installed the package and here is my wp-cli info:

:~/nickola# wp --info

PHP binary: /usr/bin/php7.0
PHP version: 7.0.14-1+deb.sury.org~xenial+1
php.ini used: /etc/php/7.0/cli/php.ini
WP-CLI root dir: phar://wp-cli.phar
WP-CLI packages dir: /root/.wp-cli/packages/
WP-CLI global config:
WP-CLI project config:
WP-CLI version: 1.0.0

I already have an existing WordPress installation that I wanted to test with and I have issued the following command:

:~/nickola# wp login create 1 --path=/path/to/existing/wp/install/

Success: Magic login link created!

-----------------------------------------------------------
http://xyzasdqwerty.com/410b1ba7/063a9c9809-c7f6d8-e68584
-----------------------------------------------------------
This link will self-destruct in 15 minutes, or as soon as it is used; whichever comes first.

I have made sure that the accompanying WordPress plugin is enabled. Regardless of this, following the link sends me to 404. This happens on a vanilla WordPress installation, standard LAMP stack on Linode, running on Ubuntu and PHP7.

Mod_rewrite is enabled on the server, if that matters, and the default WordPress .htaccess rules are in place.

Can you please suggest how can I resolve this problem.

Thanks!

Nickola

Hi there! I had a fairly fun issue earlier related to the wp_options table being crashed which resulted in the set_transient function returning false, which then resulted in a BadMagic exception with a less than useful error message given the circumstances.

I've made a very basic change to just check if set_transient returns false: brucedevcom@9c72ddf

Assuming there's no issues with this are there any objections to submitting a PR for it?

When I try to pass a url using the --url flag it doesn't seem to make any difference.

$ wp --version
WP-CLI 0.24.1

$ wp core version
4.6.1

$ php --version
PHP 7.0.12-1+deb.sury.org~trusty+1 (cli) ( NTS )

Since upgrade to WP 4.7, whenever i issue a wp login create username , i get a link and when we paste it in it comes up with the message like the link has been used. Look thur error logs did not find anything. Any clues?
Thanks.
Note: upgraded both server and client side packages to today's latest versions of wp-cli-login

Current sub-commands that are server plugin-specific should be moved under a new server subcommand.

This currently includes:

• install
• toggle

Hello~

When I run 'wp login xxx', and It said syntax error, unexpected 'class' of aaemnnosttv/wp-cli-login-command/command.php on line 11. My wp cli version is latest. Did I do something wrong?

Thanks for answering further. <3

I'm seeing white screen "critical error has been encountered" errors when using the magic link to attempt to login to sites with 2FA enabled.

Testing with ithemes security plugin (now solidwp security with the recent rebrand) with 2fa enabled for admins.

I did try with the melapress one as well and got a similar error.

Not sure that this is something that can be resolved but since I didn't see it mentioned in the issues list yet I figured I'd add it.

The current version constraint does not allow for installing on PHP 8.

This will be rather trivial after #41 and depends on this to happen first.

See aaemnnosttv/wp-cli-dotenv-command#25

We have tried to reach you through several means.

Please tell us how to reach out to you for responsible disclosure or contact us at [email protected]

Currently, login links redirect you to the admin dashboard upon successfully logging in.

However, it is sometimes known ahead of time that redirecting to another URL instead would be preferable or more direct.

To accommodate this, a new option such as --redirect=<url> option should be added to the login create command. This redirect should be stored internally and wouldn't be part of the generated link itself so it would not be changeable once created.

Seems the plugin server unnecessarily tests "wp-login.php" request.
Appending "|| is_login()" in is_eligible_request() return should solve it.

Much of the bundled Behat infrastructure has been extracted into the core wp-cli-tests package which is also extendable making the duplicate code here unnecessary.

I like this package a lot. But the question is if it is safe in the production env?

This plugin is working well for me but I noticed that the wp login command may take between one to ten seconds to complete.

This is on a site that is generally responsive and working well (navigating to any /wp-admin/ dashboard page in a second or two). Is there something that could be optimized within login-command or WPCLI to make it less slow?

The wp-cli.org Package Index has an out of date version. I noticed this since the --redirect-url option is absent.

Seems the plugin version ensure check doesnt look at the mu-plugin path.

https://github.com/aaemnnosttv/wp-cli-login-command/blob/master/src/LoginCommand.php#L471

Suggestion adding plugin to wpackagist?

Hi,

We have 2 websites running themes built with unyson framework, when we use the sso login,we get redirected to unyson website not our website.

Problem

I'd like to install the server plugin via Composer as a mu-plugin. I'm doing that by modifying the installer path for the server plugin in my composer.json, like so:

"installer-paths": {
    "path/to/mu-plugins/{$name}/": [
        "type:wordpress-muplugin",
        "aaemnnosttv/wp-cli-login-server",
    ],

This results in a server plugin PHP file installed inside a subdirectory of the mu-plugins folder located at mu-plugins/wp-cli-login-server/wp-cli-login-server.php.

However, the command only checks for the mu-plugin PHP file at mu-plugins/wp-cli-login-server.php.

Since the command is unable to locate that file, it assumes that the plugin is installed as a normal plugin. So when you attempt to execute a command like wp login as 1, the command fails and you get an error like file_get_contents(/path/to/plugins/wp-cli-login-server/wp-cli-login-server.php): Failed to open stream: No such file or directory

This error happens instead of a message that the server plugin isn't installed because the command doesn't test for the location of the server plugin, but rather the existence of the WP_CLI_Login\WP_CLI_Login_Server class.

Potential fixes

• Alter the mustUse() function above to look for the server plugin in both mu-plugins/wp-cli-login-server.php and mu-plugins/wp-cli-login-server/wp-cli-login-server.php
• Instead of using constants to define the potential locations of the server plugin, use Reflection to get the location of the server plugin. E.g. (new \ReflectionClass(WP_CLI_Login_Server::class))->getFileName(). IMO this approach is more flexible and better aligns with the isActive() test linked above

Happy to submit a PR if this makes sense

Hello,
Thanks for your awesome work !
However, the magic link URL is not working properly because we have an apache rewriterule adding a trailing slash, then it leads to a 404.
Do you have any idea about how we could mitigate this issue ?
Maybe we could change the source code in order to add a trailing slash to your magic link URL ?
Thanks in advance for your help !

Arthur

Creating a login link results in the following notice

Notice: Undefined index: redirect-url in /.../.wp-cli/packages/vendor/aaemnnosttv/wp-cli-login-command/src/LoginCommand.php on line 69

Environment

OS:	Linux 4.4.0-189-generic #219-Ubuntu SMP Tue Aug 11 12:26:50 UTC 2020 x86_64
Shell:	/bin/bash
PHP binary:	/opt/sp/php7.1/bin/php
PHP version:	7.1.33
php.ini used:	/etc/php7.1-sp/php.ini
WP-CLI root dir:	phar://wp-cli.phar/vendor/wp-cli/wp-cli
WP-CLI vendor dir:	phar://wp-cli.phar/vendor
WP_CLI phar path:	/srv/users/userc6e6b04e
WP-CLI packages dir:	/srv/users/userc6e6b04e/.wp-cli/packages/
WP-CLI global config:	
WP-CLI project config:	/srv/users/userc6e6b04e/wp-cli.yml
WP-CLI version:	2.4.0

+----------------------------------+--------------+---------+--------+----------------+
| name                             | authors      | version | update | update_version |
+----------------------------------+--------------+---------+--------+----------------+
| aaemnnosttv/wp-cli-login-command | Evan Mattson | v1.4.0  | none   |                |
+----------------------------------+--------------+---------+--------+----------------+

To prevent accidental deletion of the companion plugin, it would be nice to be able to place it inside "mu-plugins" folder. I tried manually moving it there, but it's not being recognized and WP-CLI asks for companion plugin to be installed.

Maybe simply passing --mu to let WP-CLI know where to look for companion plugin.

Thanks!

I think it would be great to have the means to change the way the links work. I.E: Having a link under a random (obviously user configurable) location and things like that would strengthen the plugin's security.

Hello.

What a great plugin this is!
It would have been nice to be able to translate the email, especially the subject field.
Probably not necessary for the mustache template, huh?

So I've got a bunch of commands that are run via ssh/paramiko on some WP Engine sites.

If I run: cd ~/sites/mysite/; wp login create [email protected] --url-only --redirect-url=/wp-admin/admin.php?page=theme-base-theme-settings directly from ssh it'll generate a usable url, but for some reasons when I run the command via my paramiko script it'll generate a url that displays The attempted magic login has expired or already been used. - the commands are exactly the same. There's a bunch of vanilla and custom wp cli commands that run fine via paramiko so it's not a universal issue.

Really weird, I assume it's some quirk with how paramiko works, but just wondering if you have any idea what could be happening?

Login to WordPress with secure passwordless links.

should be:

Log in to WordPress with secure passwordless links.

If "WP_CLI" is not defined in wp-cli-login-server.php ( not called from wp_cli ) then the line (defined('WP_CLI') && WP_CLI) is trying to use undefined WP_CLI constant or I'm missing something obvious?

Would be very useful for administrators being able to review the requests that were handled by the plugin class, i.e. in order to being able to setup rules for user-agents (like I've suggested to ignoring user-agents like Slack/Telegram/Whatsapp/etc.), check IPs, users that used their links, etc.

If the login is dumped to a file, recording the status of the request (authorized/already used/expired), would allow to check with tools like fail2ban, if an IP is trying to abuse the link/login mechanism, thus blocking it.

Some apps which try to load previews of the url you are sharing (eg: Slack) will "break" the link when sharing because the preview triggers the login which will only work once.

I have some client sites where no matter the wp-cli command it will output the same wp login link

As in wp-cli will only output a link from this package, no matter what.

I think it would be great to have the means to be able to configure the magic link timeout. Maybe via wp-cli.yml or via a command attribute ?

Composer 2 requires senver ^3.0 but this plugin requires ^1.0

Not sure if it works with latest version of semver or not but to make it install with all versions

(^1.4 || ^2 || ^3)

Would fix it, this is what is happening in wp-cli/core-command

Cheers Dan

Hey, can't get any link to work. Where do I start to troubleshoot?

Seems when using buddyboss-platform there is a conflict with one of their functions

PHP Fatal error:  Uncaught TypeError: call_user_func_array(): Argument #1 ($callback) must be a valid callback, function "bp_member_switching_clear_olduser_cookie" not found or invalid function name in /home/nginx/domains/domain.com/public/wp-includes/class-wp-hook.php:312
Stack trace:
#0 /home/nginx/domains/domain.com/public/wp-includes/class-wp-hook.php(334): WP_Hook->apply_filters()
#1 /home/nginx/domains/domain.com/public/wp-includes/plugin.php(517): WP_Hook->do_action()
#2 /home/nginx/domains/domain.com/public/wp-content/mu-plugins/wp-cli-login-server.php(226): do_action()
#3 /home/nginx/domains/domain.com/public/wp-content/mu-plugins/wp-cli-login-server.php(136): WP_CLI_Login\WP_CLI_Login_Server->loginUser()
#4 /home/nginx/domains/domain.com/public/wp-content/mu-plugins/wp-cli-login-server.php(110): WP_CLI_Login\WP_CLI_Login_Server->run()
#5 /home/nginx/domains/domain.com/public/wp-content/mu-plugins/wp-cli-login-server.php(23): WP_CLI_Login\WP_CLI_Login_Server::handle()
#6 /home/nginx/domains/domain.com/public/wp-includes/class-wp-hook.php(310): WP_CLI_Login\init_server_from_request()
#7 /home/nginx/domains/domain.com/public/wp-includes/class-wp-hook.php(334): WP_Hook->apply_filters()
#8 /home/nginx/domains/domain.com/public/wp-includes/plugin.php(517): WP_Hook->do_action()
#9 /home/nginx/domains/domain.com/public/wp-settings.php(495): do_action()
#10 /home/nginx/domains/domain.com/public/wp-config.php(119): require_once('...')
#11 /home/nginx/domains/domain.com/public/wp-load.php(50): require_once('...')
#12 /home/nginx/domains/domain.com/public/wp-blog-header.php(13): require_once('...')
#13 /home/nginx/domains/domain.com/public/index.php(17): require('...')
#14 {main}
  thrown in /home/nginx/domains/domain.com/public/wp-includes/class-wp-hook.php on line 312

Files:

buddyboss-platform/bp-members/bp-members-functions.php

Function:

function bp_member_switching_clear_olduser_cookie( $clear_all = true ) {
        $auth_cookie = bp_member_switching_get_auth_cookie();
        if ( ! empty( $auth_cookie ) ) {
                array_pop( $auth_cookie );
        }
        if ( $clear_all || empty( $auth_cookie ) ) {

                /** This filter is documented in wp-includes/pluggable.php */
                if ( ! apply_filters( 'send_auth_cookies', true ) ) {
                        return;
                }

                $expire = time() - 31536000;
                setcookie( BP_MEMBER_SWITCHING_COOKIE, ' ', $expire, SITECOOKIEPATH, COOKIE_DOMAIN );
                setcookie( BP_MEMBER_SWITCHING_SECURE_COOKIE, ' ', $expire, SITECOOKIEPATH, COOKIE_DOMAIN );
                setcookie( BP_MEMBER_SWITCHING_OLDUSER_COOKIE, ' ', $expire, COOKIEPATH, COOKIE_DOMAIN );
        } else {
                if ( BP_Core_Members_Switching::secure_auth_cookie() ) {
                        $scheme = 'secure_auth';
                } else {
                        $scheme = 'auth';
                }

                $old_cookie = end( $auth_cookie );

                $old_user_id = wp_validate_auth_cookie( $old_cookie, $scheme );
                if ( $old_user_id ) {
                        $parts = wp_parse_auth_cookie( $old_cookie, $scheme );
                        bp_member_switching_set_olduser_cookie( $old_user_id, true, $parts['token'] );
                }
        }
}

WP Engine prevent the installation of WP CLI packages via their CLI, so I've been unable to install this package.

GF Forms have a cli offering that can be installed as a plugin: https://github.com/gravityforms/gravityformscli

I'm just wondering if there's a way to install this without running wp package install aaemnnosttv/wp-cli-login-command e.g. via a plugin like the above?

Does there happen to be a way to configure the --launch browser? Right now, it attempts to use xdg-open to launch www-browser on my Windows 10's Linux Subsystem but I'd rather it just use firefox.exe or detect an environment variable of what my default browser executable is.

Error: /usr/bin/xdg-open: 771: /usr/bin/xdg-open: www-browser: not found
/usr/bin/xdg-open: 771: /usr/bin/xdg-open: links2: not found
/usr/bin/xdg-open: 771: /usr/bin/xdg-open: elinks: not found
/usr/bin/xdg-open: 771: /usr/bin/xdg-open: links: not found
/usr/bin/xdg-open: 771: /usr/bin/xdg-open: lynx: not found
/usr/bin/xdg-open: 771: /usr/bin/xdg-open: w3m: not found

Getting this

Magic login authentication failed.

I have uninstalled and reinstalled the plugin.

The site is a clone of another site on another server that is working fine. I have uninstalled the plugin, cleared wp-cli cache, reinstalled the plugin, and still getting this.

We use the plugin for SSO from our SaaS dashboard.

Any ideas?

When installing and activating the server plugin in a multisite environment using the suggested command (wp login install --activate) you may be surprised that it will error as inactive when attempting to use to log-in to a sub site.

The activation should either network-activate automatically or require an additional flag, similar to plugin activate.

It seems when the plugin is installed to mu-plugins, the toggle on/off can't find the plugin

Hello,

At the moment it does not allow for multisite capability, and only determines based on the primary site.

Can it be possible to implement multisite capability in the next release?

Kind regards,
Michael

When developing locally, it's a common practice to pull down a fresh copy of the production MySQL database before beginning any new work.

For instance, the production site may be example.com, but the local environment may be setup to use example.dev, as overridden in wp-config.php:

define( 'WP_HOME',    'http://' . $_SERVER['HTTP_HOST'] );
define( 'WP_SITEURL', 'http://' . $_SERVER['HTTP_HOST'] );

Since it's not always feasible or possible to use a tool like WP Migrate DB Pro or WP-CLI Search & Replace, so often times the wp_options table will still have the production values for siteurl or home:

Why does this matter?

By default WP-CLI Login Command uses the value in the database, so when working locally and running a command like wp login as zerocool --launch will return a Magic Login Link similar to:

http://example.com/c39808ec/47c4db-7dc7d05a4d-40b4b4a036

Instead, what is desired is for WP-CLI Login Command to use the local WordPress Site URL, not what is necessarily in the database, such as:

http://example.dev/c39808ec/47c4db-7dc7d05a4d-40b4b4a036

It appears \WP_CLI_Login\LoginCommand::domain() is responsible for determining the URL used for the login links:

 return parse_url(home_url(), PHP_URL_HOST);

While it’s possible to use the home_url() filter to alter this behavior, it would desirable for WP-CLI Login Command to handle this logic ”magically”, so the package and companion plugin could be installed and used with zero configuration.

I receive the following errors when using the magic login link (created with wp login create <user>):

Notice: is_embed was called incorrectly. Conditional query tags do not work before the query is run. Before then, they always return false. Please see Debugging in WordPress for more information. (This message was added in version 3.1.0.) in /app/web/wp/wp-includes/functions.php on line 5535

Notice: is_search was called incorrectly. Conditional query tags do not work before the query is run. Before then, they always return false. Please see Debugging in WordPress for more information. (This message was added in version 3.1.0.) in /app/web/wp/wp-includes/functions.php on line 5535

Magic login authentication failed.

I’m installing the WP CLI package at 6ee4b91 (installed using GitHub URL instead of the package name so I can use the latest) and using dev-master for installing the plugin through Bedrock.

I’m using WordPress 5.8 with Bedrock 1.16.1 running on PHP 7.4.16, MySQL 5.7, and Nginx 1.17 via Lando 3.1.4 (Landofile below).

name: bedrock
recipe: wordpress
config:
  webroot: web
  via: nginx
  php: '7.4'
services:
  appserver:
    run:
      - composer install
      - wp package install https://github.com/aaemnnosttv/wp-cli-login-command.git
      - wp core install --url=https://bedrock.lndo.site --title=Bedrock --admin_user=admin --admin_password=admin [email protected] --skip-email
      - wp plugin activate wp-cli-login-server

{
  "name": "roots/bedrock",
  "type": "project",
  "license": "MIT",
  "description": "WordPress boilerplate with modern development tools, easier configuration, and an improved folder structure",
  "homepage": "https://roots.io/bedrock/",
  "authors": [
    {
      "name": "Scott Walkinshaw",
      "email": "[email protected]",
      "homepage": "https://github.com/swalkinshaw"
    },
    {
      "name": "Ben Word",
      "email": "[email protected]",
      "homepage": "https://github.com/retlehs"
    }
  ],
  "keywords": [
    "bedrock", "composer", "roots", "wordpress", "wp", "wp-config"
  ],
  "support": {
    "issues": "https://github.com/roots/bedrock/issues",
    "forum": "https://discourse.roots.io/category/bedrock"
  },
  "repositories": [
    {
      "type": "composer",
      "url": "https://wpackagist.org",
      "only": ["wpackagist-plugin/*", "wpackagist-theme/*"]
    }
  ],
  "require": {
    "php": ">=7.1",
    "composer/installers": "^1.11",
    "vlucas/phpdotenv": "^5.3",
    "oscarotero/env": "^2.1",
    "roots/bedrock-autoloader": "^1.0",
    "roots/bedrock-disallow-indexing": "^2.0",
    "roots/wordpress": "5.8",
    "roots/wp-config": "1.0.0",
    "roots/wp-password-bcrypt": "1.0.0"
  },
  "require-dev": {
    "squizlabs/php_codesniffer": "^3.6.0",
    "roave/security-advisories": "dev-master",
    "aaemnnosttv/wp-cli-login-server": "dev-master"
  },
  "config": {
    "optimize-autoloader": true,
    "preferred-install": "dist"
  },
  "minimum-stability": "dev",
  "prefer-stable": true,
  "extra": {
    "installer-paths": {
      "web/app/mu-plugins/{$name}/": ["type:wordpress-muplugin"],
      "web/app/plugins/{$name}/": ["type:wordpress-plugin"],
      "web/app/themes/{$name}/": ["type:wordpress-theme"]
    },
    "wordpress-install-dir": "web/wp"
  },
  "scripts": {
    "post-root-package-install": [
      "php -r \"copy('.env.example', '.env');\""
    ],
    "test": [
      "phpcs"
    ]
  }
}

When I use the plugin locally i get a 404 error. I'm using mamp.
This was the link i got: http://dev.timber.nl/30734387/26320bcd-3f52ed-c3bc9df0

Thanks! Love the plugin