Well, i've noticed the frontend has a lot of stuff that if it was looked at a better way, would be much more clean, and scalable when it comes to say, adding a user, or deleting one, etc. So, i've decided , i'm going to start work on a "Beta" frontend, where the code is somewhat more scalable, and i'll try to implement some one the things i stated in the post before.. Anyways, for now -> There's a bug in \install_ispconfig\check.php, on line 30 it says "php?>", when it should actually just be "?>"
Hi, if you want to work on a new frontend you might want to have a look at the code i'am currently writing. It is the frontend that we have planned for a 3.0 release and is completely rewritten from scratch the last half of a year. The framework is finished about 90% and completely object oriented. Im currently implementing the visual form editor and the new plugin interface. I will make a SVN repository for the code and send you the Password so you may have a look at it if you want.
Excellent ideas The code i've started writing is mostly based on security, the current function's i've prepared are; * Per user salting * Per user encryption * Dynamic encryption * Dynamic salting. Per User Salting Per user salting is similar to a captcha, but it's a salt that is unique to the user, and is what is appended to the actual password they input, before being hashed into the tables. Makes it a lot harder for people to spot some kind of pattern within your MD5, and makes it more resistant to Rainbow Tables, because it's not an "actual" string that is easy to guess. Pretty secure because even if one user gets hacked, because everyone's salt is different, really, it's like cracking your customers passes one at once, because of differential patterns. Per User/Group Encryption Well, if you've got higher end customers, such as resellers, perhaps you would want to increase some form of security that goes to all their accounts, and sub accounts. The idea is pretty simple, and that is that you store the user/group encryption type, and then query it before the user's login details are used. Pretty simple, but again , effective, because then there are levels of "defence" against cracking. Again, these using dynamic salts, is pretty DARN hard to crack, even by a cryptographer's standards! Say you almost crack it.. Next day. or next logon.. completely new pattern, salt, key and hash.. Unlucky! Dynamic Encryption This would be, i guess most useful for administrator accounts. The idea is that the encryption type or hash salt, changes after each session timeout. This means that it randomly saves the encryption type for one day, or however long the session is set to die in, then it changes. This is perfect, particularly if it's one user, because you can ensure that your password is never left there for excessive amounts of time, and left open to be started to be cracked-on, which is pretty "paranoid", i know, but it's just a thing perhaps others have. So, with this, it means that the way your password is being hashed or encrypted is changed everyday.. Obviously, if there is a vulnerability found in one, there'll be a control panel section from which you can "disable" certain methods, until they are re-changed. Maybe, you may be thinking - "If it's random, how will we know how to validate it?" Well, it's not random in a way we can't control. When the admin logs on, the encryption type is selected at random, then stored in a table, where it can be queried from, if it's needed to encrypt or decrypt the password once again.. This means that yes, if you want to, you could even make it force you to log on every x minutes after your session dies, with a new encryption type once again. I personally, have used these methods, and although the latter may be thought of as excessive for some .. For those who want the highest level of ensurance that they well be secure, this is quite adequate, indeed
For the code, can you email it to me.. also, if i can enhance the code, am i okay to go ahead with that? or must i notify you?
I am just cleaning up the code a little bit, translate some comments i made in german to english. I hope i will finish it tomorrow. I will send you tomorrow the SVN access to the repository so you can access the code directly.
You can get the code for the new framework from here: svn://svn.ispconfig.org/scrigo/trunk For read access there is no password nescessary. I send you a email with the password for write access. Installation: 1) Copy the code to a php enabled webserver, the framework is tested on windows and linux with php4 and php5. 2) Create a mysql database and insert the sql dump that is in the sql directory 3) Edit the database and path settings in the file lib/config.inc.php The login is admin:admin Status: - The base framework is finished and i added some empty modules. - The module editor is working, the forms editor is work in progress. But the form definition files can be edited manually as well. - Today i will make some demo forms, e.g. the clients form to show you how things can be done with the scrigo framework. What I want to do the next days: 1) Finish the datasource feature for form elements (checkbox lists, option fields, etc) so they can get filled with data automatically from sql database queries and from custom functions. 2) Finish the code for the validators for form elements, currently only regex validation is supported 3) Implement the plugin feature, so custom form elements ca be implemented as plugins I will try to make a roadmap for ISPConfig 3.x and put them on the forum for discussion.
The code really hasnt been dramatically changed ... What i meant was a complete rewrite of the system, the idea being that all the requests would go through central page parsers, so that everything is handled, and secured through a singular page, which would mean "anonymous" URL's, and direct action logging through the headers being sent to the main page parser. With this in place, it'd be so much easier to then put all the other systems in place -> the encryption and whatever. Although, i'm still juggling with the idea which is more secure -> actual accounts within the Operating system, or accounts in Tables, of course, with tables, they could be individually and dynamically encoded, or hashed so there's a security bonus in that, and that their secluded away from the actual system. Hmm, i'll work on it, but at the moment, i'm working on the installer to interactively & automatically download the components after wget is installed, so that the versions are the latest, and that the people don't have to download the entire package with things they may already have installed so, back to work on that, then i'll get cracking on the frontend & webapp installer! Regards, The spum
The code was completely rewritten from scratch, the only code that has "survived" is the code from the database wrapper class. Also the scheme how data is parsed and the dataformat for the forms has changed... All requests for forms are handled by a central class. The file is lib/classes/tform_actions.inc.php with the helper class tform.inc.php I assume you've looked at e.g. the user forms, they are written "by hand" because the event based framework was not finished as i needed them. Currently a form page only includes these lines: PHP: require_once('../../lib/config.inc.php'); require_once('../../lib/app.inc.php'); // Defining the form definition page. // These pages includes no code, only the definition as PHP array $tform_def_file = "form/test.tform.php"; // Loading classes $app->uses('tpl,tform,tform_actions'); // let tform_actions handle the page $app->tform_actions->onLoad(); I will make a better demo page for this and put it on SVN. The big plus of this approach is that you dont loose the flexibility and the pages can be extended in an object orientd manner. If you want to e.g. overwrite the form show event handler to add somthing that can not be handled by the base framework and is only needed here, you can add before the onLoad() call: PHP: class custom_action extends tform_actions { function onShowEnd() { global $app, $conf; // Do some custom things here // parse template $app->tpl->pparse(); } } $app->tform_actions = new custom_action(); $app->tform_actions->onLoad(); I agree with you that there must be a central place where all this is handled for security reasons, and that is why the new framework was developed. If you implement the encryption in the file lib/classes/tform.inc.php it will apply to all form pages automatically. In this class is also the datalog function, this records all the actions taken on the different database tables. You can use it as undo function, security log for the admin and the datalog can also be replayed on an external database. This sounds really good. Does the installer then detect also the current version of an installed application in update mode and skips the compilation if it is not newer?
Well, it works so far, it's still not finished, but it works quite well.. I'velisted the "core apps" which need to be installed, and the others are optional apps (postgresql and so on). But yep, working well so far I just made it for PHP that there are core modules that it must be compiled with, but the user can select what it gets compiled with, depending on what packages they have selected, and such and such As for the "web" thing; It seems alright, but i'll take a look around it when i've got free time after completing these things. The next thing i'll work on is the "fantastico" style app. All i'll need to do is compile a list of web-apps, and then find out what configuration they require.. I've already done it with eg; phpbb,drupal, mambo and so on, but the idea i wanted for it was; 1) System downloads / user downloads supported version of x webapp as tar.gz 2) Whenever the installation is requested from user or admin, then the script uses exec to tar it into the user's dir as they specified, and uses the config info they inputted to replace config files, and then the app will run perfectly ;-) I have an "alpha" of this that i already tried out.. Seemed to work perfectly well, just with exec and mySQL/postgreSQL functions in PHP. Another idea that may be good, is to list the features that other HCP's have, such as Plesk, Ensim, and cPanel, and then see if we can go above and beyond that.. If i'm given a TODO list, i can get cracking on mostly anything you throw at me, so it would be a good idea to do this, i think
