Authz_core errors in Logs

[BlackTiger63]

The site of my friend looks working, but got a lot of these errors in the logs:

[Thu Jul 12 12:25:15.194522 2018] [authz_core:error] [pid 11175] [client 141.135.190.184:45849] AH01630: client denied by server configuration: /home/user/domains/mydomain.com/private_html/index.shtml
[Thu Jul 12 13:56:44.433430 2018] [authz_core:error] [pid 24262] [client 54.36.148.248:27986] AH01630: client denied by server configuration: /home/user/domains/mydomain.com/public_html/data/system/modules/user/avatar/img/whitetiger870
[Thu Jul 12 14:01:17.818421 2018] [authz_core:error] [pid 24970] [client 54.36.148.74:58340] AH01630: client denied by server configuration: /home/user/domains/mydomain.com/public_html/data/system/modules/user/avatar/img/glory
[Thu Jul 12 14:38:31.631001 2018] [authz_core:error] [pid 30596] [client 84.30.xx.xx:51838] AH01630: client denied by server configuration: /home/user/domains/mydomain.com/private_html/index.shtml
~

Same kind of errors with /public_html instead of /private_html.

Using apache 2.4.33 PHP 5.6.36 (will be replace by 7.2 after the holidays) No mod_security present. Mod_ruid2 running. Private_html symlinked by control panel to public_html.

Any hints? P.s. I've seen that some of the directory's requested don't exist, but some in the logs do and there is that index.shtml thingy too.

[pH-7]

index.shtml..? Have you added something that requests an index.shtml...? The .htaccess file denies it since it is located in the "protected" folder. More info https://github.com/pH7Software/pH7-Social-Dating-CMS/blob/master/_protected/.htaccess

Same for data/system/modules/user/avatar/img/whitetiger870 Normally, the software would request data/system/modules/user/avatar/img/whitetiger870/1-64.jpg (with the image filename).

If you try to request an asset without the filename or with a wrong one, it will be denied by https://github.com/pH7Software/pH7-Social-Dating-CMS/blob/master/data/.htaccess

When you got that error message, try to search in your browser's source code for data/system/modules/user/avatar/img/whitetiger870 without image filename extension in order to see the cause of the incorrect request from the webpage.

Hope that helps!

[BlackTiger63]

I must honestly say I have no clue. I did not add any request to an index html or shtml or anything kindlike. It's a clean and fresh installation of the newest version. And I did not touch any .htaccess file, except the one in the public_html root to enable SSL.

As for the images, there is no whitetiger870 folder there, these are the only folders present there. drwxr-xr-x 2 tend21 tend21 4.0K 2018-07-11 22:14 whiteladybug276 drwxr-xr-x 2 tend21 tend21 4.0K 2018-07-11 22:14 whiteostrich541

So maybe is trying to hack something by trying to request folders which existed in older versions or something? Might be previous users which don't exist anymore causing this, so that is not really a big issue.

But that would not explain the index.shtml error request, which already occurs by only visiting the main domain page like http://mydomain.com where the script is running.

[Thu Jul 12 16:51:39.130407 2018] [authz_core:error] [pid 23045] [client 84.30.92.132:56715] AH01630: client denied by server configuration: /home/user/domains/mydomain.com/private_html/index.shtml Encountered a new user too with other error: [allowmethods:error] [pid 22196] [client 66.249.66.3:60143] AH01623: client method denied by server configuration: 'OPTIONS' to /home/user/domains/mydomain.com/private_html/video, referer: http://mydomain.com/johnxxxxx.html

I don't know if that has anything to do with requesting non existing stuff, looks like a logged in user, but I can be mistaken. When I visit, I don't see any whitetiger error, and the page source does not have anything with shtml. I only have the index.shtml error.

[BlackTiger63]

/video folder is also not existing in public_html (yet) so maybe we only have to concentrate about the index.shtml error.

Maybe this will help. Issue occuring with IE, FF and Chrome. If I look in the element inspector from Firefox under console, I see this error, but I'm no designer or coder, so I don't know if this can cause the index.shtml issue. Fout bij brontoewijzing: request failed with status 404 Bron-URL: http://otherdomain.com/php7cms/static/js/jquery/jquery.js Brontoewijzings-URL: jquery.min.map[Meer info]

This was also on a clean installed newest version, which I did on another account to test this issue. Sorry that it's Dutch. But "fout bij brontoewijzing" = Error in source allocation.

