#1  
Old 17th October 2005, 09:59
Spum Spum is offline
Member
 
Join Date: Oct 2005
Posts: 39
Thanks: 0
Thanked 0 Times in 0 Posts
Default PHP cleanup

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 "?>"
Reply With Quote
Sponsored Links
  #2  
Old 17th October 2005, 10:20
till till is offline
Super Moderator
 
Join Date: Apr 2005
Location: Lüneburg, Germany
Posts: 36,011
Thanks: 826
Thanked 5,379 Times in 4,226 Posts
Default

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.
Reply With Quote
  #3  
Old 17th October 2005, 15:14
Spum Spum is offline
Member
 
Join Date: Oct 2005
Posts: 39
Thanks: 0
Thanked 0 Times in 0 Posts
Talking 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
Reply With Quote
  #4  
Old 17th October 2005, 22:17
Spum Spum is offline
Member
 
Join Date: Oct 2005
Posts: 39
Thanks: 0
Thanked 0 Times in 0 Posts
Default

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?
Reply With Quote
  #5  
Old 17th October 2005, 23:43
till till is offline
Super Moderator
 
Join Date: Apr 2005
Location: Lüneburg, Germany
Posts: 36,011
Thanks: 826
Thanked 5,379 Times in 4,226 Posts
Default

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.
Reply With Quote
  #6  
Old 18th October 2005, 16:25
till till is offline
Super Moderator
 
Join Date: Apr 2005
Location: Lüneburg, Germany
Posts: 36,011
Thanks: 826
Thanked 5,379 Times in 4,226 Posts
Default

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.
Reply With Quote
Reply

Bookmarks

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
[error] an unkown filter was not added: PHP Arien Installation/Configuration 12 7th October 2006 14:17
PHP not working jefash General 10 28th May 2006 08:48
Cannot compile new PHP with apxs olli Installation/Configuration 11 4th March 2006 15:32
Multiple domains jysse Installation/Configuration 2 10th August 2005 11:22
Apache + PHP lola Server Operation 1 25th April 2005 13:41


All times are GMT +2. The time now is 14:37.


Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2014, vBulletin Solutions, Inc.