CMSimple_XH 1.6 BETA

[Gert]

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

Thanks for the hint, now I have clarified it on cmsimple.com:

http://www.cmsimple.org/doku/en/?Second ... d_Subsites

http://www.cmsimple.org/en/?CMSimpleCoAuthors

Gert

[Holger]

Thanks for the hint, now I have clarified it on cmsimple.com:

Yeah, that sounds good!


Holger

[cmb]

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

Agreed. Something that should be documented prominently regarding CMSimple_XH.

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

I believe it's possible to insulate multiple installations on different (sub)domains, though, by configuring seperate vhosts for each installation appropriately.

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.

Compressing files can be configured to happen automagically (see mod_deflate and zlib.output_*).

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

Yes. However, in the current versions there will be always a warning saying that the template file is not readable. In CMSimple_XH 1.6 this warning will only be shown when the user actually tries to save the template or when he has a look at the system check.

[Gert]

Yeah, that sounds good!

Now CMSimple_XH also should place a warning regarding nested installations, on a prominent site on it's website,

Gert

[cmb]

Now CMSimple_XH also should place a warning regarding nested installations, on a prominent site on it's website,

Done.

[Gert]

After having acquired the password hash it is pretty easy to gain access to the "main site".

Hm ... so why you have introduced the password encryption, if it is so easy

Gert

[cmb]

Hm ... so why you have introduced the password encryption, if it is so easy

The hashing of the password since XH 1.5.4 is meant to avoid that an attacker can obtain the clear text password, what may be used by the admin for other accounts as well. Obtaining the password hash "only" allows access to the CMSimple administration, by simply setting the respective cookie. This will be furthermore improved in CMSimple_XH 1.6 by not storing the password hash directly in a cookie, but in a session variable (as it should have been from the beginning, i.e. since sessions were available; not sure when they have been introduced).

[jpafonso]

Hi, Cristopher (Hi Gert, Hi Holger, Hi Tata)

Sorry, I forgot to check the follow-up to my Sunday message.

It would be nice to hear the details of your solution

I'll do it in the proper channels in the suggested Open Developement forum, once I know more of the site, but for now, and just to not break the flow of the conversation, I'll explain it here. I simply added code in the li() function, to test for headings started with two quotes, something like:

Code: Select all

    if (!strncmp($h[$ta[$i]],"''",2)) {
      $t .= dynamicMenu($h[$ta[$i]]);
    } else {
         ...the usual code to insert the <li> tag contents here...

Is that simple. I didn't even tested it against other uses of toc(), but for now,it works. dynamicMenu() is a costumable function who will expand the weird tag started by '' into whatever menus we want. Of course, whoever programs it, must know what he is doing, but then again, this is for the cases where we want to have something not possible the usual ways, and need more expertise.

I have to admit that I have no experience with intranets, and if there's a simple possibility to distinguish intranet from internet clients.

My solution hack at 2009, CMSimple v3, was to do the following substitutions at cms.php:

Code: Select all

//     if ($t != '' && $t != $c[$s] && $t != 'remove' && $t != 'hide') {
//  =>     if ($t != '' && $t != $c[$s] && $t != 'remove' && $t != 'hide' && $t != 'extranet') {

in what would be today, I suppose, evaluate_cmsimple_scripting(), and in hide(), to do the following:

Code: Select all

//    return (!($edit && $adm) && cmscript('hide', $c[$i]));
//  =>    return (!($edit && $adm) && (cmscript('hide', $c[$i]) || (!ereg($regExpIp,$_SERVER['REMOTE_ADDR']) && (!(cmscript('extranet', $c[$i]))))));

Here, $regExpIp is placeholder for a regular expression defining the IPs of the machines to which applies the property "intranet'.

Basically, this is an "hide" behaviour with a condition. If we don't write a #cmscript extranet# token inside a content, it will not appear to the outside. Formerly, I implemented a "intranet" cmscript, but this way, the page is not show to the public by default (saving embarrassments if we forgot to add the intranet tag).

This solution is much more milder than yours. The idea was not to block content but to avoid to clutter the interface with information not needed "outside". This solution had the same security loopholes as "hide" (if hide has any).

If there is runkit installed on the server

I don't want to depend on runkit. He might not be installed.

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.

I agree with Gert here, to maintain some simplicity in the design, we need to trust. The obvious answer to your basic problem is to keep the subsites model where there is "trust" among subsites, and create different sites where that is not possible. So, if site A, B and C are made by the same person or there is no danger in the sharing of information between sites (to be more precise, if it doesn't matter if site C won a life of his own, and start to prey on the other ones), then they can be in the same installation. If not, different installations!! Or if we want A, B and C to be assuredly safe, despite we know they fulfill the previous conditions, different installations!!

That being established, we can concentrate in create bridges between subsites without concerns for security. To research for a multi-site search function for example. Security will not be a concern because their lack will be a feature: if we wanted to do things safely, we would have put things separately. So, only sites we trust will go together and only them will be able to use the inherent unsafety to their advantage.

I apologize for stepping in with these opinions. It is clear that you have all been thinking about this for a long time, and I should have read those arguments first. From what I understood, 1.6 is quitting from presenting certain features, amputating the need to research solutions for them. I'm trying to foreseeing what may compensate that loss. A language in the spirit of AREXX between CMSimple installations might do the trick, putting CMSimple sites talking to each other, exchanging info when needed. For the case of multipart sites, or sites so big they need to have the content.html page separated, I think it is not that difficult to maintain several content files, each with its own content, if every content page maintains a full copy of the pagedata.php info (that's a bad side effect of joining the two, the content.html with the pagedata.php... I imagine that before, you could use one pagedata.php for several different content pages).

I'm sure that if I explore the forum, I'll find much better ideas.

Best regards,
JPA

[cmb]

I simply added code in the li() function, to test for headings started with two quotes, something like:
[...]

Ah, I see. Something similar is done by Advanced TOC. We may consider to extend li() in this direction, but actually, I would prefer to completely rewrite the whole toc()/li() stuff--IMO it's much too hard to understand what's going on there--however, not for XH 1.6.

This solution is much more milder than yours. The idea was not to block content but to avoid to clutter the interface with information not needed "outside". This solution had the same security loopholes as "hide" (if hide has any).

Well, I'm not aware of any security issues regarding #CMSimple hide#--it simply hides the page from the menu (and sitemap etc.) If one knows the page's URL, he can access the page nonetheless. Anyway, you may use the following in userfuncs.php to avoid modifying the core files:

Code: Select all

function hideIntranetPagesForExternalVisitors()
{
    global $c, $cl;
    
    for ($i = 0; $i < $cl; ++$i) {
        if (cmscript('extranet', $c[$i]) && !ereg($regExpIp,$_SERVER['REMOTE_ADDR'])) {
            // hide the page:
            $c[$i] = str_ireplace('#CMSimple extranet#', '#CMSimple hide#', $c[$i]);
        }
    }
}

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

Note, that str_ireplace() requires at least PHP 5, and that ereg() is deprecated.

From what I understood, 1.6 is quitting from presenting certain features, amputating the need to research solutions for them.

Indeed, as IMO there are much more important issues we have to deal with. CMSimple is a nice system, but there has not been any (well, only very few) development for years, and that shows up in many areas. I consider it of utmost importance to bring the code base up-to-date and to employ contemporary software development practices. CMSimple_XH 1.6 is only a small step in this direction, and even that took a lot of time.

[Bob]

Great beautiful work, guys! Tests and the translation of files in French are in progress...
Still congratulations.
Bob