From: Albrecht G. <alb...@ma...> - 2010-04-27 09:19:48
|
Hi Gustavo, hi David, Gustavo, thank you for the scetch of the possible solution on the ".htaccess" issue. David: can you please check this and give feedback to Gustavo? It is pretty urgent, since this is the last point we have to integrate beofre the release of 6.0.2 thank you and all the best Albrecht > since many people complain about the "DocumentRoot" limitation in the > installation of PHProjekt 6, for a better solution about the security, > there is an idea about to make 2 improves: > > 1. Make the configuration.ini file, a php file, so nobody can read it, > only the web server can execute it or read it. > > 2. Make a private folder for save there the logs, the temporally and the > uploaded files. (All the files written by the API/User). > > --- About 1. --- > The best solution that i found, is to keep the configuration.ini file as > format, add a <?php in the first line, rename it to configuration.php > and change the comments from ; to #. > There is a new Config parser, that just drop the first line, and take > the file as ini. > > Pros: > 1. The format is read friendly, like all the ini files. > Contra: > 1. Since is a php file, the common editor should provide a correct > interface for edit files, but since the ini structure is not PHP, maybe > the user have ugly messages in the editor. > 2. If you want to access directly to the file > http://p6/configuration.php => you will get a parser error. Maybe is not > a contra, but is ugly. > > --- About 2. --- > Here i want to discuss some scenarios. > First, the zip or the tarball, provide a folder phprojekt with all the > files and folders in it. > Currently the structure is: > phprojekt/ > application/ > htdocs/ > library/ > logs/ > tmp/ > upload/ > configuration.ini > And the limitation say that a vhost must be set to the htdocs folder. > > With the private folder, the idea is something like: > > phprojekt/ > application/ > htdocs/ > library/ > configuration.ini > private/ > logs/ > tmp/ > upload/ > > Scenario 1 - Common German structure: > If i drop the phprojekt folder in my public_html, then i have: > public_html/ > phprojekt/ > application/ > htdocs/ > library/ > configuration.ini > And the link to the API is http://my.domain/phprojekt/htdocs/index.php > In this scenario, the setup routine can try to create a private folder > in 2 places: > 1. in the same level as phprojekt. > Pros: The setup should can, since is a public folder with full access > to the web server. > Contra: Even if the private folder have a random name set by the user, > is accessible by web http://my.domain/private. > For solve that, we provide a .htaccess with Deny from all, but the > folder is still writable and public. > The user can set the write rights for this folder to "only owner"?, yes, > but ONLY in Linux, in Windows system, the folder is public and writable > (only the admin of the system can set the rights there). > > 2. Outside the public_html: > Pros: Is not accessible by Web. > Contra: > - The web user in general don't have access to write folders there, > or for rights or for groups limitation. If the setup routine can't > create the folder, the user/admin must do it. > If there are many problem for the common users to create a vhost, you > think that create a folder outside public is easy for them? > - If the folder is created, must have the correct right access, since > the API don't have right for change them, and again, the access system > works only for Linux, in windows is ALL 777. Do you think that the user > can do it? > > Scenario 2 - Personal systems: > In general, for the Scenario 1, we can use the DOCUMENT_ROOT var for > get the public folder, but for example, i have a windows system with > apache and the document root set on for example D:www, then i have many > sub folders for many pages. > My DOCUMENT_ROOT, is www, and the API will try to create a folder in: > - D:/www/phprojekt (in the same level as phprojekt) > - or in D: (Outside the public folder) > > Add to all this, if the server use safe_mode = ON, the API have problems > to access this private folder, depend on where is it. > > Also, if the rule is "no writable folders in the public one", what we > can do whit the application folder?. > Yes, we can make it read only, and add a private/application/ where the > user can add new modules. > But then the user can't delete the current modules like "Calendar" if he > don't want it in the system. > Also, we must change the routines that scan the application folder for > new modules, or custom ones, and we will have TWO applications folders, > one for the system and one for the users...if this don't generate > misunderstandings... > > For finish, i am agree with a private folder where we can write stuff in > a safe way, but reading the post, and the comments, there are many > "normal users" playing with P6, and are not "administrators", so maybe > this folder will provide more problems than solutions to these users. > > What do you think? > > If you want to test a bit, one of these implementations is in: > - http://github.com/gsolt/PHProjekt/tree/privateFolder > Works fine in windows, since don't try to set access, in Linux i tried > to install it in the MF server, and neither the API or myself, can > create a private folder with 0600 access in the before public_html. > > Greetings, > Gustavo > > > > ------------------------------------------------------------------------------ > _______________________________________________ > Phprojekt-devel mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phprojekt-devel |