[polynamaude]

@BlackTiger63 No the video path does not exist at the root of your installation (/public_html in your case as I understand). It's a normal thing as /video is the name of the video module only. There's no direct correlation between the URL and the underlying filesystem representation.

You can look over at the issue you opened #232 . pH gave you links to the front end router that does the translation between the request and the pages served. What we actually called front end controller.

So you will find the modules under /_protected/app/system/modules (base modules) and /_protected/app/modules (for the add ons).

PM

[vinny1962]

I believe this is caused by Mod_Ruid2 this could be your problem try using CGI or have your server admin covert your account to CLI in the PHP manager this may help your site work properly this is not good to run with PHP7------> Mod_ruid2 running. Private_html symlinked by control panel to public_html.

And symlinked b y control panel I never herd of try cloud Linux symlink protection.

Regards

Vinny

On Fri, Jul 13, 2018 at 3:39 PM, Polyna-Maude R.-Summerside < notifications@github.com> wrote:

@BlackTiger63 https://github.com/BlackTiger63 No the video path does not exist at the root of your installation (/public_html in your case as I understand). It's a normal thing as /video is the name of the video module only. There's no direct correlation between the URL and the underlying filesystem representation.

You can look over at the issue you opened

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/pH7Software/pH7-Social-Dating-CMS/issues/234#issuecomment-404933382, or mute the thread https://github.com/notifications/unsubscribe-auth/AdMNfUUIGt4aqUCKvm1V5YlDO0NgIkABks5uGPdugaJpZM4VMzHq .

[BlackTiger63]

@polynamaude Correct, that part confuses me every time, but due to the log entry's it looked like this user was trying to lookup his old video's, but his account did not exist anymore because I installed the script totally new for my friend.

@vinny1962: Thanks for the tip. But why do you think mod_ruid2 would cause this? I am the server admin by the way, and the script is from a friend. However, I won't change mod_ruid2. If that would be the cause of the issue, then this is the only script having issues with mod_ruid2. All systems have their pro and cons. As for symlink private_html to public_html, never heard of? Wel loads of company's are using Directadmin control panel and it's an option in there for which the user can choose in their package. If they enable it, ofcourse a real symlink is made, working great. Private_html will be removed in due time anyweay as it's kind of obsolete since evertying will become https. Cloud linux symlink protection is something totally different.

[polynamaude]

@BlackTiger63 Maybe you should take the time to install pH7CMS on a virtual machine with a plain standard apache web server and get a good understanding of how the system works. That will save you from going to look for problem in avenues that aren't.

Like vinny said, your problem could be linked to your specific configuration (mostly) and one of the modules. For your affirmation that no other software caused you problem with this modules, that doesn't make a proof that it may not be your first one.

The more you optimise, the more you make intensive use of a system function and the more you risk finding new compatibility issue.

In the late 1990, early 2000 we used to get all kinds of system hanging when we switched them to Unix/Linux. Was it a Unix/Linux problem ? Not at all, it was bad memory chips that when used by DOS/Windows 95/98 we're working okay but when pushed to the limit by Linux/Unix failed.

To be able to support many connection with the less ressources possible we end up pushing software to its limits.

Take a look at apache documentation and mod_rewrite to understand the difference in the way of dealing with real path, hard link and soft link. You'll see the many subtile difference that are part of your solution.

To push away a possibility of issue on the only basis that you never got that problem before is not the way to do. As it's always good to try everything.

Have you ever had a CMS filter your request based on the User-Agent? There's always a first.

[polynamaude]

@BlackTiger63 You should get used to the fact that there's no definitive link between URL and underlying filesystem. Look at Symfony, CakePHP, Laravel, Yii and other framework.

When you get the same URL as the filesystem it's mostly that it's being continued this way based on a passed design before SEO friendly URL and HTTP 1.1 request translation (rewrite). To get good acceptance by search engine, you need to have a user friendly URL and that's not possible when you just base your action on the way the filesystem is built.

For example if Joomla is still based on the filesystem it's because it started with Mambo long time ago and needed to keep backward compatibility because of all the plugins and extensions. But it's going away with 4.0 and SEF URL

[BlackTiger63]

