Tuesday, April 29. 2008Stupid open_basedir handling in PHPTrackbacks
Trackback specific URI for this entry
No Trackbacks
Comments
Display comments as
(Linear | Threaded)
There are several possible solutions to your problem:
1. Use relative paths and set up the systems accordingly.
2.Use a local configuration file that stores the path to the directory.
Both options are a better application design than the current solution (I presume you hardcoded all possible paths in your code and then check which one is the right one). Both solutions make sure that the application continues to work even when you install it on another 10 servers with different filesystem layouts. Solution number 2 makes sure you have to edit just one configuration file instead of having to modify the source code.
Comments (3)
Your "solution" is just a (not working) workaround.
Sometimes you can't change the directory layout because you don't manage the server.
In my case i have to hardcode the pathnames, because they are not inside my document_root (so relative pathnames would not work anyway) and if the directory exist, i have to change some environment variables based on the directory name. As a side note: if the directory would be inside document_root there is no need for adding the directory to open_basedir.
Yes, the directory name is hardcoded: if you have a configfile and some ppl are allowed to change the application, you end up with a situation where someone overwrites this configfile with other values. No good plan for the real world.
Comments (2)
That's not true. :)
Two possibilites: Either "some ppl" are allowed to change the source inside the document root. Then they can already do everything they want with the source. Or they are not allowed to modify the source. Then you just upload the correct configuration file for each webserver and you are set. No need to modify the source code or to check 5 (later 10, 20, ...) different paths to find the right one.
If you are afraid people will break stuff by having write access, remove it. If people set incorrect configuration values, they deserve to get an error.
And using a config file was just one example - the point was to make it configurable instead of hardcoding it in the application. You may want to store these deployment-dependent settings in a database. Where you store them is not the issue - just don't hardcode deployment-dependent data inside an application.
Comments (3)
seufz
The directory does only exist on one of the servers and in this case the path must go into a specific environment variable to make sure, an external program is catching up the right settings. So no need for source code changes with more servers.
About the write access: it's a (big) difference if ppl change some specific files they know about or if ppl modify the entire application. But then i should take care that changes in one version of this file work on all servers - your attempt will not do so.
By the way, i want to rant about PHP here ;-)
Comments (2)
Yes I know, you like to do that. Still, I do not think this is a PHP problem. It might even be documented that nonexistant paths are removed from the open_basedir setting (I don't know, but it does sound sensible, maybe it is even good for security purposes). The fundamentally wrong thing here is that you have a deployment (server) dependent setting in source code. It doesn't matter if you need it in the environment or how you use it, it should not be hardcoded in PHP source code.
And I agree with you, telling people to modify one specific, well documented configuration file is completely different than modifying source code. That's why I would opt for that solution. It can even be a PHP file. I see no reason why that wouldn't work or why that solution would be inferior to just hardcoding the paths. Care to enlighten me?
Comments (3)
|
QuicksearchBlog AdministrationPostgreSQL BuchCalendar
BookmarksCategoriesLast SearchStatisticsLast entry: 2019-02-03 14:34
957 entries written
568 comments have been made
26064 visitor(s) this month
335 visitor(s) today
141 visitor(s) online
Top Referersprohoster.info (122445)
sex-tale.ru (49738) xxx-rasskaz.ru (47335) vk.com (30105) blogos.kz (30103) ua.tc (30015) newporno.xyz (26737) blox.ua (25371) 2dm.prohoster.info (24280) link.ac (22459) Recent Entries
Archives |