inthylight

See “How do I use the Clef login shortcode?” in the new Clef knowledge base.

@daltarn3 if you choose to disable passwords for some or all users, you can then create an override URL that allows password-based access.

“How do I use the Clef login shortcode?” has been added to Clef’s knowledge base. The article explains how to use the clef_render_login_button shortcode both in posts/pages and in text widgets.

I’ve been looking into the same issue. According to the HSTS specs (6.1.1), setting the max-age directive as 0 should “turn off” HSTS in the following sense:

A max-age value of zero (i.e., “max-age=0”) signals the UA to cease regarding the host as a Known HSTS Host.

Compare 5.3:

Specifying a zero time duration signals the UA to delete the HSTS Policy (including any asserted includeSubDomains directive) for that HSTS Host.

@barbaraas,

I experienced a similar phenomena after yesterday’s auto-update to 3.9.2. In my case the problem was that the file permissions changed (inexplicably?) from www-data:www-data (the user:group under which PHP runs on my server) to root:root on select subfolders within /wp-content/plugins/. In order to get updates for those select plugins to work, I changed the permissions via the command line. From within /wp-content/, I ran:

chown www-data:www-data -R plugins

Hi Julio,

The problem was actually in the Clef backend rather than in the WP Clef plugin. So, no, I didn’t make a support request on the WP Clef page.

Clef fixed the backend problem, and now WP Clef and SX User Name Security are fully compatible.

Peace

…gentlemen, I apologize. My initial conclusion based on my debug attempts proved erroneous. It turns out there was a bug in wpclef (now fixed). I’m not sure why deleting the user name security plugin made a positive difference in my debugging (it removed the internal server error and allowed successful logins), but the problem was with wpclef, not user name security.

Hi Daniel,

I’m in the middle of live debugging a potential compatibility issue with wpclef that might be the cause . . . hang on.

With so many users (including myself on five sites) encountering this bug in 3.1.2, wouldn’t it be better to push a fix now rather than to recommend an awkward “mini plugin” in the undefined interim?

Thank you for the set cookie domain tip. Adding this to the config file fixed the same problem for me that pjv was having. Also, it fixed the post/page previews errors (I was receiving 404 errors).

Has anyone tried the solution mentioned here: modifying the cookie domain?

A small “bug” report: the Site Lockout Notification e-mail contains two typos (i.e., missing a space before the opening parens around the IP and “parmenently”).

Dan,

First, I love your plugin. Thanks for a great tool.

Second, I want to second the motion to add the full IP for failed attempts to the notification e-mails and to the plugin backend. It is a bit cumbersome to have to open the database look up the bad IPs manually.

thanks,
LO

A suggestion for the two-factor authentication feature you mentioned: add Clef integration as one of your two-factor options.

Thanks for the great plugin!