@polynamaude I know that. But I normally don't work with that. Mostly if I have to fix some things for scripts (which I only do as a service, because I don't have to fix scripts problems for users) I work with forum softwares and wordpress when I fix things for them. In those cases mostly the url and underlying filesystem is the same. I never worked with any of the frameworks you mentioned by the way or SEO stuff. SEO is not my job anyway. That's more for webdesigners and maybe users who want to do that.

That's might explain why I'm not used to it and if I encouter it again once a while, have to get used to it again. We're getting older, same as you already forgot that my 403 error in issue 233 was something you solved yourself when you had the same problem. If long not used or worked with something I need some getting used to again a bit.

I also am from the time since C64 and have lived through DOS, W3.x, os/2 etc. etc. It's not like I'm just coming around the corner. In fact we might be around the same age if you experienced these times too.

On a forum I had once an issue when something was filtered due to the User-Agent. Once... in 10 years! And it happend to me about 2 years ago. So it's easy to forget that. I don't know why you're talking abount symlinks and hardlinks, I don't have to do with that. I did not create any symlinks.

For your affirmation that no other software caused you problem with this modules, that doesn't make a proof that it may not be your first one.

Ofcourse, I didn't say that. But it would also be rather strange if I know it does not make a difference and have to explain it in to detail. For once I will do it know, so you both know why I stated it's not a mod_ruid2 issue. Because under mod_ruid2 there is never need for 666 for files or 777 for directory's. In contradiction of suphp (when using php-cgi) they can be used without getting an error 500. That comes in handy, because some bit worse written scripts still only do a 777 check and not if the folder is really writable.

With mod_ruid2 this is easy to test. Now for this reason, yesterday I just created all directory's to 777 and all files to 666 and the exact same index.shtml error occurs. So it's definately not a mod_ruid2 issue. Because the only other thing which mod_ruid2 does in base, is executing the php script as the user. Wich is a good thing.

So it's nice you state things about 1990 and 2000 and Joomla, and brings up some nostalgic with me because it was a great time. But it does not fix the index.shtml issue. It's not anything on my server which want to create an index.shtml or a johnxxx.shtml, it's the script that does this as you can also see from what I posted from the console.

So if you want, please have a look at this answer: https://github.com/pH7Software/pH7-Social-Dating-CMS/issues/234#issuecomment-404545356 which looks to me as if this is caused by jquery.min.map.

As said, I don't worry about the access denied errors at the moment. But this index.shtml thing is a real issue. Or at least a real error, not caused by the server imho. It might be possible to just ignore it as the script is working fine. But it's an improvement if it can be fixed somehow isn't it?

[BlackTiger63]

@polynamaude:

You should get used to the fact that there's no definitive link between URL and underlying filesystem.

But there is a definitive link between the logs and the filesystem! So when I say there is no whitetiger870 directory or /glory in the avater/img directory (this means any avatar/img directory) then there isn't. When searching for names I mean... Using find or locate, it's always to be found. And then one could wonder why the script is sending a access denied to the log, instead of a not found error. It's not a big deal, because it's only log stuff, but it makes it makes searching for reasons for an error a bit harder.

[polynamaude]

@BlackTiger63 Good luck ! You'll find your way.

[BlackTiger63]

No I don't. I have no clue why the index.shtml is requested on a fresh install and it's not mod_ruid. So hopefully somebody else can explain it.

[polynamaude]

@BlackTiger63 I talk about symlink because @vinny1962 refer to private/public html symlinked and I'm telling you that security is different for both.

Also modify your "settings" table in the database to disable asset caching, minifyimg and compression to see if it helps.

[polynamaude]

How can you say it's not mod_ruid if you haven't tried to disable.

[polynamaude]

@BlackTiger63 Do like all coder do and create a simple installation inside a virtual machine and add your options one by one to see which one is causing problem. And afterward go live.... Or take the Jewish way and wait 3000 years for god to come.

[BlackTiger63]

I can also ask if you investigated what mod_ruid2 really does on a server and why the script should be able to work with it.:) If I got time later on, I'll have al ook at it what it does at anoter server with php7 and php-fpm. But if it really is mod_ruid2, then the same error can be expected with php-cgi with suphp. I don't mind being "Jewish" for 1 second, as said, I don't use the script, just helping a friend, and the errors can be ignored because they don't make the script fail.

[polynamaude]

@BlackTiger63 Like I just said, go into the database and inside the settings table, disable cache, minify and compress. It should get working.

When using cache and minify, the system use curl to request assets, process and cache them. After it will serve the cached version. It will give less possibility of something going wrong with the preparation of your request.

