Fix for DomainSellerPro script not working

[crazyd]

Some of you may have the Domain Seller Pro Script shown here:

www.domainsellerpro.com

If your script WAS working fine, but now it doesn't work (eg, you can't log into admin, links dont work, etc), there is a reason for it. It is because your host has upgraded to PHP5 and now the way global variables are addressed is different.

The hard fix is to replace $a with $_GET['a'] in the admin.php file etc. (I will note here that I tried that, and it still didn't work, so I must have missed something)

Here is the EASY fix:

Instead of rewriting all the code (re: (2) below), what you need is a php.ini file in your directory (only in the www directory where your other domainsellerpro files are).

Open notepad, Save the file as php.ini and upload it.

The php.ini file should read simply:

register_globals = On

______________

Some more reading on all of this:

(1)http://drupal.org/node/210311
(2)http://www.issociate.de/board/post/280079/PHP_not_returning_variables!.html

So it is a 2 minute fix, real simple.

Leave all your original php files the same, no changes required.

Good luck all.

 

[Palyriot]

Bad advice. Don't enable register_globals. Just make the easy changes. It should take less than 2 minutes to fix the entire script. Enabling register_globals is a bad workaround.

Make these changes in admin.php:

Only change $a to $_GET["a"] where you see it in an if statement. Such as:

if($_GET["a"]=="importing" && $loggedin)

You also need to change:

$pass = (isset($passfromform)) ?substr(md5($passfromform), -10) : $pass;

to

$pass = (isset($_POST["passfromform"])) ?substr(md5($_POST["passfromform"]), -10) : $_GET["pass"];

You can also download the working admin.php. Just change the filename from admin.txt to admin.php

 

[crazyd]

Thanks very much Palyriot.

Those changes on the script did not work for me. Specifically, I was able to log into admin ok, whereas I couldn't at all before, but none of the links would work in admin or elsewhere.

Are you sure there are not files other than just admin.php that need updating? Such as index.php or others.

I am no expert on php, believe me. I guess the concern is that turning Globals on is a security risk, right? Someone could hack the site easily? That was my impression. If that is true, it seems someone would have to really have some time on their hands, and if you keep a backup of all your files, you should be ok I should think.

So I guess you are saying that even though my fix works, it is not safe to do so.

 

[Palyriot]

I fixed your script and everything works. Infact, I just tested it and all of the links worked.

 

[crazyd]

I fixed your script and everything works. Infact, I just tested it and all of the links worked.

Actually I put the original files back, and turned Register_Globals On, that's why the links are working now. With your fix, I could log into Admin ok, but the links still would not work.

I am convinced there is another file or files that need updating for your method to work. Possibly index.php or something. I got tired looking over so much code, though.

 

[Dotmainer]

Actually I put the original files back, and turned Register_Globals On, that's why the links are working now.

You leave your car open on the street ? :td:

-

 

[crazyd]

You leave your car open on the street ? :td:

-

Actually I do, yes. It's a good neighborhood.

Thanks for taking the time to make your comment.

 

[RJ]

Don't enable register globals on your entire server. Just add this line to your config_inc.php script in DSP, anywhere before the closing php ?> tag:

extract($_GET);extract($_POST);

Everything will work fine.

 

[Palyriot]

Don't enable register globals on your entire server. Just add this line to your config_inc.php script in DSP, anywhere before the closing php ?> tag:

extract($_GET);extract($_POST);

Everything will work fine.

That's just as unsafe as enabling register_globals. Practically does the same thing.

 

[Eric]

That's just as unsafe as enabling register_globals. Practically does the same thing.

register_globals = On, that's server wide (unless you're running PHP 5 and have the ability to add a local php.ini to the public_html or DSP directory).

extract($_GET); extract($_POST); , that's for the current script (in this case, DSP) only. As long as variables are sanitized, etc (which I'm sure RJ took care of - it's his script), everything will be fine.

 

[crazyd]

register_globals = On, that's server wide (unless you're running PHP 5 and have the ability to add a local php.ini to the public_html or DSP directory).

extract($_GET); extract($_POST); , that's for the current script (in this case, DSP) only. As long as variables are sanitized, etc (which I'm sure RJ took care of - it's his script), everything will be fine.

If you are running anything less than PHP5, then the script should run fine without any adjustment, right? That's the whole issue here.

I have a hostmonster account (multiple domains), running PHP5 (hostmonster has register_globals OFF by default), and so I put the php.ini only with the www directory files for that domain name, not the root account. That's why I thought security was not a big issue. I did not turn register_globals on for my whole server account, just the directory. I was frankly happy that the script worked with this solution.

But, taking RJ's tip, I deleted my 'local' php.ini file and put RJ's line of code in config_inc.php, and everything works fine, as he said.