Hot answers tagged

32

Sessions aren't enabled in wordpress by default, if you want to activate php sessions add this at the beginning of your functions.php: if (!session_id()) { session_start(); } You now can use $_SESSION['your-var'] = 'your-value'; to set a session variable. Take a look at the PHP documentation on sessions. Update: There was a second answer, which, in ...


21

You just need to add your filter hook like this: function myplugin_cookie_expiration( $expiration, $user_id, $remember ) { return $remember ? $expiration : 600; } add_filter( 'auth_cookie_expiration', 'myplugin_cookie_expiration', 99, 3 ); You can add it to your theme’s functions.php file.


13

EDIT: "THE PLUGIN BELOW ISN'T AVAILABLE ANYMORE, SO PLEASE USE THAT PLUGIN INSTEAD: WordPress Session Plugin" There is a good WordPress Plugin adapted from CodeIgniter Session class: WP Sessions Plugin. When you activate the plugin, you can start to use $session object from anywhere in your theme ($session object as long as global). For instance, to use $...


13

OK, simple solution after digging in the WordPress code. // get all sessions for user with ID $user_id $sessions = WP_Session_Tokens::get_instance($user_id); // we have got the sessions, destroy them all! $sessions->destroy_all(); This will log the user with ID $user_id out of WordPress. Use case: My use case for this is when a user is approved ...


12

