Jump to content
  • Checkout
  • Login
  • Get in touch

osCommerce

The e-commerce.

Register Globals Support


Guest

Recommended Posts

  • 3 weeks later...
  • Replies 280
  • Created
  • Last Reply

Top Posters In This Topic

I've put up v 1.2 of this contribution.

 

The main thing it adds is correct support for easypopulate - it actually works now !

 

See the CHANGE_HISTORY_FILE for details of what else has changed.

 

There's a reasonable chance that I'll get to look at some of the other problems that have been raised in the next few days, so there might be a v 1.3 pretty soon too

 

By the way, I tried to look at what other people had added (there are three updates to my last v. 1.1.1 contrib), however, they are all zip files and I can't seem to be able to unpack any of them - I just get errors.

 

Looking at some of the other posts here, other people seem to be having the same problem !

 

regards,

 

Richard Bentley.

Edited by CMOTD
Link to comment
Share on other sites

I have put up v 1.2.1 of this contribution

 

It includes some more fixes (well, it would, wouldn't it ?).

 

If you have any more problems, let me know.

 

Also, if I have not addressed a problem that has been posted here and you STILL have a problem, then let me know.

 

IMPORTANT

-------------------

If you post a problem report to this forum (or if you contact me directly), PLEASE say what version you are using (and don't just say 'latest' - give me a number !!)

 

regards,

 

Rich

Link to comment
Share on other sites

  • 2 weeks later...

Hello CMOTD

 

I need this mod cause my shared ssl space need the registar globals of.

 

However, do you have a Zip of the latest one which i can install i dont know how to open tar.gz

 

Am dumb as well so is it ok to install, i thought i wouldnt be able to do anything because of this registar globals thing had to change to a linux to get site going now need it to get ssl working ok.

 

Thanks for any info :)

Link to comment
Share on other sites

I can make you a zip file if you like, but you shouldn't need it. If you are using Windows, then you should find winzip can handle tar.gz files perfectly well (certainly version 8.1 SR1 does).

 

If you are using unix / linux, then you can uncompress it with....

 

tar -xzf whatever_i_called_the_file.tar.gz

 

Let me know (PM me if you like) if you still have a problem and I'll email you a zip

 

Rich.

Link to comment
Share on other sites

Sorry - misread the question....

 

How do you get to php.ini ???

 

If it's your own server then you ought to know where you put it !

 

If it's a shared server (supplied by your ISP) then you almost certainly can't; you are stuck with what the ISP sets ! They may not even let you see the contents (either because they can't be bothered to set up the mechanism to let you or because they are just being mean-spirited)

 

Rich.

Link to comment
Share on other sites

I'm still getiing the same error as mentioned a while back on this thread by someone else:

 

Fatal error: Call to undefined function: tep_session_save_path() in /freeola/users/3/4/sr0087843/htdocs/catalog/includes/application_top.php on line 142

 

Line 142 reads as follows

 

tep_session_save_path(SESSION_WRITE_DIRECTORY);

 

Using a new install of osCommerce 2.2 milestone 2 and the patch v1.2.1

 

Any help would be appreciated

 

Thanks

Link to comment
Share on other sites

I've looked at this and can't see anything in the patching instructions that might lead this to happen.

 

So....

I suppose the obvious question is "do you have the function 'tep_session_save_path' defined in .../catalog/includes/functions/sessions.php ?".

 

Unless you have moved things about, it should be the very last function in the file. If it's not there then I would suggest you add it back in - the instructions don't say to delete it

 

Feedback on this would be appreciated.

 

Rich.

Link to comment
Share on other sites

The funtion is in the correct place in the code, which is strange.

 

For the time being I got something working by just using the latest CVS version on my server where globals are off and the last milestone on the other server where globals are on. It would be nice to know where the problem was though...

 

I've looked at this and can't see anything in the patching instructions that might lead this to happen.

 

So....

I suppose the obvious question is "do you have the function 'tep_session_save_path' defined in .../catalog/includes/functions/sessions.php ?".

 

Unless you have moved things about, it should be the very last function in the file. If it's not there then I would suggest you add it back in - the instructions don't say to delete it

 

Feedback on this would be appreciated.

 

Rich.

:blush: :blush:
Link to comment
Share on other sites

I've searched the forums and I've even posted in the General Support section and I can't seem to find any help with this problem. I have installed Oscommerce 2.2MS2. I am on a shared host, and register globals are turned off. I get the error message that register globals must be enabled. I then install the patch version 1.2.1 to fix this. Everything works exactly the way it is supposed to except in the Admin area when I try to add a new product or a new product category I get an Internal Server Error. I type in the Category Name, Upload the image, click save and this is when I get the Internal Server Error page. Also, when trying to add a new product, I enter in all the information such as the item description, etc. I click the preview button and I get the Internal Server Error. The only contribution I have installed is the register globals 1.2.1 fix. I haven't done anything else to the shopping cart. The server's error log says this:

Tue Oct 19 11:25:03 2004] [error] [client xx.xx.xxx.xx] File does not exist: /home/domainname/public_html/500.shtml
[Tue Oct 19 11:25:03 2004] [error] [client xx.xx.xx.xx] Premature end of script headers: /home/domainname/public_html/catalog2/admin/categories.php

 

Thanks in advance!

Link to comment
Share on other sites

Tue Oct 19 11:25:03 2004] [error] [client xx.xx.xxx.xx] File does not exist: /home/domainname/public_html/500.shtml

