How Many Free Months Can I Get As Compensation For The HUGE Amount Of Time Wasted...

[pfsmgh]

FYI: I checked to make sure this is posted in a private, not public area.

Most of you might already know Hostgator's default setting for Register Globals is ON, which is a very non-standard set-up.

1) FYI: Total Invoices 21 $199.01
2) In terms of traffic and bandwidth I have barely ever used my account.
3) I have over 150 addon domains, most all for test sites with no traffic.
4) Prior to the nightmare with Register Globals, I took the time to put a simple, but useful, .htaccess file in every addon domain. This file was to re-direct all "www" URL's to "no www"
5) All 150 + had to be hand-made, to change the URL to match the addon domain.

Please, watch what happens next:
(((quoting from support tickets, starting over 3.5 months ago)


ME) ...How soon can \'gatorxxx.hostgator.com\' have the register_globals setting turned Off?

Thank you.

Hg Support)

Hello,
The reason it is not conformed to the industry standard is because some clients require register_globals to be turned on. It is easier for us to have clients set this to off, then have everyone ask for it to be turned on. I am sorry that the information on the forum was unhelpful to you. I have set register_globals to off and symlinked the php.ini to every instance of it within your account.

Thank you for your business!

Please update this ticket should you require further assistance.


###########
Note: It took me almost three months to notice the damage which had been done (see my next reply for details)


ME) Hi,

Please, help me fully understand the solution.


1) I work on a test site on this account, which has many sub-folders.

2) Later, I download the files expecting to use them somewhere else.

3) The "symlinked php.ini" is now an actual copy of php.ini, and it is in every single sub-folder.

4) This can cause severe problems when I move the project to another host.

Based on my understanding of the situation, there seems to be a lot of extra work created in order to deal with your non-standard setting. I don't claim to be an expert, do you have any advice on dealing with a project that has many sub-folders plus the "challenges" already described?

Thank you


Hg Support) Hello,

If you'd like we can remove all of the php.ini from every sub directory on your account and create one single php.ini configuration file and place it into the root directory of your account '/' and disable the register_globals for all of the directories and sub directories in your account rather than have an instance in each directory. Then if you need to make any other changes to the PHP configuration you can simply modify one file and if you move the project to another host you will not need to worry about having all of these custom configuration's in each directory.

Please let us know how you'd like to proceed.

Thanks!


ME)

Yes, please do.

Thank you


Hg Support)

Hello,


We've removed all of the custom php.ini configuration files from every directory in your account and placed a single instance of the php.ini configuration file in the root '/' directory of your account and have disabled the register_globals in the file. We then added the following to the .htaccess file located in the public_html/ directory..


<IfModule mod_suphp.c>

suPHP_ConfigPath /home/example

<Files php.ini>

order allow,deny

deny from all

</Files>

</IfModule>

in order for the single php.ini configuration file to be used for every directory in your account.

If you need further assistance or have any other questions please let us know.


ME)
Hi,


I'm usually good at figuring things out, but this non-standard setting is a huge mess.


The good news: My blog and test forums are working.

The bad news: I have over 150 addon domains (mostly for test sites) and they all used to be configured for "no www" in the URL.

Now, I have over 150 domains with "500 Internal Server Error"


Here is exactly what I need, please.

1) For register_globals to still be off

2) To be able to use a simple .htaccess file, like this (for example)


RewriteEngine on

RewriteCond %{HTTP_HOST} !^example\.com$ [NC]

RewriteRule .? http://example.com%{REQUEST_URI} [R=301,L]


I'm shocked, and thinking a large amount of work got wiped out.

Thank you.



Hg Support)
Hello,


It appears that all of your add-on domains had this:

RewriteRule ^(.*)$ http://example.com/$1 [L,R=301]RewriteCond %{HTTP_REFERER} !^$



Which was causing the issue since the .htaccess files require a new line between rules. I have fixed this by inserting a new line, and I'm now showing that they are working:



http://domain.com/

http://sample.com/


Please let me know if there is anything else that I can do for you, or if you notice any issues.


############
EDIT:
FYI: My original .htaccess files worked fine, before these endless problems started.

ME) Hello,
Thanks for trying to help.

Issues:


1) All my .htaccess files are now a huge 56K, that is absurd.

2) my /image folders do NOT currently work (by default)


Question?

If I use this code in an addon domain for .htaccess (changing example to the domain name)


RewriteEngine on


RewriteCond %{HTTP_HOST} !^example\.com$ [NC]


RewriteRule .? http://example.com%{REQUEST_URI} [R=301,L]


...then will register_globals currently still be off?

or do I need to add something else to each .htaccess file??

