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 "?>" :)
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!
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:
For read access there is no password nescessary. I send you a email with the password for write access.
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
- 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! :)
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:
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:
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 :-)
|All times are GMT +2. The time now is 16:10.|
Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2013, vBulletin Solutions, Inc.