Thanks for the hint, now I have clarified it on cmsimple.com:Holger wrote:But I'm not sure if your users are aware about that.
http://www.cmsimple.org/doku/en/?Second ... d_Subsites
http://www.cmsimple.org/en/?CMSimpleCoAuthors
Gert
Thanks for the hint, now I have clarified it on cmsimple.com:Holger wrote:But I'm not sure if your users are aware about that.
Yeah, that sounds good!Gert wrote:Thanks for the hint, now I have clarified it on cmsimple.com:
Agreed. Something that should be documented prominently regarding CMSimple_XH.Gert wrote:Nested CMSimple(...) Installations (and CMSimple subsites) are only for users, they trust each other.
I believe it's possible to insulate multiple installations on different (sub)domains, though, by configuring seperate vhosts for each installation appropriately.Holger wrote:To make it clear (once again): using subsites (or multiple installations) is a security vulnerability by design.
Compressing files can be configured to happen automagically (see mod_deflate and zlib.output_*).Tata wrote: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.
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 wrote:If the user has no ftp access, you simply can make the template files "not writable".
Now CMSimple_XH also should place a warning regarding nested installations, on a prominent site on it's website,Holger wrote:Yeah, that sounds good!
Done.Gert wrote:Now CMSimple_XH also should place a warning regarding nested installations, on a prominent site on it's website,
Hm ... so why you have introduced the password encryption, if it is so easycmb wrote:After having acquired the password hash it is pretty easy to gain access to the "main site".
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).Gert wrote:Hm ... so why you have introduced the password encryption, if it is so easy
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:cmb wrote:It would be nice to hear the details of your solution
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...
My solution hack at 2009, CMSimple v3, was to do the following substitutions at cms.php:cmb wrote:I have to admit that I have no experience with intranets, and if there's a simple possibility to distinguish intranet from internet clients.
Code: Select all
// if ($t != '' && $t != $c[$s] && $t != 'remove' && $t != 'hide') {
// => if ($t != '' && $t != $c[$s] && $t != 'remove' && $t != 'hide' && $t != 'extranet') {
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]))))));
I don't want to depend on runkit. He might not be installed.cmb wrote:If there is runkit installed on the server
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!!cmb wrote: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.
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.jpafonso wrote:I simply added code in the li() function, to test for headings started with two quotes, something like:
[...]
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:jpafonso wrote: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).
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();
}
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.jpafonso wrote:From what I understood, 1.6 is quitting from presenting certain features, amputating the need to research solutions for them.