Ok, the reason you are getting this error is because the server is encountering an error (error 500 in this case) and it's running off to try and find a nice friendly error page to present to the user. In this case it's looking for a page called 500.shtml. You don't have this page defined (which isn't unreasonable) and so the server then sort-of bounces and generates the 'file does not exist' error.

 

The REAL problem is is the error 500 which means "Internal Server Error", but you probably worked this out already.

 

Register-globals issues asside, this is probably worth looking into a bit further - try bringing up a page you know does not exist (eg - http://mydomain/bogus.html). This should return a 404 error to the browser, but you might get something similar to the above (ie - ..../404.shtml not found); not very useful or informative for your users ! If this is a general issue then you either need to define a set of error pages that the server CAN find or ask your host provider to explain to you how to redirect all errors to a default set of error pages that they should provide (IF they DO provide them !)

 

[error] [client xx.xx.xx.xx] Premature end of script headers: /home/domainname/public_html/catalog2/admin/categories.php

This is REAL problem and it is this that is causing the "Internal Server Error". You will probably find that there is a mistake in the code that you have changed. Of course, it could be a mistake in the patching instructions in which case it's MY fault !

 

It's difficult to say without looking at the code, but it's probably a missing ')' or '}' or a missing '?>' or something tiny like this. It could be a misplaced comment or something - it WILL be something trivial but probably something very tedious to track down. Such is life !

 

I would suggest the following :

 

* Go through the code changes and make sure they are absolutely correct. If this fault ONLY occurs in the categories page then I would suggest the fault is in the admin/categories.php file. If it was in the admin/includes/application_top.php file or any of the other files that that are included more generally then more would be broken than just your categories page - you would get the same fault popping up on other pages.

 

* If you still can't work it out, you can (if you want) email me the files you have changed and I'll take a look for you - If you do this, I probably need the following :

 

admin/categories.php

admin/includes/application_top.php

admin/includes/functions/sessions.php

admin/includes/functions/general.php files

 

If you don't get in touch otherwise, it would still be nice to know if/when you resolve this so that if it is a problem in the patching instructions, I can correct it for other users.

 

Rich.

Edited by CMOTD
Link to comment
Share on other sites

Are there any mods required to payment modules when using the register globals fix ?

 

If I use the cc payment module or the nochex module then everything works fine.

 

If I use the ProtX payment module then it seems to decode the response from ProtX as failure even when it has passed. This results in being taken back to the choose payment option screen.

 

I changed the statement:

If ($status != 'OK')

to read:

if($status == 'OK')

in the ProtX payment module and it completes the order so I assume the status is not being calculated correctly.

 

The status is calculated in the function before_process() but I don't have enough knowledge to know if this needs changing to operate with register globals off.

 

Regards

 

Dave Peters

Dave Peters

Link to comment
Share on other sites

Are there any mods required to payment modules when using the register globals fix ?

Quite possibly. I never changed this module to make it work with register globals. In fact, truth be told, I'm not even sure what ProtX is.

 

I assume this is a standard module in OSC ? If so then it looks like there is an omission that needs addressing in the register globals patch. I'll try and have a look at it, but it might take me a while before I get round to it. Also, I may not be able to test it, depending on what it is (but until I find out what it is, I don't know).

 