It uses bare cookies and stores the login state information client side. + = wordpress_7339a175323c25a8547b5a6d26c49afa=yourusername%7C1457109155%7C170f103ef3dc57cdb1835662d97c1e13; Where do all these cookies and salt come from? The salt is in your wp-config.php file: /**#@+ * Authentication Unique Keys and Salts. * * Change these to different ...


12

This question made me really interested. Took about 5 hours of my Saturday to create the full solution :) Plugin Limit Login Sessions It doesn't provide a settings page yet, so all options are currently hard coded. The plugin implements the following (according to OP): A user can have a maximum of 5 login sessions across various browsers and devices. If ...


10

Short introduction After quick look inside WP source code, I think I've found solution... WordPress uses two functions to set and parse auth cookies: wp_generate_auth_cookie wp_parse_auth_cookie There is a filter in wp_generate_auth_cookie called auth_cookie which you probably could use to change the contents of cookie, but there is no filter inside ...


7

WordPress doesn't use sessions, that's why your session variables aren't working. As a matter of fact, if certain variables are defined, WordPress will actually destroy $_SESSION to keep itself stateless. But if you really want to use sessions, try adding session_start() at the beginning of your wp-config.php file. This will (hopefully) start sessions ...


7

Transients are just database keys that expire. It's like telling WordPress you want it to remember a certain piece of information, but for a limited time. In general, transients are accessible to PHP through any request. But since they're server-side, transients are only exposed to front-end users if you as the developer expose them. A Solution Given ...


6

It finally hit me that javascript would be behind the interim login modal behavior, and that gave me a new direction in my search. I have disabled the new login popups by adding the following to my theme's functions.php file: // Disable login modals introduced in WordPress 3.6 remove_action( 'admin_enqueue_scripts', 'wp_auth_check_load' ); If anyone's ...


5

Transients are persistent storage mechanism. That means that by saving transient with certain key you will be able able to retrieve same transient with that same key (if it had not expired and cache have not been flushed since). "Public" does not really apply to them, since they are internal code concept and only thing that accesses them is your code, not ...


5

The reason for not working $_SESSIONS in WP Core: The thing WordPress is doing with sessions is burdened inside ~/wp-includes/load.php. The responsible function for resetting the $_SESSION to null is wp_unregister_GLOBALS(). So in case you really need it, you'll have to turn register_globals off in your php.ini file. /** * Turn register globals off. * *...


5

Use wp_logout(). It calls wp_clear_auth_cookie() and invalidates the current log-in information immediately. Sample code, not tested: add_action( 'init', 'log_out_banned_user' ); function log_out_banned_user() { if ( ! is_user_logged_in() ) return; $user = wp_get_current_user(); if ( ! get_user_option( 'rc_banned', $user->ID, ...


5

I've discovered the following stuff. This kind of login is called internally Interim. It works thanks to the continuous polling offered by the Heartbeat API. The prefix of the expired session functionality is wp-auth-check and the important bit for me was a little script at /wp-includes/js/wp-auth-check.js. When the auth check request is sent to the ...


5

Your problem is that you call wp_logout_url immediately after wp_set_auth_cookie. wp_set_auth_cookie() does some setcookie() calls. Unfortunately setcookie doesn't make the new value available instantly in the PHP global $_COOKIE. It must be set through a new HTTP Request first. wp_logout_url() (via wp_nonce_url > wp_create_nonce > wp_get_session_token > ...


5

Stop what you're doing - it's so much simpler! function wpse_191369_post_password_expires() { return time() + 10; // Expire in 10 seconds } add_filter( 'post_password_expires', 'wpse_191369_post_password_expires' ); That's all you need.


5

WordPress doesn't use PHP sessions, so WordPress itself can not be related with your sessions working or not regarding if you are logged in or not (I think). Try to call session_start() on init action instead of doing it in a template file and be sure it is called before your custom library is loaded. Also, it can be interesting to end the PHP session on ...


4

This is not surprising or uncommon, it's how browsers work, the pages are cached and are part of the browser history. This is not specific to WordPress but many web applications out there. There are also different approaches to providing a solution. For one (not very good solution), clearing the browser history. For another - sending in special cache ...


4

Yes, WordPress uses cookie to keep track of who is logged in in cookies. But you don't have to rely on it. If you want to check if user is logged in, you can just use is_user_logged_in function and you can identify a user by his/her ID which you can get by calling get_current_user_id function.


4

Your code doesn't seem to be wrong, it's just how I would do it - see my answer here. So the question would be is your session getting started? Try debugging this: // do you have a session id $s_id = session_id(); print_r($s_id); // can you declare a bogus session variable, yours might just be empty $_SESSION['bogus'] = 'bogus'; print_r($_SESSION['bogus']);...


4

While toscho's method works, a simpler approach might be to use the authenticate hook to prevent them from authenticating via cookie, or any other means, in a more direct fashion. Totally untested code. Should work though. // the priority of 999 is to ensure it's last in the auth chain add_filter('authenticate', 'force_fail_banned_users', 999, 3); ...


4

The definitive solution with session is.. do not use session. As example in your form, you can output 3 fields: an image field -> the captcha image a text field -> to allow users to insert the characters an hidden field -> contain the solution but encripted using wp_create_nonce In this way when the form is submitted you can compare the user input with ...


4

Here (with some trepidation) is a sketch of a use-once link solution that might be safeish enough if one can depend on the ip being fairly constant (at least in the short-term) to the phone, using a query var and a transient based on $_SERVER['REMOTE_ADDR'], though as @Wyck and @G. M. say, any such backdoor is a security risk... // Make query var & ...


4

You also need to define a matching COOKIEHASH for both sites - a random 32 bit string will do. By default, COOKIEHASH is an MD5 hash of the site URL, and is used to generate the default names for all authentication-related cookies. Hence why, at the moment, your cross-domain login isn't working (the names of the cookies aren't consistent, as COOKIEHASH will ...


3

Of course, right after submitting it I find out the cause for the issue: The problem is caused by FireFox prefetching the other post in the background, resulting in those noticed 2 different postIDs per single page request. If I disable prefetching, then it behaves as expected, so will need to add code to check for the prefetch header sent by FireFox ...


3

Wordpress doesn't use PHP session ($_SESSION). If you want to use it you need to do at your own. For example: add_action('init', 'wpse_session_start', 1); function wpse_session_start() { if(!session_id()) { session_start(); } } But, if you want is to get the user id of the current user, you can use get_current_user_id(): <?php $user_ID =...


3

The reason is when you execute this code setcookie('wp-postpass_' . COOKIEHASH, '', 0, COOKIEPATH); It will reset your post password cookie to blank '', so it just work once To solve this you need to assign the original cookie and extend the timeout, like this setcookie('wp-postpass_' . COOKIEHASH, $_COOKIE['wp-postpass_' . COOKIEHASH], time() + 60 * 5, ...


3

There is no regular output and hence no header sent before template_redirect on the front end. If you need sessions on the back end too, use the action wp_loaded to cover both. Example: add_action( 'template_redirect', function() { $status = session_status(); if ( PHP_SESSION_DISABLED === $status ) { // That's why you cannot rely on ...


3

That button sends an AJAX request that runs wp_ajax_destroy_sessions(). It's not really abstracted in such a way that you can re-use it outside of AJAX, but if you copy the source into your own function, minus the JSON parts, then you could perform the same action yourself. The key part is this bit, which will destroy all sessions for a given user ID: $...


3

There’s nothing that requires that get_header run before output starts, you could put it in the middle of a template file after other content and still have a perfectly valid theme. template_redirect is the last action where it is guaranteed that no output has started yet.


Only top voted, non community-wiki answers of a minimum length are eligible