entity-command
entity-command copied to clipboard
session tokens not always shown
Bug Report
- [x] Yes, I reviewed the contribution guidelines.
- [x] Yes, more specifically, I reviewed the guidelines on how to write clear bug reports.
Describe the current, buggy behavior
A clear and concise description of the behavior that produces a wrong result or error.
Remember to provide some context to make sure we're all on the same page when reasoning about this.
Describe how other contributors can replicate this bug
- run
php ../wp-cli.phar user session list 1 - run
php ../wp-cli.phar db query 'SELECT * FROM wp_usermeta where meta_value LIKE "%1a.b.c.d%"'
Describe what you would expect as the correct outcome
The user session list 1 command should show the session_token entries, like the db query one does. There seems to be some issue, at least the command does not output any sessions, even if there are session_tokens entries.
Let us know what environment you are running this on
OS: Linux 4.19.0-17-amd64 #1 SMP Debian 4.19.194-1 (2021-06-10) x86_64
Shell: /bin/bash
PHP binary: /usr/bin/php74.wrp.cli
PHP version: 7.4.20
php.ini used: /home/httpd/php74-ini/xxxx/php.ini
MySQL binary: /usr/bin/mysql
MySQL version: mysql Ver 14.14 Distrib 5.7.34, for Linux (x86_64) using EditLine wrapper
SQL modes:
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: /usr/www/users/xxx/redacted
WP-CLI packages dir: /usr/home/xxx/.wp-cli/packages/
WP-CLI global config:
WP-CLI project config:
WP-CLI version: 2.5.0
Provide additional context/Screenshots
Thanks for the report, @DanielRuf !
Were you able to track the problem down further?
Oh ok, so you close issues when there is no response after a while? Sorry, had other more important things to do.
Can you reproduce it locally?
Oh ok, so you close issues when there is no response after a while?
Correct. Our expectation is that a bug is reproducible in a generic WordPress environment.
Can you reproduce it locally?
No:
$ wp user session list 1
+-------------------------------------------+---------------------+---------------------+-----------+------------------------------------------------+
| token | login_time | expiration_time | ip | ua |
+-------------------------------------------+---------------------+---------------------+-----------+------------------------------------------------+
| cd0798b6cff44f3ab9ac95a412903a153f13b87e9 | 2022-08-31 16:26:00 | 2022-09-14 16:26:00 | 127.0.0.1 | Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7 |
| d3ee5c4850cfba6b3d939e4 | | | | ) AppleWebKit/537.36 (KHTML, like Gecko) Chrom |
| | | | | e/104.0.0.0 Safari/537.36 |
| 279096a7c734fc6d518add9b0e519922d3cd94c28 | 2022-09-11 20:53:49 | 2022-09-25 20:53:49 | 127.0.0.1 | Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; |
| 2493c73080e364c07fe9908 | | | | rv:104.0) Gecko/20100101 Firefox/104.0 |
+-------------------------------------------+---------------------+---------------------+-----------+------------------------------------------------+
$ wp user meta get 1 session_tokens
array (
'cd0798b6cff44f3ab9ac95a412903a153f13b87e9d3ee5c4850cfba6b3d939e4' =>
array (
'expiration' => 1663172760,
'ip' => '127.0.0.1',
'ua' => 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/104.0.0.0 Safari/537.36',
'login' => 1661963160,
),
'279096a7c734fc6d518add9b0e519922d3cd94c282493c73080e364c07fe9908' =>
array (
'expiration' => 1664139229,
'ip' => '127.0.0.1',
'ua' => 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:104.0) Gecko/20100101 Firefox/104.0',
'login' => 1662929629,
),
)
Hm, weird. The database in my case contained more than the command returned.
Unfortunately I can not provide more details since this was the result during an analysis of a compromised website and we don't keep logs or data of customers for good reasons.
Unfortunately I can not provide more details since this was the result during an analysis of a compromised website and we don't keep logs or data of customers for good reasons.
@DanielRuf Makes sense! It seems like it might've been specific to that environment.
If you run into it in the future, it'd be great to see if it can be reproduced in a generic WordPress environment. Feel free to pop into the #cli channel on WordPress.org Slack, and someone might be able to help you debug.