PM

[polynamaude]

@BlackTiger63 try running "find . - name jquery.min.map" and you'll see that the file is not in the distribution. I don't speak dutch but what I understand is that you talked about a problem finding this file ? As you know .map file are used for development and not for end use. If I'm wrong then explain more of the dutch log file.

[polynamaude]

Also the problem seem to be that your installation is in /ph7cms and not in / so the router gets problem. Do your installation in a root (/) not a subfolder.

[polynamaude]

@BlackTiger63 Like I said the router translate the request and serve the module. It doesn't know how to deal with the installation in the /ph7cms and treat the request accordingly.

[BlackTiger63]

@polynamaude I was already doing some testing on another server, had some time left before going to sleep (it's 03.00 AM here now). :) What I did was install the CMS on another server with php7.1 and php-fpm which did not gave the index.shtml error. Still I'm sure it would not be mod_ruid2, luckily on that server I can test this, because I can switch between php-7 and php 5.6 with mod_ruid2. After switchting, there also was no issue, so it's not mod_ruid2 either. But at least I can be sure it's some kind of server issue somewhere.

The script is coded in a good way so it shouldn't matter if it's not in the root folder. On the test server not in the root folder either and it's working there. On my friends account is even is in the root folder.

However, on checking the http allowmethods, on the working server it contained OPTIONS as on the server with the issue it did not. So now I included OPTIONS, will clear the cache and see if the error persists or if this fixes the issue. It will at least fix one issue where this method was denied as I could see from the log. I'll be back to update.

[BlackTiger63]

Unfortunately, this did not help with that strange shtml issue. However, it's clear now that is must have something to do with the server.

As for that strange jquery.min.map, that became visible when I investigated the cms homepage with my browser using the console logger. I will translate the error for you. Error on source-allocation: request failed with status 404 Source-URL: http://myhobby.domain.com/php7cms/static/js/jquery/jquery.js Resourceallocation-URL: jquery.min.map

The jquery.js is from the script, but I don't know why the console says the resourceallocation url is jquerry.min.map.

On my friends homepage in the console there is also this line (translated): Cross-Origin-request blocked: the Same Origin Policy doe not allow reading from the external source on https://freegeoip.io/json/ . (Reason: CORS-header ‘Access-Control-Allow-Origin’ missing). These are minor log failures as the script is working fine, it's just console output from Firefox.

But I'm tired now. I will investigate further tomorrow. Good chance that if the problem the server causes is fixed, all other errors in the log dissapear too. Thank you for thinking with me again.

[polynamaude]

@BlackTiger63 This has to do with your server and it's why I said to use a virtual machine, starting with bare web server install the cms and install pieces from there to know when it break.

The request for .map is for your software to get a definition of the JS file so it's totally normal.

Your CORS Cross Origin Request is probably a good indication that the problem is in the configuration of your virtual host as it is mixing the different origin of request on the same server. You're using multiple domain name with one IP. Anyway we're far from the CMS and any issue related to it.

PM

[BlackTiger63]

I already stated that:

However, it's clear now that is must have something to do with the server.

I wanted to go to sleep, but it annoys me when the server does something which he shouldn't.

Since we agree it's a server issue and not script issue, I will close this one.

[polynamaude]

Keep a piece of paper beside your bed and you'll wake up with a solution to write down.

[BlackTiger63]

I already did just before I went to sleep. :)

So I tried just now and it's the .htaccess of the script, if I disable this one, the strange index.shtml stuff is gone from the logs.

# Deny access to all CGI, Perl, Python, Bash, SQL, Template, INI configuration, cache, log, temporary and text files
#<FilesMatch "\.(cgi|pl|py|sh|bash|sql|tpl|ini|cache|log|tmp|txt)">
#    # Apache 2.4+
#    <IfModule mod_authz_core.c>
#        Require all denied
#    </IfModule>

#    # Apache 2.2
#    <IfModule !mod_authz_core.c>
#        Deny from all
#    </IfModule>
#</FilesMatch>

So now I'm going to investigate why this server is having issues with it and the cpanel server isn't.

[BlackTiger63]

It's the "sh" statement causing this. Very odd, should not happen. Going to contact panel support about this.

[vinny1962]

Well Black Tiger I do not use the Direct Admin and I can not tell you what it is that is causing your problem I use cPanel so I am not sure what you are running that is causing you problem I use what is listed

