Index: [Article Count Order] [Thread]

Date:  Fri, 9 May 2008 14:46:09 +0100
From:  Michael Stauber <bq (at mark) solarspeed.net>
Subject:  [coba-e:12779] Re: site creation limit
To:  coba-e (at mark) bluequartz.org
Message-Id:  <200805091546.10509.bq (at mark) solarspeed.net>
In-Reply-To:  <48241C71.9040804 (at mark) zbronx.com>
References:  <48241C71.9040804 (at mark) zbronx.com>
X-Mail-Count: 12779

Hi Gustavo,

> I was wondering if anyone ever set an hard limit on how many sites can
> be created on BQ.
>
> Any pointers to where to start looking?

Yeah, I once created a PKG for that purpose on request of a customer. I 
couldn't really talk him out of it, because this is something that can't 
really be made fool proof and secure. II'll explain why further down.

What I built contains modified base-vsite RPMs. Those RPMs handle site 
management, creation and site listing. 

If you want to code it yourself, take a look at these files:

[root@cbq web]# rpm -ql base-vsite-ui|grep web
/usr/sausalito/ui/menu/base/vsite/siteweb.xml
/usr/sausalito/ui/web/base/vsite/adminList.php
/usr/sausalito/ui/web/base/vsite/advancedSearch.php
/usr/sausalito/ui/web/base/vsite/deleteAdminUser.php
/usr/sausalito/ui/web/base/vsite/manageAdmin.php
/usr/sausalito/ui/web/base/vsite/siteSuspend.php
/usr/sausalito/ui/web/base/vsite/suspendAdminUser.php
/usr/sausalito/ui/web/base/vsite/vsiteAdd.php
/usr/sausalito/ui/web/base/vsite/vsiteAddSave.php
/usr/sausalito/ui/web/base/vsite/vsiteDefaults.php
/usr/sausalito/ui/web/base/vsite/vsiteDefaultsSave.php
/usr/sausalito/ui/web/base/vsite/vsiteDel.php
/usr/sausalito/ui/web/base/vsite/vsiteEmail.php
/usr/sausalito/ui/web/base/vsite/vsiteList.php
/usr/sausalito/ui/web/base/vsite/vsiteMod.php
/usr/sausalito/ui/web/base/vsite/vsiteModSave.php
/usr/sausalito/ui/web/base/vsite/vsiteWeb.php
/usr/sausalito/ui/web/base/vsite/vsite_common.php

What you want to look at in particular are vsiteAdd.php (creates new vsites) 
and vsiteList.php (shows which sites are there and has the "create new site" 
button).

However: 

If you just modify the files yourself, the next BlueQuartz update might 
install a newer base-vsite-ui and replace your changes. So you'd rather build 
new RPMs and give them a ridiculously high version number which is a lot 
higher that the version numbers that BlueQuartz uses at the moment. That way 
BlueQuartz updates will never update your modified base-vsite.

BUT: This can *** of course *** get circumvented by the server admin.

The server administrator typically also has root access to the box by SSH or 
through (gasp!) Telnet. Or he can create extra-admins with such access. And 
those can "downgrade" your modified base-vsite by installing the official 
BlueQuartz base-vsite. Which would then remove the manually imposed maximum 
number of sites-restriction.

Or they could simply edit the PHP pages again and change the number of maximum 
allowed sites, as that number would have to be stored somewhere in the code. 
Or the code would tell where that number is found if it's in an external file 
or database.

I partially got that tackled with my modified base-vsite RPMs, as I encoded 
the PHP pages with IonCube encoder (hides the source code) and the maximum 
number of sites is defined by the presence or absence of specifically 
crafted "key" files (25/50/75/100 ... sites max.). No license file = 25 sites 
maximum and if you substitute the correct key files it may allows more sites 
to be created.

Still: The server admin could replace those RPMs with the official ones and 
get rid of the restriction. Even if you disable shell access entirely for 
admin/root he could take the official BlueQuartz base-vsite RPMs, rebuild 
them with a version number higher than yours, roll up a PKG and install that 
through the GUI. ;o)

Sooo .... generally BlueQuartz is way too open for such kind of restrictions 
and I therefore don't think it's a good or practical idea to do this, but you 
can of course give it a try if you want.

-- 
With best regards,

Michael Stauber