I changed the statement:

If ($status != 'OK')

to read:

if($status == 'OK')

Sounds like a very dangerous thing to do - just willy-nilly inverting the logic so that it thinks an error is a non-error and a non-error is an error !!

 

Rich.

Link to comment
Share on other sites

Thanks for the reply. ProtX is a payment module in the contributions section. I think ProtX is the cheapest credit card payment service in the UK so it would be good to have it work.

 

Link to contribution:

http://www.oscommerce.com/community/contri...,1/search,protx

 

You can leave all parameters of this module as supplied and it will work via the ProtX test server. Any card details you put in are not actually processed. You need only a plausible card number and any expiry date in the future to give a success.

 

Currently when you get a good credit card it returns you back to the payment selection screen instead of the thank you screen.

 

I didt intend to actually use the code with the logic reversed <g> just thought it was a simple way to prove that is where the problem was.

 

 

 

Quite possibly. I never changed this module to make it work with register globals. In fact, truth be told, I'm not even sure what ProtX is.

 

Rich.

Dave Peters

Link to comment
Share on other sites

...ProtX is a payment module in the contributions section.  I think ProtX is the cheapest credit card payment service in the UK so it would be good to have it work.

I hear what you're saying but if it's not part of the core OSC code then I'm unlikely to even look at it any time soon.

 

As I've said before, if there's a bug in my contribution then I'll fix it, but I don't have the time (or inclination) to support an endless collection of other people's contributions. The fault lies with the ProtX contribution - if what you are saying is correct (and I have no reason to doubt you) then it would seem that it hasn't been written in such a way that it works without register globals being enabled (and yes, it could be written to work regardless of the register globals setting). It's almost certainly very simple to fix.

 

I've just spent some time fixing the admin 'Edit Order' contribution, but quite honestly, I've only done this because I want to use it (I'll probably get round to publicising the fix for this at some point - if anyone wants this any time soon, give me a nudge).

 

I can imaging the chaos that is going to ensue when OSC finally and officially goes over to not requiring register globals - A lot of the contributions will not work - their authors ought to be looking at this issue now. :-)

 

Rich.

Edited by CMOTD
Link to comment
Share on other sites

I hear what you're saying but if it's not part of the core OSC code then I'm unlikely to even look at it any time soon.

Rich.

 

I suspect here will be other modules with this problem but I have sorted the ProtX submission. Here is the solution for anyone else reading this thread.

 

The following modificaton is needed to the protx_form.php file:

 

