apiosys

Makes sense. Thanks again both.

Thanks both for your quick answer. @coreyk your solution seemed to me the most elegant. I’ve implemented it in my functions.php of the active theme but it has no effect I’m afraid… I still get the page served like so:

$ curl -I https://cdn.mydomain.com/wp-login.php
HTTP/2 200

The main issue I have with this is that the page being accessed like this, uses the IP from the CDN and not the client. And since I ban IP’s based on failed login attempts (and normal humans will never access this URL since they would simply go to mydomain.com/wp-admin) I end up banning the IP ranges from my CDN servers and thus not serving static content anymore…

@brianbrown thus I implemented your solution which did n’t appear nice to me at first sight but is probably much better in the sense that we let handle Apache throwing the redirect rather than WP which is probably safer, faster and less ressource consuming. And now I properly get:

$ curl -I https://cdn.mydomain.com/wp-login.php
HTTP/2 301 
location: https://www.mydomain.com/wp-login.php

which is exactly what I want. The CDN IP shows only once when hitting the page and then it is the client’s IP doing the rest and can thus get safely banned if this was an attack.

Here the snippet as I use it since only one CNAME for CDN and wanting the URL’s prefixed with www to be consistent with the rest of the site and added support for mp4 files:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP_HOST} ^cdn\.(.*)$ [NC]
RewriteCond %{REQUEST_URI} !\.(bmp|css|gif|jpe|jpeg|jpg|js|otf|png|swf|tif|tiff|ttf|webm|webp|woff|woff2|mp4)$ [NC]
RewriteRule ^(.*)$ https://www.%1/$1 [L,R=301]
</IfModule>

It’s good enough for me, got rid of those annoying attackers using my CDN like this.

Thanks.

Joris.

You might want to give this one a try : https://github.com/humanmade/wp-simple-saml . It works for me authenticating against G-Suite SAML. Sorry for not giving an answer related to this plugin directly but I never got this one to work neither unfortunately.

Kind regards,

Joris.

Of course you are right, throwing out the plugin should not leave any traces. I probably updated to many stuff at once incl. update to 5.2. Went through the classic check of disabling all other plugins and enabling them one by one and found out that “WP Simple Paypal Shopping cart” was the culprit. As soon as I get rid of that one the site health report is clean again… Sorry for bothering here with that. I have added your plugin also back in and the site report remains clean (and no more usernames are leaked). Many thanks. Joris.

Hi Daniel. Thanks for following up. Unfortunately I didn’t get it resolved, I’m now using another plugin that does the trick with some manual modification.

Kind regards,

Joris.

Thanks for your reply. It would be good to have a backport to the current stable though as well since I’m not too keen on upgrading on a live system with a very fresh version. Hope you can take that into consideration.

Kind regards,

Joris.

The standard one is like so:

[ultimatemember form_id=12345]

replacing the form_id with your own.

Kind regards,

Joris.

Any news on this issue? This is maybe small but a real showstopper…

J.

Can you please take into consideration this bug? Even though this ticket is a duplicate, there are other reports of this same issue that are not being addressed as far as I can see.

Many thanks in advance,

Joris.

Self-reply: for those interested, I have accomplished this in a function in my theme so as not to modify the code of the plugin. In this exemple, the field created in UM forms is called agree_tc, ajust to your own needs as well as appropriate error message to user:

// As part of UM authentication process, call function to verify TC checkbox
add_filter('wp_authenticate_user', 'wp_authenticate_user_acc', 99999, 2);

function wp_authenticate_user_acc($user, $password) {
    // See if the checkbox #agree_tc was checked
    if ( isset($_POST['agree_tc']) ) {
        // Checkbox on, allow login
        return $user;
    } else {
        // Did NOT check the box, do not allow login
        $error = new WP_Error();
        $error->add('did_not_accept', 'Please confirm that you have read and accept the terms and conditions' );
        return $error;
    }
}

Any ideas someone?

For the apostrophe issue in the bio of users, I confirm this is still the case even in v 1.3.88 and is NOT fixed despite the statement of the official support. There are various reports about that in this forum. Support: can you please fix this urgently? I think it’s really a showstopper for a lot of us.

Kind regards,

Joris.

Duplicate since ongoing topic here : https://www.ads-software.com/support/topic/characters-show-as-html-code-on-frontend/#post-9555873 . That one is NOT solved though.

For support: what do you mean by:

Do you have “Does this textarea accept HTML?” turned on in the biography field settings?

Where do you mean to set this? I have set “Enable html support for user description” to ON in Appearance => Profile.

J.

@tnightingale I have tried your solution but it’s still the same result for me. This remains a bug to me. I posted this yesterday also here : https://www.ads-software.com/support/topic/bug-html-chars-in-members-page/ .

Can the support team please have a look into it?

Kind regards,

Joris.