> 1. security - at least 5 times now i've been able to find out people's
> db name/login by requesting the "/modules/include/global_settings"
> file. without an extension, most servers send it as text. easily
> fixed, but it doesn't seem good to have FT install with such a
> big security hole.
But the real security hole is the people are mistakenly putting the modules
directory in the Web server path. This should never be done, even if
there are .php extensions.
> 2. file transfer - lets ftp clients know to use text or binary, etc.
>
> 3. syntax coloring - lets editors know what type of code is in the file
> so that they can color it correctly.
>
> 4. file type - on mac and windows you can tell the OS what program you
want
> to open the files with if they have an extension (on windows it uses
> the actual extension, on mac it adds creator info when you
> ftp/untar/checkout the files).
These are true, although they don't affect me at all. My FTP client has a
button
for choosing mode. I don't use highlighting. And I use file->open to edit
files. Maybe I'm weird that way.
> we could add a function that wraps include() and adds the file extension,
so
> that if the extension ever needs to be changed/removed it won't be all
> through the code.
>
> like:
>
> ext_include ($file)
> {
> include($file . ".php");
> }
>
> could maybe also do the double-include checking in that function.
Actually, I'm not sure this would work...consider that if you include a file
inside a
function, those variables would be created inside the function's scope.
Here's a reason for NOT using a .php extension. It could be worse for a
module
to be executed outside of the normal calling mechanism than to be displayed
in the
browser. The only sensitive file is include/global_settings, anyway. And
if you've
set up FreeTrade correctly, it won't be accessible. And if you've set up
MySQL
correctly, you won't be allowing connections from outside the localhost.
I also don't like .php on the end of the modules for the same reason I don't
like .exe
on the end of all the executables in /usr/local/bin. It's just kind of
ugly.
Anyway, like you said. It's been discussed on the list before. If anyone
has any new
insight into the issue, it should be interesting.
Leon
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Site: http://www.working-dogs.com/freetrade/
Problems?: [EMAIL PROTECTED]