I hope the answer is "Yes" (about register_globals still being off), and I unfortunately need to waste a HUGE amount of time recreating the 150+ small, simple, functioning .htaccess files I used to have.

Thank you


Hg Support)

Thank you for contacting HostGator.

Register_globals is off in your php.ini so this would mean it is off in your whole website. This code you pasted for the .htaccess file looks fine. As for the images folder are you meaning this one /home/example/www/images/? What errors are you receiving when trying to use the image folder? Also how are you getting these errors?

If you have any other questions, please let us know.


Summary:

I'm not an expert on php.ini and I slowly learned more as time went by.
Thanks for trying to help, but...

1) Your Register Globals ON is a security risk, and very non-standard.

2) Your support staff tried to help, (we remained very polite the whole time),
but I have wasted a huge amount of time.

3) Now I still need to waste more time re-creating over 150 small, simple, functioning .htaccess files (one for each domain)

How Many Free Months Can I Get As Compensation For The HUGE Amount Of Time Wasted.


Thank you.

[GatorWesley]

Hello,

Can you please provide a recent ticket concerning this? The most recent ticket I could find under your primary email address is: Ticket ID # JFD-3242453 which is from August.

[dwrunyon]

I will state while it is here that I too am very much bothered by the register globals thang.

I really do not understand the logic that we must ALL suffer for the totally non standard, insecure few... that is totally backwards to me. To tell you the truth I would very much prefer to hear Brent himself explain this one... I do not know much about it, but at least on the surface the situation defies common sense. I used the php.ini in root and htaccess rules combo just a recent while back.

[phototristan]

Me too. I know that there some some web programmers/designers who think HostGator is a haven for spammers and hackers just because the default for register_globals is set to on. It seems silly to have it default on when that is totally non standard and may in fact not be safe. Further, it makes people dis-recommend Hostgator.

[dwrunyon]

Originally Posted by phototristan

Further, it makes people dis-recommend Hostgator.

Just the other day, when I was gittin into the "deal with register_globals" mode, I actually canceled with HG and in the survey said I would NOT recommend HG because of this ONE problem... I did not want to just send folks in thare without knowing anythang about it. I did not know anythang about it, and if Drupal hadn't thrown up a warning about it I never would have. It strikes me as some seriously not good stuff. I personally am more or less satisfied with the solution I'm using, but do not believe that WE, the NON register_globals folks, should have to suffer in ANY WAY from those who "need" it.

I am curious as well as to exactly WHAT someone would need it for that it is so important that WE must suffer rather than THEM... the way I see it THEY should have to jump through hoops to get THEIR insecure, "rare" crap runnin!

[fanfavorite]

As per php.net, another workaround is:

PHP Code:

<?php
if (ini_get('register_globals') == 1) {
     if (is_array($_REQUEST)) 
          foreach(array_keys($_REQUEST) as $var_to_kill) 
               unset($$var_to_kill);
     if (is_array($_SESSION)) 
          foreach(array_keys($_SESSION) as $var_to_kill) 
               unset($$var_to_kill);
     if (is_array($_SERVER))  
          foreach(array_keys($_SERVER) as $var_to_kill) 
               unset($$var_to_kill);
     unset($var_to_kill);
}
?>

Just a note as well that in PHP 5.3.0 it has been depreciated and as of PHP 6 is completely removed.

I agree with getting registered globals turned to off by default, but don't agree with Hostgator having to compensate you for your time. They did more than they had to as a host. They decided to leave registered globals on, whether it was the right decision or not, and you were made aware of it. As far as I am concerned, it is our responsibility to make sure our sites functions properly unless there is a server failure or whatever that we cannot control.

[dwrunyon]

Originally Posted by fanfavorite

They decided to leave registered globals on, whether it was the right decision or not, and you were made aware of it.

How many though have NOT "been made aware of it" by just happenin to be the kind of person who checks out and searches the forums? The impression that I am gittin is that fer the average user that has no idea it is on or what it is er anythang, it's just sittin thare bein dangerous, is it not?

[fanfavorite]

Although people may not be aware of it, if they are writing in PHP, they should be checking the server configuration, which is very easy to see with a simple phpinfo(); tag or looking in cpanel for the basic information.

[dwrunyon]

Originally Posted by fanfavorite

Although people may not be aware of it, if they are writing in PHP

What about not WRITING, but just USING one of the many, many, many, many already written PHP thangs that ALL the kids are doin these days?

[fanfavorite]

Many scripts have support for both or at least have some kind of documentation that states about this issues. This is one of the reasons why some of my clients have come to our company rather than have their son/daughter or friend do their website. When working with scripting, whether premade or custom, you should be well aware of the settings on the server to make it function the way it is supposed to.

