On Tue, 14 Nov 2000, Leon Atkinson wrote:
> > 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.
Totally. I am just worried about all these new people setting it up wrong
(as they have been). But I guess as long as there is a clear warning in the
install file it's their mistake to make. Maybe instead of finding
APPLICATION_ROOT on it's own, FT should require the user to tell it where
the files are installed, with a clear statment saying it does not need to be
(and should NOT be!) accessible through the web server.
Personally I just put an .htaccess file in there denying access (which lets
me move whole copies of freetrade around easily while developing).
> > 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
>
> 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.
I have found ways to work around these (setting everything up so that is
assumes files are php files if it doesn't know what they are) but it's not
the best solution since it kinda messes other things up.
> 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.
Hmm. I didn't know that. Couldn't the global variables be declared global,
and still be used?
> 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.
Couldn't all the modules check for something that is defined in index.php?
And this only relates to the first concern, which should really be solved by
making sure people understand how freetrade is meant to be installed.
> 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.
I agree with you on this, though if that including function idea could work
at least you would never see it in the code. And you COULD have
extensionless files if you wanted them that way.
> 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.
What I REALLY wish I could do was to just tell my OS that everything is this
directory should be treated as php files, as that would solve all the editor
problems. All the editors I've used define languages according the file
extensions.
This isn't a huge deal to me (I do like the way the files look without
extensions), but it just seems like it makes sense to use extensions so that
it is clear (to computers AND people) what is contained in the files. As
PHP gets better support in editors, having the files identified as being PHP
becomes more useful.
- Isaac =)
(btw: I *love* syntax highlighting! makes everything so clear, and catches
those stupid typing mistakes, like leaving out a quote mark. the way the
program is built and it's flow just seems so much more obvious when
everything is color-coded.)
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Site: http://www.working-dogs.com/freetrade/
Problems?: [EMAIL PROTECTED]
