Is the location of the app directory configurable such that it can be removed from web space? I don't like it there since it contains configuration information such as db user and password. Granted an .htaccess protects it, but still... better that this information not reside in web space.
Via Alan Storm, where all this is set up...
You would have to figure out how to create an overwrite module for app/code/core/Mage/Core/Model/Config/Options.php and test it really thoroughly on a development system to make sure it won't break anything.
As it's something that is more or less a part of Magento bootstrapping, it probably gets instantiated well before the Magento code that actually allows a module to be read and loaded.
I appreciate your many replies to posts I've made, chiefair.
I'm left wondering why this would not left to be easily configurable via the magento admin control panel.
Where do you want your crons to reside?
Where do you want your configs to reside?
I see a lot of files in web space that just shouldn't be... configuration files contaiing db passwords and cron scripts (cron.sh/cron.php). Why would I want cron scripts open to the world to run? These aren't even in an .htaccess protected directory like the xml file with the db password. They just sit there in open web space.
I don't really see why you want to move the app folder away from it's original location. When you configure your server correctly and set the right permissions, all outside access will be denied by default.
Here are the permissions that work for me most of the time:
- All folders have permissions 775
- All files have permissions 664
Never set the permissions of any file to 777!
And FYI, the app folders are declared in this file: app/Mage.php
Arjen... UNIX file permissions and public web access are two different things. Unless you block read access for the user under which the web server runs, then any file with read access by the web server user can be read, or executed with execute permission. But the web server user has to be able to read the xml config files and hence will happily serve them if the web server is not configured properly.
I would very much recommend you understand web server configuration in order to understand this thread well.
It is just good standard web security that such files containing passwords not be in web space. You wouldn't put /etc/passwd or /etc/shadow in web space whether you chose to protect them with an .htaccess file or not.
Then further, for a cron to be in web space is absurd.
It's an issue mentioned by many a seasoned web app builder who questions the need for the executiable code to be inside the web doc root.
Basically it was a decision made a long time ago by Varien to make an easily installable e-commerce website application in hosting accounts where you only have access to doc root.
The only protection you have is .htaccess files and ownership/permissions. Magento has a couple articles somewhere on doing an extreme lockdown which very few people ever put into practice.
Secret: It's not the one posted up there...
So if you're running nginx, IIS, etc. and you don't understand the need to replicate what all those .htaccess files do, you're running in a state of non-security.
Somewhere in the old version of this website, there was a recommendation to remove the .htaccess file in the `media/` folder to get Magento to function on some hosting providers like GoDaddy. Go read the thing and ponder on what it does, think about having user uploads enabled and that the `media/` folder by design must give access and often is set 777 due to the web server owner/group being totally different from the hosting account owner/group.
Oh... easy to install it is and I can see that angle.
If it's not easy to get up and running, it doesn't get the desired amount of playtime. That's certainly seems to be the goal... get it in use and beware those not keen on looking for the necessary improvements.
I have full control of my UNIX servers so doing what I need to do isn't a problem. It's basically doing it in such a way that is appropriate for magento and not a hack so that future upgrades don't blow away my changes. Granted, it provides a very nice configurable front end tailored to ecommerce.
I'm wondering what lurking problems I'm setting myself up for if I choose to move to magento without understanding all these gotchas.
If you don't mind be asking... do you use magento chiefair?
Do you happen to be a magento developer?
We run it on our company's e-commerce web server. From a network IT background with Linux experience and C/perl programming from a previous website, I became a developer/website administrator in order to salvage a website software conversion horribly gone wrong that I inherited.
Funny how a lot of Magento Manager/Developers are created via that route.
The original hired developers bit off a chunk too large for their intended software platform, said oooh, shiny Magento says it can do amazing things, lets switch horses in midstream and hacked it into function with a dwarvish war axe. I spent the next two years hunting "Closing div exists in template xxxx comments" and returning Magento to its proper template structure so it wouldn't blow up every time my partner added or changed content. And refactored code until upgrades became possible without destroying the website. It was pretty gruesome getting there. Wish I'd inherited a pristine site <grin>.
Any comment on Enterprise vs Community? Any experience with Enterprise? One example given that we're just getting our feet wet with Magento here... We're doing a product import and it appears to be loading a product at about 1 product per second!!!
If I get the same performance loading my customers... it's probably going to take a couple of days to import. Somethign can't be correct there. Does Magento throw some "sleeps" inside the community version?