Lack of Shared Server Support?

[monizzle]

As I understand it, there is no way to install osCommerce on a shared server where the host is properly looking after security issues.

 

In other words, quoting from a previous post, "an osCommerce install requires that register_globals variable be set in php.ini to ON, or 'IF' allowed in httpd.conf, .htaccess the sever has to have 'AllowOverride Options' or 'AllowOverride All' set in httpd.conf"

 

I am 100% new to PHP so I am taking my web host's word that these are real security issue and their policies cannot be amended. However, I am not new to web application development or the needs of small business.

 

Is there any way to get osC installed on a server with such restrictions? If not, consider making some changes. Small businesses rely on shared/managed hosting because of workload and revenue issues. A HUGE number of sites run on shared servers. Making this app available to the broadest range of developers seems to be in keeping with the ethos of the PHP community.

 

If I am wrong and I *can* get osC installed with these security restrictions, I would greatly appreciate someone pointing me in the right direction. GREATLY. If I am right and someone knows of another app which meets my shared server reqs, I would greatly appreciate someone pointing it out as well.

 

Either way, congratulations on an interesting collaboration.

[Guest]

The register_globals issue is currently being addressed (in fact, I think that the current CVS supports having it turned off for the catalog area; admin not started). However, I would still shy away from a host that tells you that having register_globals enabled is a security issue for *them*. If they are so badly misconfigured that miswritten scripts can endanger their setup, think what a cracker could do with a *legitimate* account (they sell to anyone with a credit card, right?) with *intentionally* malicious scripts. Any host that incompetent should be put out of business. More likely, they just don't understand the issue--not exactly a ringing endorsement of their competence either.

 

Having register_globals on is only an issue if you write bad code (in particular, if you do not initialize variables prior to use). Even with register_globals off, it's still bad code. Register_globals just allows a certain category of exploit on that bad code. Without the bad code, no exploit. Even with the bad code, all it's doing is changing a variable that you might use. This can break things in your code, but unless your code is running with high privileges, it shouldn't be able to do anything to the server nor to anyone else's site. As I said in the first paragraph, a host that is so badly run that they can't even protect from accidental issues in script is never going to be effective against actual malicious attempts.

 

More info on register_globals here.

 

Still, register_globals should not be needed. It is perfectly possible to make the site in such a way that it is circumvented. As I said at the top of this post, osCommerce is currently moving from a system that requires register_globals on to one where register_globals can be off. Most (if not all) of the catalog side is done. At some point in the future, the admin side will get done as well.

 

You can get more info about current changes planned for osCommerce by looking at the workboard.

 

Hth,

Matt