mod_suexec

mod_suphp

mod_unique_id

Regards Vinny

On Sat, Jul 14, 2018 at 8:35 AM, Black Tiger notifications@github.com wrote:

It's the "sh" statement causing this. Very odd, should not happen. Going to contact panel support about this.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/pH7Software/pH7-Social-Dating-CMS/issues/234#issuecomment-405021065, or mute the thread https://github.com/notifications/unsubscribe-auth/AdMNfSWVPIIj8IRx8bstQtPrdX-Mn2x9ks5uGeWugaJpZM4VMzHq .

[BlackTiger63]

That's correct @vinny1962 . The other server which I tested on is a Cpanel server and there were no issues at all. It must be caused by something DirectAdmin is configuring in apache configs or virtual hosts some way. That's why I contacted support.

Greetings, Richard.

[BlackTiger63]

Reopening this as this is -not- a DA servers issue but a .htaccess issue.

Have a look at this: https://httpd.apache.org/docs/2.4/mod/core.html Since |sh| is in the Filesmatch directive, the log also shows the index.shtml denied because index.SHtml also contains the word "sh".

Same for the access denied log entry's to avatar images. /cache/pH7_cache/str/design/avatar/goldengorilla208/99dfc5661f2bcc0b0fe7b62xxxxxxxxxxx.cache.php

Which is the reason of the blocking of those access denied notices because cache.php also contains the word cache.

So the correct string in .htaccess should be: <FilesMatch "\.(cgi|pl|py|sh|bash|sql|tpl|ini|cache|log|tmp|txt)$"> with the dollar sign on the end.

The script is still blocking it's own cache (so cached avatar) files this way with it's .htaccess file. :)

[pH-7]

Thanks a lot for your investigation @BlackTiger63! I will dig in there according to your answer :)

[BlackTiger63]

Got another addition @pH-7 which I just found out. You might check out the .htaccess in the /public_html/data/ directory which denies all access to everything in the /data directory and below (so also the avatars jpg files in there), unless that is intended. At least the script is causing log entry's about it.

[polynamaude]

@BlackTiger63 Look at the "require all granted". What does it do ?

Exclude everything except if access is granted somewhere else. And it is in the main .htaccess

[BlackTiger63]

@polynamaude: If you know .htaccess so good, you should have seen why there was a block to index.shtml and the cache files which you didn't, but blaimed the server.

Can't you communicate at a normal, not denigrating way? And it is in the main .htaccess I call "main" in the public_html, but it's in the .htaccess in the data directory indeed.

We all overlook things. In this case, it were a lot of request by different ip's to non existing avatars. Since it were variuos different ip's and various avatars, made me thing it was .htaccess too.

[polynamaude]

May I ask why your server would be the only one having this problems?

Le 16 juillet 2018 08:54:06 EDT, Black Tiger notifications@github.com a écrit :

@polynamaude: If you know .htaccess so good, you should have seen why there was a block to index.shtml and the cache files which you didn't, but blaimed the server.

Can't you communicate at a normal, not denigrating way? And it is in the main .htaccess I call "main" in the public_html, but it's in the .htaccess in the data directory indeed.

We all overlook things. In this case, it were a lot of request by different ip's to non existing avatars. Since it were variuos different ip's and various avatars, made me thing it was .htaccess too.

-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/pH7Software/pH7-Social-Dating-CMS/issues/234#issuecomment-405237746

-- Polyna-Maude R.-Summerside

[BlackTiger63]

May I ask if you even checked apache error logs youserlf? I'm not sure, but I am sure a lot of users don't. And I wonder if you did, because if you now still think my server is having issues, after I prooved it's the scripts .htaccess I really start to wonder how you come to the idea the server would have problems.

My server has no problems and does exactly what it's told to do, by the .htaccess file, so I'm sure our server is not the only one. It's plain and simple following apache rules which every server does.

However, I'm prepared to answer your question. There are 3 very normal reasons that those log entry's do appear in the server and not on the cpanel server I tested with. 1.) As yo might know, the order of the Directoryindex directive can be different on servers. If index.php is stated before index.shtml, then index.shtml is not search for anymore, so will not be not blocked, hence no error in the error log. Our servers are already running several years, so they still contain the old order with index.* files first. Our cpanel server is brand new and that Directoryindex directive starts with index.php hence no entry in the cpanel's error log.

