Cidram: how to install cidram on site that uses .shtml

[bigalownz]

Server information.

VPS

CIDRAM version used (if known, please also include the exact commit hash).

CIDRAM version used: 2.4.4

Signatures version (if known).

PHP SAPI used

fpm-fcgi

PHP version installed

7.4.11

Operating system used

ubuntu 20.04

---

Issue

how do i install on a .shtml

Expected behavior

loads with no problem

Actual behavior

added this on top of page before
<!--#include file="/cidram/loader.php" -->

but get this
[an error occurred while processing this directive]

tried again with
<!--#include virtual="/cidram/loader.php" -->

and the login page for cidram shows up on top of page

[mikeruss1]

include this in .htaccess

ForceType application/x-httpd-php

or change file type to php, and the code

[Maikuolan]

I must confess, that I've never actually tried using CIDRAM to protect .shtml pages before, so actually knowing how to do it aside, I'm somewhat wary of any potential "gotchas", possible security implications, points of failure, etc that might possibly exist that I mightn't be aware of, simply due to never trying it before.

@DanielRuf Any thoughts about this in that regard (e.g., possible problems with the above suggestion, possible better ways to go about this, etc)?

My thinking is that mikeruss1's suggestion will most likely do the trick just fine, and achieve the desired end-results. I'm not sure offhandedly of a better way to go about having CIDRAM protect .shtml pages. I'll do some googling a little tonight or some time tomorrow though and reply back here again if I can find anything.

[DanielRuf]

shtml like html files are not processed by PHP. The solution by @mikeruss1 might work but might introduce new security related issues.

[DanielRuf]

See also https://stackoverflow.com/questions/839272/how-to-include-php-file-in-shtml-pages and https://www.virtualmin.com/node/36831

Normal PHP files are nothing that you want to protect and can not by default using PHP - except you tell Apache to load them with the PHP interpreter.

[DanielRuf]

Alternatively using simple CIDR rules in your .htaccess might be the better solution.

[Maikuolan]

Alternatively using simple CIDR rules in your .htaccess might be the better solution.

In that regard, I should mention that I do provide an .htaccess version of CIDRAM's default signature files, available here. However, important to note that, since it's .htaccess, it won't have the benefit of any of CIDRAM's default signature bypasses, search engine verification, social networking verification, the default "ignores" file, reCAPTCHA and so on. You're welcome to give it a try if you'd like, but if you do, I would strongly advise to at least briefly monitor your website's performance after doing so, to ensure there isn't any noticeable negative impact, and in general, to approach with caution (there's a risk of false positives, but due to the nature of requests blocked directly through .htaccess, there isn't generally much recourse available for those affected by said false positives to seek support or to ultimately resolve the problem). There are a few CIDRAM users I know of that also use the .htaccess file that I provide, but I don't use it myself at any of the websites that I maintain, due to the aforementioned concerns.

Of course, nobody is limited to just that, and it's pretty easy to make your own blocklists and .htaccess files if you've got some specific ranges in mind that you want to block. ;-)

[bigalownz]

Thanks for the help

The problem is not running php scripts in the .shtml file
just the login screen appearing

so adding

<Files *.shtml>
ForceType application/x-httpd-php
</Files>

to htaccess just downloads the .shtml file

I then tried changing in cidram.ini from disable_frontend=false to disable_frontend=true
and that worked

but then I can not login to cidram

and the .htacces version of cidram is not something i want to use

I just don't want to change the file from .shtml to .php yet

[DanielRuf]

ForceType application/x-httpd-php

Your hosting provider probably uses a different handler for PHP like ForceType application/x-httpd-php71. Please ask the hosting support regarding the correct handler directive.

[bigalownz]

that just downloads the .shtml file

i already have a php script running on the page so it not a php problem

[Maikuolan]

My suspicion is that the problem here (i.e., that the front-end login is always appearing), is that the "virtual" inclusion being done here is causing the code within the CIDRAM loader, responsible for determining whether CIDRAM has been loaded directly (i.e., direct access as per one would normally do to access the login page) or indirectly (i.e., hooked to a page as per one would normally do to protect their website), to come to the determination that it's being loaded directly all the time, even though it's being done indirectly.

The code in question:

    /** Checks whether we're calling CIDRAM directly or through a hook. */
    $CIDRAM['Direct'] = !isset($_SERVER['SCRIPT_FILENAME']) || str_replace("\\", '/', strtolower(
        realpath($_SERVER['SCRIPT_FILENAME'])
    )) === str_replace("\\", '/', strtolower(__FILE__));

Since the loader is the one particular part of CIDRAM which'll never be touched by the updater, we can (relatively speaking) safely edit the loader without worrying about our changes being overwritten by the updater.

What might be the best bet here, I think, would be to duplicate the loader (loader.php), so that we can split front-end access away from what we'd normally be hooking into to protect our websites.

In one copy, replace the above-cited code to this:

    /** Checks whether we're calling CIDRAM directly or through a hook. */
    $CIDRAM['Direct'] = true;

In the other copy, replace the above-cited code to this:

    /** Checks whether we're calling CIDRAM directly or through a hook. */
    $CIDRAM['Direct'] = false;

