• Resolved ozarkrepair

    (@ozarkrepair)


    Hello, I’m a new user of AIOS and have it installed on a website still under local development, so I don’t have a public link to share. All features seem to work except for the bulk force login page rename (aka “LPR”) feature which I’d really like to use.

    The platform I have wordpress installed on is NixOS, which is fairly different from the usual Linux distros, so this could be related to an OS platform incompatibility. When I activate the LPR feature, and go to visit the new login page slug, I just receive a 404 — I never reach a login page from the new slug. Looking at httpd access/error logs and chrome inspector doesn’t really give me any hints as to what is going wrong. I’ve searched this forum and looked at about 20 of the most recent related posts for which resolution of a similar issue seems mostly related to either having wordpress installed in a subdirectory and needing to have appropriate .htaccess mod rewrites applied, or having used the Brute force cookie login feature which could cause a conflict, neither of which applies in my case.

    I’ve been looking through the plugin code to try and track down where things are going wrong, but I’m not finding where the code path should even start to pick this up as soon as the url https://$FQDN/$aiowps_login_page_slug is entered. The LPR feature doesn’t seem to modify .htaccess so I don’t think there is any rewrite handling that I need to look at, so I should be looking somewhere in the plugin code I think. The plugin file wp-security-process-renamed-login-page.php is an obvious candidate, but nothing is jumping out at me in that code as going wrong, so maybe I need to be looking elsewhere.

    Can somebody help point in the right direction to debug this?

    PS – I’m using the latest wordpress 6.1.1 and latest AIOS 5.1.5 with PHP 8.1

    Thank you!

Viewing 5 replies - 1 through 5 (of 5 total)
  • Thread Starter ozarkrepair

    (@ozarkrepair)

    Looks like I probably need to start by tracing through the code path at the index.php entrypoint.

    Plugin Support hjogiupdraftplus

    (@hjogiupdraftplus)

    Hi @ozarkrepair

    Yes it should start with index.php being called and wp-security-process-renamed-login-page.php file AIOWPSecurity_Process_Renamed_Login_Page::renamed_login_init_tasks() reaches there where it checks url being requested path matches the slug it will try show the rename login page not 404

    Thread Starter ozarkrepair

    (@ozarkrepair)

    Thanks! I’ll update again once I have it resolved, hopefully by next weekend.

    Thread Starter ozarkrepair

    (@ozarkrepair)

    Hi @hjogiupdraftplus, I figured it out. This was due to a small edge case. The UI for the LPR feature states:

    Enter a string which will represent your secure login page slug. You are encouraged to choose something which is hard to guess and only you will remember.

    So, I was testing with rename slugs following patterns of wp-login-$RANDOM_SUFFIX and I didn’t think anything of it, because there are no restrictions on the rename mentioned to the user as shown above.

    But in the code here, there is a strpos check for any substring of wp-login in the rename slug, and if found, it will fail with 404, which is why my tests were failing.

    Maybe adding a note in the UI on that feature to not include wp-login anywhere in the name that is chosen would be helpful to anyone else who might otherwise do the same thing and then not understand why it doesn’t work.

    Thanks for the pointer above to get me looking in the right direction!

    Plugin Support hjogiupdraftplus

    (@hjogiupdraftplus)

    Hi @ozarkrepair

    Thanks for identifying this issue, I will create internally ticket for this and It might be in upcoming AIOS version as per priority with other task.

    Regards

Viewing 5 replies - 1 through 5 (of 5 total)
  • The topic ‘Debug pointer help for bulk force login page rename’ is closed to new replies.