function before_process() {

global $HTTP_POST_VARS;

 

$Decoded = $this->SimpleXor(base64_decode($_REQUEST['crypt']),MODULE_PAYMENT_PROTX_FORM_PASSWORD);

$values = $this->getToken($Decoded);

 

Note I accept no responsibility for this as I am not a PHP programmer but I just hacked in some code from ProtX integration kit into the original submission and it appears to work fine.

 

Dave Peters

DP Software

Dave Peters

Link to comment
Share on other sites

$Decoded = $this->SimpleXor(base64_decode($_REQUEST['crypt']),MODULE_PAYMENT_PROTX_FORM_PASSWORD);

Just a thought, but it might be an idea to narrow the scope of this further and use $_POST instead of $_REQUEST

 

Rich.

Link to comment
Share on other sites

HANDY HINT FOR FINDING REGISTER GLOBALS PROBLEMS AND SOME BUG-HUNTING TIPS

 

I thought I'd added this to the latest installation instructions but it looks like I didn't, so....

 

For anyone who is wanting to make some other contribution (or their own code) work when register_globals is switched off, you might find the following bit of code very useful. All it does is print out the global data arrays. Then, when you exercise your code, it allows you to see which variables are being used and so may need attending to in your code. I usually add this to the end of the application_top.php file. As you can see, you select which arrays to print simply by commenting the appropriate lines in/out. Most of the time you will only need to monitor the POST and GET variables, but it's always worth checking the COOKIE array too if you still have problems.

 

function px(&$arr, $arr_name)
{
 if (sizeof($arr))
 {
   print "---------- <br />";
   print $arr_name . "<br />";
 }

 foreach($arr as $key => $v)
 {
   print " ".$key." -> '".$v."'<br />";
 }
}



px($_GET, "GET");
px($_POST, "POST");
// px($_COOKIE, "COOKIE");
// px($_SERVER, "SERVER");
// px($_ENV, "ENV");
// px($_FILES, "FILES");

 

AN EXAMPLE

 

Let's say, I've just added the 'Really Annoying Flash Animation' contribution to my OSC code and I'm finding that there are problems in the admin section which iI suspect are due to register_globals issues. OK, what do I do ?

 

Well, first thing is to add the above code snippet to the bottom of .../admin/includes/application_top.php (if my problem was in the catalog section, I would add it to .../catalog/includes/application_top/php). I then bring up the page that is causing me problems.

 

My ficticious problem is that when I edit the settings for this contribution, things seem to not be quite right - say I find that the 'Annoyance Factor' setting seems to be getting ignored. To see what is going on, I exercise the page concerned by changing some settings, one of which is the 'Annoyance Factor' value. I really hate my customers and want to drive them all away, so I set the 'Annoyance Factor' it to its maximum value of 100%

 

Ok, I then hit the 'save' button.

 

The bit of code that I added to application_top now prints out the global variables. I see that in the POST section there is a variable called 'annoy_factor', and look - it has a value of '100' - Looks like this is my candidate !

 

So....

 

I now go to the admin configuration page code and look for this variable name. And there it is !.....

 

if (isset($annoy_factor))
{
  ..bla bla bla....
}

I may well find that it's used in a couple of other places too.

 

OK, so now I've found the variable, what's the problem ?

 

The problem is that the variable $annoy_factor won't exist ! Why ? Because we have switched off register_globals ! What enabling register_globals does is to take the global variables defined in the arrays $_POST, $_GET, etc and give them all individual global names. So, when we switch register_globals off, this mechanism is suppressed. For more information, go to the PHP support site.

 

To fix this problem we can do one of two things, thus :

 

OPTION 1

Somewhere (probably near the top of the file, but not necessarily - I'm afraid you are on your own here), you could add the following line...

link_post_variable('annoy_factor');

This will basically do the job that having register_globals enabled would have done (ie - it will create the $annoy_factor variable).

This option is possibly the one to go for if it all starts to look very complicated and you loose your bottle !

 

Note that the function 'link_post_variable' is provided by the 'Register Globals' contribution, so this fix is no good if I wanted to email the author of the 'Really Annoying Flash Animation' contribution with my fix so (s)he could include it into the next version of their contribtution.

 

OPTION 2

If you can do it, this is a better option than OPTION 1; it is much tidier. It involves changing the existing variable reference(s) to point to the globals arrays (which is what the author of the 'Really Annoying Flash Animation' contribution should have done in the first place). For example, change this...

if (isset($annoy_factor))
{
  ..bla bla bla....
}

...to this...

if (isset($_POST['annoy_factor']))
{
  ..bla bla bla....
}

You may find that some code uses the global variable array name $HTTP_POST_VARS[...] instead of $_POST[...]. The two are basically the same thing but $_POST is the preferred method. $_POST also has one advantage of using $HTTP_POST_VARS, and that is that with $HTTP_POST_VARS you will have to declare its use if you use it within a function. So, if our example code above was actually within a function, and we used $HTTP_POST_VARS instead of $POST, we would also have to add the line...

global $HTTP_POST_VARS;

...before we referred to it elsewhere in our code. This 'global' statement must be within the body of the function. With $_POST, you don't have to do this because it's done automatically for you by the PHP engine (actually, it's just not needed !).

 

--------------------

After applying one of the above fixes I should find that this variable will work. Of course, there could be other variables that are also causing problems and one or more of the other variables that I have not adjusted yet could still mean that our annoy_factor function is still broken until I also fix those.

 

--------------------

The above example refers to a POST variable, but exactly the same thing applies to GET variables. You may also find that a contribution adds a new SESSION variable or even a new COOKIE variable, though this is rare.

 

Anyway, I hope this gives you some pointers. If you find a fix for a particular contribution then feel free to post it up here so it can help others who are using the same code. Be sure to mention the version of the' register globals' contribution that you are using and the version of the other contribution you are fixing !

 

Rich

Link to comment
Share on other sites

OK, I was about to abandon OSC as I won't run with register_globals=OFF these days, when I found this great great thread. So first of all a huge thank you to Rich for all this.

 

I followed the instructions and spotted the note about removing the test in the installer too (!!!) and hey presto. Cool. Admin seems to be working fine.

 

I chose "use database" for my sessions during the install.

 

When I came to run the Catalog I got a huge blank. Inserting an echo"Got here OK"; at various points in application_top.php (the catalog one obviously) got me as far as line 150 or thereabouts:

 

tep_session_save_path(SESSION_WRITE_DIRECTORY);

 

at which point the whole thing falls over.

 

Has anyone got any ideas whether this is indeed related to my choice of database logging of sessions, or even how to switch around to just using a text file once installed so I can test it. Having just set up the admin completely I'm reluctant to overwrite the lot for a few hours and see if anyone can help!

 

I wonder whether the database logging is using variables that aren't captured by this so I guess I'm about to try and get that debugger (see above) going but of course the moment I can't see that either! Doh.

 

Thanks in advance

John

Edited by rocketshop
Link to comment
Share on other sites

...

  tep_session_save_path(SESSION_WRITE_DIRECTORY);

Mmmm....

 

I've never used the database option for saving sessions, so I don't know. Seems a bit odd that a call would still be made to tep_session_save_path if you have this option enabled though, don't you think ? This is just speculation, but if you are using the database option then wouldn't it be reasonable for the session directory not to be set up ? In which case, I would expect this call to fail, which seems to be what is happening. But why is it being called anyway ?

 

The changes I made to session storage shouldn't have any affect on HOW the sessions are saved; at least there is nothing in the unmodified code to suggest that such a differentiation is made. Clearly, some bit of the code must know the difference though - maybe I missed out a whole chunk of session-storage code (for database storage) ?

 

I don't have it in front of me so I'm not certain, but I think the session database/file selection is an option accessible from the admin.

 

Could be worth a search through the forums here to see what other issues have found with session storage.

 

Feel free to come back if you don't resolve this (and if you do resolve it, let us all know), and I'll try and have a look at it.

 

Rich.

Edited by CMOTD
Link to comment
Share on other sites

Have installed the contribution and put up on my shared ssl not at my main catalog yet, to test if it will work ok.

 

However, when i go there once installed i get the following.

 

Parse error: parse error, unexpected T_STRING in e:\sslroot\uvcatalog\catalog\includes\functions\general.php on line 1255

 

Fatal error: Call to undefined function: tep_session_name() in e:\sslroot\uvcatalog\catalog\includes\application_top.php on line 148

 

Any ideas?

 

Many thanks

Link to comment
Share on other sites

I have the register Globals off mod installed

 

Google is flooding my error logs with every request.

Anybody have any ideas?

 

Only google generates the errors in the log, not other users.

I watched google spider my site in whos online and tail the logs and see the error append with every google request.

I have "Prevent spider sessions" set to True, all other session variables set False.

I am using the mysql sessions instead of the file type

 

Linux Red Hat apache system with PHP 4.3.9

 

[Tue Nov 02 10:03:32 2004] [error] [client 66.249.78.54] PHP Warning: array_keys(): The first argument should be an array in /var/www/mysite/catalog/includes/functions/sessions.php on line 311

[Tue Nov 02 10:03:32 2004] [error] [client 66.249.78.54] PHP Warning: Invalid argument supplied for foreach() in /var/www/mysite/catalog/includes/functions/sessions.php on line 313

 

Thanks for any help

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...