Use the one where we've changed it to true to access the front-end, and use the one where we've changed it to false for your hooks (coincidentally, you can rename both copies to whatever name you'd like, as long as they both remain in that same particular directly, and they should, in theory, both still continue to work as expected, though YMMV, so let me know if you give this a try and find it to not be the case).

[bigalownz]

just tried that

/** Checks whether we're calling CIDRAM directly or through a hook. */
    $CIDRAM['Direct'] = true;

still show the cidram login

/** Checks whether we're calling CIDRAM directly or through a hook. */
    $CIDRAM['Direct'] = false;

does not show cidram login
but cant login

[Maikuolan]

but cant login

Hm.. I'll do some thorough testing at my end either tomorrow or a little later during the week, to see whether I can figure anything out. We'll get to the bottom of it, I'm sure. :-)

[737simpilot]

Could some kind of hook be made in the PHP langue that then hooks the required shtml file? I don'
t know code at all, but since I run a hook that uses PHP that hooks both Ninjafirewall and CIDRAM together, I was thinking because the PHP code can do this, maybe it can do it for an shtml file in some fashion.

[bigalownz]

any update on this ?

[Maikuolan]

I've tried replicating the problem at my end exactly, including the suggested steps above, but I seem to still be able to log in properly at my end.

I wonder whether it might be a problem with cookies being accepted properly at your end, or maybe something has gone wrong with the CIDRAM front-end accounts file? Might be worth looking into, I guess.

Try deleting the /vault/fe_assets/frontend.dat file and logging in again, this time using the default username and password, and let me know whether that solves the problem. If that solves the problem, that would mean that the CIDRAM front-end accounts file must've somehow become corrupted (since resetting it fixed it). If that doesn't solve the problem, it must be something else instead.

As for the cookies possibility: You could try checking whether there's a CIDRAM-ADMIN cookie set at your browser for the domain in question. If it's set, then the CIDRAM front-end has successfully created a login cookie, so the problem must be something else. If not, then that might be the problem, and we could look further into that possibility. It might just be a matter then of adjusting the policy either for your browser or for your website/domain (depending on wherever the problem is exactly which is preventing it from being set properly). Also thinking about the cookie possibility, because I'm wondering whether CIDRAM being included virtually to an SHTML file might somehow be messing with it (but I'm not absolutely sure about it).

[bigalownz]

sorry i thing you misslead the problem
i can login in

the problem is when
<!--#include virtual="/cidram/loader.php" -->
is added to a .shtml file is show this

as you can see the login is at the top
also when some one is banned the access denied is at the top but the can see the rest of the page

[Maikuolan]

Ah, okay. That makes much more sense now. It seems that when PHP dies its own processing, it doesn't actually die to entire request, since it's just being piped back to the server to be "virtually included" by the server within the output for the SHTML page. Actually, that seems to be a problem, which is completely different than what I'd originally thought the problem was. '^.^

Not entirely sure how to solve this offhandedly. Maybe adding in some exit codes might help? Would depend on whether the server properly responds to exit codes, I guess. Might help, though.

I'll do some more research at my end.

[Maikuolan]

Actually, @bigalownz, mind doing me a quick favour?

Would you be able to open the vault/frontend.php file at your CIDRAM installation, and look for this bit of code, near to the very bottom of the file:

/** Exit front-end. */
if (empty($CIDRAM['Alternate']) && empty($UpdateAll)) {
    die;
}

..And then change it to this (adds an "exit code" to the main point of termination in the code for the front-end):

/** Exit front-end. */
if (empty($CIDRAM['Alternate']) && empty($UpdateAll)) {
    exit(1);
    die;
}

After doing so, test the front-end again, and let me know whether it changes anything (seems to fix it, seems a little better, seems a little worse, or seems exactly the same, etc).

If I know that this works at your end, then I'll know it works, and I can work towards coding it as a proper, configurable feature into CIDRAM, to benefit everyone. But, if it doesn't work, I'll know then to abandon that particular idea and continue researching alternative solutions.

Cheers.

[DanielRuf]

die and exit are the same method and do the same, these are just aliases ;-)

https://www.php.net/manual/en/function.die.php

I doubt that you can stop / affect the (s)html interpreter, unless you use the Sethandler solution to let the PHP interpreter parse the shtml file.

[bigalownz]

@Maikuolan that didn't work

[Maikuolan]

@Maikuolan that didn't work

Hm, oh well. Back to the drawing board then. Regardless, thanks for testing. :-)

[bigalownz]

I think I have got it working

Removed this from the .shtml file
<!--#include virtual="/cidram/loader.php" -->

Then add to the top of the .shtml file

<?php 
// CIDRAM
require(dirname(__FILE__).'/cidram/loader.php');
?>

In .htaccess file add

<FilesMatch ".+\.shtml$">
        SetHandler "proxy:unix:/run/php/php7.4-fpm.sock|fcgi://localhost"
</FilesMatch>

Then in /etc/php/7.4/fpm/pool.d/www.conf

Change
;security.limit_extensions = .php .php3 .php4 .php5 .php7
To
security.limit_extensions = .php .php3 .php4 .php5 .php7 .shtml

The restart php-fpm

service php7.4-fpm restart

I will do some testing over the next few days

(My server might be different than yours "ubuntu 20.04 php-fpm7.4”, so I don't know if it will work on other versions of php )

[Maikuolan]

I will do some testing over the next few days

Great to hear that you've (hopefully, fingers crossed) got it working! Looking forward to hearing how it goes. :-)

[bigalownz]

so far no problem running cidram with .shtml files
no higher server loads or any php etc errors

[Maikuolan]

Great to hear. :-)

I'll mark this as resolved and close it for now then, since it seems to be working okay now. If there are any more problems with it though, let me know and we can reopen it.