rmpel

<?php
// sent an updated nonce to the front-end on each request
add_filter( 'rest_post_dispatch', function( WP_REST_Response $response, WP_REST_Server $rest, WP_REST_Request $request) {
    $response->header('X-WP-Nonce', wp_create_nonce( 'wp_rest' ));
    return $response;
}, PHP_INT_MAX, 3);

// wp_create_nonce relies on user-id from global user object, and authentication cookie.
// both are INCORRECT after programmatic log-in or log-out.
// Really, WordPress? You should do this for us!

danieliser

<?php

/**
 * Return the default suggested privacy policy content.
 *
 * @return string The default policy content.
 */
function plugin_get_default_privacy_content() {
	return
	'<h2>' . __( 'What personal data we collect and why we collect it' ) . '</h2>' .

danieliser

<?php

/**
 * Register eraser for Plugin user data.
 *
 * @param array $erasers
 *
 * @return array
 */
function plugin_register_erasers( $erasers = array() ) {

danieliser

<?php

/**
 * Register exporter for Plugin user data.
 *
 * @see https://github.com/allendav/wp-privacy-requests/blob/master/EXPORT.md
 *
 * @param $exporters
 *
 * @return array

powerman

How to securely test local/staging HTTPS project

Modern projects often support HTTPS and HTTP/2, moreover they can use Strict-Transport-Security: and Content-Security-Policy: headers which result in different behaviour for HTTP and HTTPS versions, or even completely forbid HTTP version. To develop and test such project locally, on CI, and at staging server we either have to provide a way to access it using HTTP in non-production environments (bad idea) or somehow make it work with HTTPS everywhere.

HTTP in non-production environments is a bad idea because we'll test not the same thing which will runs on production, and because there is a chance to occasionally keep HTTP enabled on production too.