dougjoseph

Thank you for sharing this! I wept as I read it.

I’m so saddened to hear of this. Thank you for letting us know. Could you link me to the memorial page you found?

OK, so armed with the knowledge that that the plugin seems to use the same secret for one user on all sites in a multisite hub, I tried, within the Google authenticator app, using only one login for all sites, and that seems to work for logging into all the sites. I guess I just did not understand how it was supposed to work.

• This reply was modified 11 months, 2 weeks ago by dougjoseph.

Is the included 2FA feature supposed to ignore subdomains and other domains in a multisite hub?

When I created logins in the Google authenticator app, I created one for each of our sites.

However, the 2FA feature of the plugin apparently wants to use the same secret for every single site in our multisite hub (both subdomains and domains).

I only figured that out by noticing it while I was going to each of the sites, clicking into my profile settings within each site, and resetting the secret. I noticed that the most recent secret was overwriting all the earlier secrets on the other sites. That meant, I think, that all the previously made logins in the authenticator app, were based on an earlier secret now deleted. Thus, presumably that would mean only the latest distinct login in the authenticator app works.

I seem to either not understand how this is supposed to work, or it’s not working right, and I’m not sure which.

Thanks. I will try to circle back after checking.

Thanks for the additional info. The sites run by the non-profit have quite a few plugins, as you can imagine. If I get a chance to try to troubleshoot I will update if I can learn more. ??

Hello and thanks for replying. I am a developer with decades of coding experience, including expertise in PHP. My involvement here is as a volunteer helping a non-profit organization. The only action needed to cause this warning message to be thrown in the error log is to simply visit the WordPress site that has your plugin installed. The error message tells exactly which of your scripts is causing it. Specifically seems to be line 377 of “PDb_Session.php.”?As I mentioned, the server in focus is running PHP Version 7.4.33. I’m not sure why your code would try to modify headers in such a case, but we’re not doing anything that should be causing any need for modifying the headers.

Here is an example of a newly created warning generated just now by simply viewing the website’s home page, while the “Participants Database” plugin was installed and activated:

PHP Warning: Cannot modify header information – headers already sent in /home/~/public_html/wp-content/plugins/participants-database/classes/PDb_Session.php on line 377

Dear @priyaasawa

Wow, that’s interesting. Glad you got it sorted out.

Dear @priyaasawa

OK, that could mean at least two different things. One is that your issue is something else entirely, not related to the “SubstituteMaxLineLength” — and the other is you may have more than one issue, something in addition to “SubstituteMaxLineLength”

At this point, and I’m assuming you’ve already tried (by process of elimination) to rule out something related to either plugins or themes, it may be time for you to simply contact Godaddy support.

And finally, for clarity sake, here’s what I was suggesting on where to add it (which I am also assuming is exactly what you already tried):

SubstituteMaxLineLength 10M

# BEGIN GD-SSL
<IfModule mod_rewrite.c>
Options +FollowSymLinks
RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteCond %{HTTP_USER_AGENT} ^(.+)$
RewriteCond %{SERVER_NAME} ^www\.theglacstudio\.dk$ [OR]
RewriteCond %{SERVER_NAME} ^bp2\.bb9\.myftpupload\.com$
RewriteRule .* https://%{SERVER_NAME}%{REQUEST_URI} [R=301,L]
Header add Strict-Transport-Security “max-age=300”
Header always set Content-Security-Policy “upgrade-insecure-requests”
</IfModule>
# END GD-SSL

# BEGIN WordPress
# The directives (lines) between “BEGIN WordPress” and “END WordPress” are
# dynamically generated, and should only be modified via WordPress filters.
# Any changes to the directives between these markers will be overwritten.
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* – [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ – [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

# END WordPress

One last question: Are you using Godaddy for your hosting?

Also, feel free to post or otherwise share your .htaccess file’s contents.

PS: I see now you are indeed doing the add to your .htaccess file.

If you try adding it at the top, does that help?

Dear @priyaasawa

Hello. Are you adding the line to your .htaccess file?

If so, I would recommend adding it at the top.

If not, then be aware it goes in your .htaccess file.

Update: I’m currently using the following as a “quick and dirty” fix (that I am not real happy with, but it was done in a bit of desperation):

if ( !function_exists( 'our_custom_login_page_style' ) ) {
	function our_custom_login_page_style() {
	    echo '<style>.no-js .hide-if-no-js {display: block !important;}</style>';
	}
}
add_action('login_head', 'our_custom_login_page_style');

Notes:

This “add_action” function was copied (and then tweaked) from an OSTraining WordPress Tutorial titled “How to Customize the WordPress Login Screen” — written by Harish Chouhan on April 15, 2013.

URL: https://www.ostraining.com/blog/wordpress/customize-login/

I previously found out about use of “login_head” from brianjohnhanna’s reply at:

URL: https://wordpress.stackexchange.com/questions/241961/a-child-theme-version-of-wp-login

…however, the “add_action” in brianjohnhanna’s reply does not overwrite existing CSS and we needed to do that.

KEY NOTE:

This fix basically negates (only on this page), i.e. overrules by “brute force” so to speak, a script-based protection by which whatever items would normally be hidden whenever JavaScript support is not found in the browser, will not be hidden. Since a purpose of such “detection and hiding if not found” schemes is to prevent spambots from abusing the site, this quick and dirty fix is a debatable detriment. It does succeed in letting site users reset their passwords. But is the cost worth it? Finally, since I don’t yet know what in our old theme needs edited so the desired feature will work as intended, I don’t yet know of another, better alternative.

I found this:
https://www.ads-software.com/support/topic/missing-password-input-field-for-resetting-pw/

It seems someone else found the same issue, and got as far as realizing it was somehow theme related, but that’s as far as they got.

Does anyone have any ideas where to look in the theme to fix such a brokenness?

My browsers (both Safari 14 and Chrome 92) (on macOS Mojave) do have JavaScript enabled, as per testing with https://www.whatismybrowser.com