CMSimple_XH 1.6 BETA

[cmb]

Hi João,

[...]
So, I'm a buyer to CMSimple_XH 1.6 argument that it is doable to install different CMSimples to each subsite (if needed), because I already did that. It is not nice or easy, but if that prevents complications, I understand it.

Well, please let me explain. The first subsite feature "prototype" was implemented in CMSimple_XH 1.5. This was merely a hack to augment the multilingual site feature. Rather soon it turned out, that there were several limitations and (minor) incompatibilities with existing plugins, however. CMSimple 4 has vitally improved this first "draft", but there are still some issues regarding the concept and some plugins. The basic problem is, that it's still not clear whether subsites models a multiple client capability (i.e. completely separated websites) or just the facility to divide a "large" website somehow. This affects the core functionality in a few cases (such as the search function) as well as (some) plugins.

I'm explaining all this (sorry if it is long), because, maybe you know more elegant ways to do that. Or if not, perhaps you find it enough interesting to discuss it to be included in the future, or even in the 1.6. The changes to do in the li() are minimal, about 3 lines. [...]

I'm not aware of a more elegant way to do that; the introduction of the $li parameter to toc() was meant to help solve such issues, but it may not suffice for all cases. It would be nice to hear the details of your solution (preferably in a new thread in the Open Developement forum.

so, I cannot substitute hide() without substitute the toc

If there is runkit installed on the server, you could replace hide() with a new definition (runkit_function_rename() and runkit_function_redefine() make it possible to override a function, somewhat similar to overriding a method in a subclass).

A similar concern I solved in the past with another hack, is to differentiate pages inside the cmsimple which are public, from ones which are only accessible through an intranet. Can you tell me if there is an elegant way (an add-on or a feature usable under 1.6) I can use?

There are the plugins Memberpages, Register_XH and Membersarea which allow to control access to certain pages based on user login (I'm not sure, if the plugins already could be used with XH 1.6 yet; Register_XH probably needs some modifications).

I have to admit that I have no experience with intranets, and if there's a simple possibility to distinguish intranet from internet clients. That might be reflected by the IP ($_SERVER['REMOTE_ADDR']); if so, it would be possible to modify one of the mentioned plugins accordingly (resp. reusing the necessary code/ideas in an own plugin). Basically, the intranet pages have to be marked somehow (for instance with a new page data attribute) and then the content has to be traversed to dynamically hide these pages for internet visitors. A rough outline:

Code: Select all

function hideIntranetPagesForExternalVisitors()
{
    global $c, $cl;
    
    for ($i = 0; $i < $cl; ++$i) {
        if (isIntranetPage() && externalVisitor()) { // these two functions will have to be defined
             // replace the contents of the page, hide it and send "403 Forbidden" response:
            $c[$i] = '#CMSimple hide# #CMSimple shead(403)#';
        }
    }
}

if (!(XH_ADM && $edit)) {
    hideIntranetPagesForExternalVisitors();
}

I'm fated to find bugs if there are ones

Thanks. It's always good to catch eventual bugs as early as possible.

Christoph

[Gert]

The basic problem is, that it's still not clear whether subsites models a multiple client capability (i.e. completely separated websites) or just the facility to divide a "large" website somehow.

Clear statement: Primarily it's made for Multi Client Capability, even if all clients are the same person

Gert

[cmb]

Clear statement: Primarily it's made for Multi Client Capability, even if all clients are the same person

I would appreciate to have a multiple client capability for CMSimple(...)--unfortunately, it is not possible (CMIIW). The problem is, that one cannot insulate the "subsites" from each other, as long as arbitrary PHP can be executed. For instance, one could insert in the template of a "subsite":

Code: Select all

<?php echo htmlspecialchars(file_get_contents('../cmsimple/config.php'));?>

After having acquired the password hash it is pretty easy to gain access to the "main site". Multiple installations of CMSimple(...) have the same vulnerability by default, but at least it's possible to insulate them from each other by configuring different web users for each "subsite" (what would probably require a v-server or a dedicated server, though).

Having the possibility to set up several subsites for a single (group of) user(s) seems to be nice, but it merely circumvents the limitations regarding the "maximum" size of the contents. In my opinion that should be solved in another way (the keyword is "scalability"--try to use CMSimple for a high traffic website).

Having a freely configurable mixture of both variants won't solve the first issue, and might lead the webmaster to false hopes easily. Furthermore it makes it harder for some plugins to work properly (e.g. Sitemapper_XH).

[Gert]

Clear statement: CMSimple(...) is not made for manage bank accounts

For instance, one could insert in the template of a "subsite":

Code: Select all

    <?php echo htmlspecialchars(file_get_contents('../cmsimple/config.php'));?>

To make it clear once again:

That's also possible with nested CMSimple_XH installations

Nested CMSimple(...) Installations (and CMSimple subsites) are only for users, they trust each other.

As long as the user is able to add php (or JS) code from the backend (for example by edit the template.htm), he can compromise the whole system. The best were, to remove the option "edit template.htm" from backend.

To edit the template from the backend is dangerous anyway, because there is no back button,

Gert

[Tata]

The best were, to remove the option "edit template.htm" from backend.

That's a point I agree with. I had a couple of pages around where the webmasters entered the template and/stylesheet and the website was gone.
I woiuld even suggest compression of the template and stylesheet. Maybe some semiautomatic uploader/installer wouild be good. There could be a function included, which would compress all possible files.

[Gert]

That's a point I agree with. I had a couple of pages around where the webmasters entered the template and/stylesheet and the website was gone.

If the user has no ftp access, you simply can make the template files "not writable".

If he has ftp access, he can do all anyway,

Gert

PS: not effective on servers, where you can edite files without writing permissions.

[Holger]

To make it clear once again:
That's also possible with nested CMSimple_XH installations

But the difference is, that XH or the XH-Developers not recommend installing subsites or nested installations, while you advertise

Clear statement: Primarily it's made for Multi Client Capability

To make it clear (once again): using subsites (or multiple installations) is a security vulnerability by design.

Holger

[Holger]

That's a point I agree with. I had a couple of pages around where the webmasters entered the template and/stylesheet and the website was gone.

If the user has no ftp access, you simply can make the template files "not writable".

If he has ftp access, he can do all anyway,

Gert

But you can make the same things with #CMSimple ...# Scripting. So that should be deactivated too .


Holger

[Gert]

To make it clear (once again): using subsites (or multiple installations) is a security vulnerability by design.

But you can make the same things with #CMSimple ...# Scripting. So that should be deactivated too .

Again and again and again:

Nested CMSimple(...) Installations (and CMSimple subsites) are only for users, they trust each other.

Gert

[Holger]

Again and again and again:

Yes, I know that.
But I'm not sure if your users are aware about that.

At cmsimple.org I can only find:

Multi clients ability (fully configurable and multilingual Subsites)

Subsites are working just like second languages​​, but they will not appear in the language menu. Subsites can also be multilingual.
Subsites are operated in a subfolder of the CMSimpleRoot, the copy template for subsites is the folder "2site", just copy it to your CMSimpleRoot folder and rename it.
Subsites should be installed in a folder with more than 2 characters, so they can be distinguished from the second languages ​​of the main installation.
The copy template for a second language of a subsite is the folder "2site2lang", it includes all necessary files. Copy it to your Subsite folder and rename it to a 2-characters folder (en, de, fr ...).

And advertising "Multi clients ability (fully configurable and multilingual Subsites)" sounds good, but could end up in a mess if one uses it really as advertised.

IMO the solution in CMSimple4 is far away from "Multi clients ability".


Holger