• Resolved animagic

    (@animagic)


    Are there any specific changes or recommendations for settings within the plugin that should be made before attempting to switch to https://. I have attempted everything short of uninstalling the few plugins I have and reverting the database to a clean version with no plugin data. Currently, even with the Rename login feature and the Cookie rename feature turned off, I lose access to wp-login.php after switching the WordPress URL Settings to https://. I also get an endless loop when attempting to place a rewrite rule for 301 redirect to https://.

    I am guessing this is an htaccess issue with the myriad of rules placed in it by AIO Security. I love the plugin but am having some serious issues with converting to https://

    For reference, I have a live site at https://mysite.com and a development site at https://dev.mysite.com BUT the development site has its own directory and is not a true sub-domain/sub-directory of the main site.

    https://www.ads-software.com/plugins/all-in-one-wp-security-and-firewall/

Viewing 5 replies - 1 through 5 (of 5 total)
  • Plugin Contributor mbrsolution

    (@mbrsolution)

    Hi animagic are you sure you have set up the backend correctly to https://?

    Can you share what areas you have changed in the backend to https://?

    Thank you

    Thread Starter animagic

    (@animagic)

    I found it was not an issue with the plugin. My pair of web servers are behind a Load Balancer that our host runs and the LB was not setup properly to send the X-Forwarded-Proto header. All is well now!

    Plugin Contributor mbrsolution

    (@mbrsolution)

    Hi animagic I am glad to hear ??

    Can you mark this support thread as resolved.

    Thank you

    Thread Starter animagic

    (@animagic)

    Resolved

    Thread Starter animagic

    (@animagic)

    Reopening the ticket.

    This is a side-issue that possibly pertains to my conversion to https://.

    I have 2 sites, 1 live and 1 dev. the dev site has been successfully flipped to https:// but in doing so, either I edited some code or the database in some fashion so that the Cookie Based Brute Force Protection does not correctly redirect attempts at /wp-login.php to my current redirect of https://127.0.0.1. It still provides the login page at /?mysecretword=1 thought which is odd. My live site is not https:// yet as we have not finished testing the theme, etc. on the dev site and the redirect works correctly there.

    I have edited the htaccess file in the dev site to reflect the change to https in the Cookie BF section and it is identical to the live site’s htaccess in all other regards. I also don’t see any anomalies or differences in the database, thought I may be missing something.

    Any thoughts?

Viewing 5 replies - 1 through 5 (of 5 total)
  • The topic ‘https conversion’ is closed to new replies.