2.) Same for the xxxxxxxx.cache.php files. Which makes me doubt if caching was really working, as it was also forbidden by the .htaccess diretive. So again, no server problem.

3.) The reason that we're seeing a lot of access_denied notices to not exising avatars anymore is also logically. I already said we can ignore that. Could be hackers trying things, could be older users which do not exist anymore, searching for their old avatar, which is not present anymore because the script was installed totally fresh. Because my friend had some 0.5.8 version running which could not be upgraded anymore.

As for 2.) and 3.) on the cpanel and my other test account, I installed fresh versions. So there were no users, hence no image cache, hence no need to deny access to cache, hence no entry's in the error log.

[polynamaude]

@BlackTiger63 Then fix the script and go on because you're the only one complaining here. And other users gave you suggestion but you hang yourself to expecting error on our parts.

Have you did the installation in a virtual machine and building on one by one to see a fail point ? Don't think so

Have tried disabling cache, minify and gzip ? Same answer (I told you how).

If you have loose configuration that may interfere, then it may also be part of your problem.

No me, I'm bailling out. I'm sure you'll get help from others. Can't help someone who doesn't want to do some try out to resolve his problem. If you know the solution, then fix it. Workout yourself your own .htaccess . Look at the weekly download and only you get this.

[BlackTiger63]

With cache disabled, yes I did, ofcourse the error does not occur, but you should know that is a workaround, not a fix, the fix is to fix the .htaccess file.

OMG... You still ignoring the prooved fact that the .htaccess is blocking cache.php. Next to that, you still don't know the difference between complaining and reporting errors to make improvement. Great you're bailing out, you did not gave me 1 single solution, except 1 in cron which also contained a wrong commandline option. And I don't want to be helpt by somebody who thinks I do nothing to solve the problem while I've been looking for hours, contacting DA support and even found the solution to a script .htaccess issue. While you did nothing yourself, did not check error logs or even tried if I might not be correct. Only stating that it's my server, and it's mod_ruid2 while it's all not! I just explained, there are no problems, I explained how and why the errors occured, if you don't understand that, then you don't know nothing about a linux hosting environment. Please don't reply to my issues anymore, I'm fed up with your nonsense and denigrating reply's.

[polynamaude]

@BlackTiger63 Listen, the .htacces has nothing to do with the access of php files as those are called upon by PHP itself.

Next, the htacess looks to be a specific problem of ypurself. I operate a pH7Cms myself and be assured my logs are clean.

By the way, your friend wasn't the guy thinking we could remotely erase his database and complained that we should have waited he gets back from vacation to shutdown the server ? What a laugh he gave me. Feel sorry for those guy. Anyway don't forget that we have no obligation to you. You're the one asking help, not me. You should have thinked of giving feedback of what ypu tried. See ya

[BlackTiger63]

@polynamaude Next, the htacess looks to be a specific problem of ypurself. I operate a pH7Cms myself and be assured my logs are clean. Then your cache is not working, as you can see from as well the apache docs as the improvement marked by Ph7 that the .htaccess is blocking cache files or you have cache disabled or changed or used another .htaccess file. Clean logs do not always proove that nothing is wrong.

By the way, your friend wasn't the guy thinking we could remotely erase his database and complained that we should have waited he gets back from vacation to shutdown the server ? WHAHAHAHA! My friend has totally no knowledge of anything apache, mysql, .htaccess or github, he's like most users just a windows user with a hosting account. So no, he wasn't that guy. As you can see I've got a great laugh about that too. LoL.

As for the help, no you have no obligation, but also no need to be rude either. Keep in mind that the more the script grows, the more normal hosting users you will get, who will have no clue about anything. You might think of that when responding in the future. But you can expect more users like the one you mentioned in the future as the script will get more popular.

[pH-7]

@polynamaude If you tail /var/log/apache2/error.log you should see similar errors. @BlackTiger63 Caching files are read internally by PHP, without going through .htaccess. I'm not sure why you get them too. https://github.com/pH7Software/pH7-Social-Dating-CMS/blob/c4733ebc07871176583807072ee061502b1f289f/data/.htaccess is the improved and shorter version I just made. However, /data/.htaccess isn't really necessary (it is just there to improve a bit the security), so you can just remove it.

I'm closing this issue since it goes too big, no longer respects the courtesy rules and begins to be difficult to understand from the beginning.