lol we could go on forever with this.

[dwrunyon]

Originally Posted by fanfavorite

lol we could go on forever with this.

No shit. But the bottom line fer most of mankind is that it is NOT on by default at ANY other host I have ever used, and I would suppose much of any other... there is OBVIOUSLY somethin not right about that... it aint just a unique little thang to set em apart from the pack... it is, by ALL EVIDENCE, a flaw in the way they have chosen to set thangs up, and we are voicin that. There is no need to defend a, agin, by all evidence, bad decision.

[fanfavorite]

Well I think Hostgator and the clients that want it turned on will have no choice. As per what I put above, it is depreciated in 5.3.0, which my server is running 5.2.8 and completely gone in 6.0. I think it would be best for Hostgator to start getting people to switch, since they will be forced to in the future.

In any case, I agree with you that this should be turned off, but I do not agree with the posted asking for compensation.

[cleanxhost]

How Many Free Months Can I Get As Compensation For The HUGE Amount Of Time Wasted?

You're having a laugh are you not?

[dwrunyon]

Originally Posted by fanfavorite

I agree with you that this should be turned off, but I do not agree with the posted asking for compensation.

Agreed!

[GatorJoshL]

Hello,

To clarify this, the reason that 'registered globals' is set to on by default is in PHP4, which was what all our servers had up until the migrations that we performed this year, had it on by default. Which means that many scripts that were installed required this to run, turning this off globally would break scripts that were already configured with the option on.

If you need registered_globals turned off all you will need to do is give us a call/open a ticket or live chat and we'll be glad to turn them off.

I just wanted to clarify why globals is on by default.


Thank you,

Josh Loe
Sys Admin

[dwrunyon]

Much appreciated... lookin forward to version 6! Though I see the conundrum, I would have, when 5 was made active, broke em... you'd have probably been doin them all a favor, and then, when they gite pissed and moved to another host, they would more than likely be off thare too, so they would have had to sit in their chair and stew in their own feces fer at least a couple of hours realizin that it was fer the best. To my mind, it would just seem most prudent to err on the side of those customers who are set up more securely, and have the ones who are wanting to run insecure crap jump through hoops rather than the "innocent" so to speak.

Bear in mind now, that I am not really complainin about MYSELF, cause I have mine all situated... but rather the totally fresh person to sites and hosting, who is probably more casual and all with it and would probably run a Fantastico install of somethin.

BTW, that brangs to mind right thare the curiosity of what happens to a totally fresh acct that tried to one click install Drupal... does the Fantastico system turn of the RGs or does it go ahead and install, and then throw up the errors when the user logs in fer the first time?

[striddy]

Auto spell check in the forum seems broken again, actually still.

[pfsmgh]

Originally Posted by GatorWesley

Hello,

Can you please provide a recent ticket concerning this? The most recent ticket I could find under your primary email address is: Ticket ID # JFD-3242453 which is from August.

1) Same ticket, this issue has been causing problems since August.

2) I used to have over 150 "hand-made" .htaccess files, which were small and useful (one for every addon domain.

3) Now I have over 150 .htaccess (created by your support staff) which are all over 53K. That is absurd.

Note: I generally like Hostgator, but this issue has been a HUGE waste of valuable time.

[mp3]

I'm still not entirely sure I understand what is broken, or why the files are so large...
The files now have either LF or CRLF characters at the end of each Apache config line? How does that increase the size (and why do you care about a handful of bytes?)?
Also, what is it that isn't working? It was never described in detail, but I'm sure someone here can point out the solution.

@register_globals
If you are writing scripts that need register_globals off to be secure, then your scripts are poorly written and are not secure.
That said, I always write with register_globals off.

Originally Posted by striddy

Auto spell check in the forum seems broken again, actually still.

Made me laugh.

[Teddy Rogers]

Originally Posted by GatorJoshL

To clarify this, the reason that 'registered globals' is set to on by default is in PHP4, which was what all our servers had up until the migrations that we performed this year, had it on by default.

Actually... to clarify register_globals has been OFF by default since PHP 4.2.0. So technically you have been switching it back ON for those servers running PHP 4.2.0 and above.

Having your customers use your servers requiring register_globals ON is a security risk. They may be prone to hackers injecting variables and values allowing them to take full control of their websites.

Your analogy of why it must be left ON is also wrong since you allow your customers to downgrade to PHP4 if they so wish. That means you should turn register_globals OFF by default for all the users who have migrated to PHP5. Most site software supports PHP5 and are not effected by register_globals. Anyone needing register_globals ON should be using PHP4.

No offence to dwrunyon, you need to take advantage of a spell checker or take up some English classes. Your spelling and grammar is atrocious...

Ted.