OLD Super Orders 2.0 (See v3.0 thread instead)

I've installed the security_patch_v138_20090619 yesterday and now when I try to modify Order Payment Data using the 'Modify'-button it sends me to the Admin homepage instead of displaying the actual payment details. "Remove" on the other hand does seem to work!?

Anyone else experience and maybe solved this? I seem to have missed one upgrade (using rev 46) so I'll upgrade as soon as possible to rev 47 to make sure it isn't related to that.

Super orders is not actively maintained and is full of security holes. There's at least one instance where 1.3.8 has stopped functions within it when you are searching for <= something as it strips out the < sign. My personal opinion is that it should be removed from the download section until a maintainer is found but I run more than 30 modules and apparently some of the features are going to be put into ZC 2.0 but it comes as no surprise that fixing a hole in ZC in general would wipe out function in super orders. Anyone is free to post an updated version if they solve the issues as the original maintainer has no further interest in it.

Greetings!

I'm using ZC 1.3.8a with PHP 5.2.9

I installed SuperOrders according to the directions, and when I go to Customers/Super Orders, it comes up with a blank page. In fact, every related page (except the configuration page) comes up blank. When I look at the source of the blank page all it says is:

The error logs provide no clues. We're using BlueHost as our web host, if that makes a difference.

Even if I make the very first line of code in super_orders.php 'print "Made it here!";' it doesn't do anything but give the error above.

The only other module I've installed is Export Shipping Information.

Any ideas? Thank you!

Emily

That is most likely to be that you have uploaded the files with the wrong permissions on them and the webserver either cannot read them or thinks the permissions are not strict enough. In your ftp program right click the files and see what it says, the ownership and permissions should be the same as your existing files that work. a 500 error is web server related not PHP based.

Thank you
Philip

philip_clarke:

That is most likely to be that you have uploaded the files with the wrong permissions on them and the webserver either cannot read them or thinks the permissions are not strict enough. In your ftp program right click the files and see what it says, the ownership and permissions should be the same as your existing files that work. a 500 error is web server related not PHP based.

Thank you
Philip

Philip, thank you so much!! The problem was too much permissions. They came in the archive as rw-rw-r and when I set them to rw-r-r everything started working. I would never have figured that out, so thank you again!!

:clap: :clap: :smile:

Emily

davale:

I've installed the security_patch_v138_20090619 yesterday and now when I try to modify Order Payment Data using the 'Modify'-button it sends me to the Admin homepage instead of displaying the actual payment details. "Remove" on the other hand does seem to work!?

Anyone else experience and maybe solved this? I seem to have missed one upgrade (using rev 46) so I'll upgrade as soon as possible to rev 47 to make sure it isn't related to that.

Rev 47 will not correct the problem.
The new security patch file located in /youradminfolder/includes/init_includes is looking to see if you are using a 'get update', which the Modify Command uses. A quick work around until the problem is actually solved would be to remove ',update' from line 16 in the security file.

if (isset ( $_GET ['action'] ) && in_array ( $_GET ['action'], array ('save', 'layout_save',** 'update',** 'update_sort_order', 'update_confirm', 'copyconfirm', 'deleteconfirm', 'insert', 'move_category_confirm', 'delete_category_confirm', 'update_category_meta_tags', 'insert_category' ) ))

I realize that this defeats one purpose of the patch, but as I said, this is just a Quick Work Around. :shocking:

Please Please Please take over this module. Remove all of the keywords like "update" and the one that does <= and gets clobbered by 1.3.8's security

:frusty:

JTheed:

Rev 47 will not correct the problem.
The new security patch file located in /youradminfolder/includes/init_includes is looking to see if you are using a 'get update', which the Modify Command uses. A quick work around until the problem is actually solved would be to remove ',update' from line 16 in the security file.

Thanx JTheed for this workaround. Tried it and indeed the function is restored. Still wondering if I should leave it out or let security prevail.

philip_clarke:

Please Please Please take over this module. Remove all of the keywords like "update" and the one that does <= and gets clobbered by 1.3.8's security

:frusty:

I am not a programmer Philip, I just try to figure out what causes a problem and where to fix it. You could change the word update to something else, but anyone looking at the code would do the same in their attack.

This particular security patch is for the Admin Area Only. Hopefully, your Admin area is secure so no one can get into it to begin with. Use common sense and have difficult passwords and change the name of the admin folder. If on Linux type servers, use the .htaccess to ask for a name and password before letting you login to the admin area.

Mine's already secure, I also run the ZC Worldpay module and 30+ modules for the UK's royal mail shipping modules (there's a lot of services) I only have time to point out the problems and try and quickly answer anything like the server 500 error above, which is why this module really needs a good hard look. On every site I've ever worked on I have recommended moving the admin folder and if the shop owner is capable then also .htaccess protecting it as well as using SSL but I have got to say that 90% of the sites that I visited (and I do about 30 sites a month for shipping updates) have not moved their admin folder nor removed the docs folder that has the instructions.

i installed this several times and i just can't figure out where i went wrong. when i click on super order, i get the 404 Not Found error

I'm thinking there's something else wrong because this error also comes up when i try to use the 'monthly sales' mod.

any idea what it could be? seems like i just can't get this to work.

I'm having a problem with Super Orders 2.0. It seems to have knocked out my direct Bank deposit payment modules.

I have tried removing and installing the modules to no avail ?

My guess it it might have something to do with the latest security update and renaming of the admin folder but I have searched the database for includes/admin and it came back with nothing ???

Any ideas ???

We do alot of business through Direct Credit so it needs to be working ASAP :(

Thanks in Advance

We use Zen V1.38 / Super Orders 2.0

Cheers

The main symptom of the bug that is caused by the latest security update is that the server redirects to the admin login page. You could get a 404 if it's not redirecting properly, likewise it could damage other modules.

The reason is that the security update requires that all forms in Admin (no matter what you call it,) have a secutiryToken hidden field added to them. You can check this by going into one of your payment modules and looking at the HTML source, and you should see SecuityToken as a hidden field somewhere. The Payment and Shippng modules in general work fine because they are built use PHP called zen_draw_form.

If super_orders is not completely built using zen draw form then it will not work unless it is modified to add the hidden field. This can be checked by gping to super_orders.php and looking for the securitytoken hidden field. I would not take long to add the field to the PHP pages if this is the main problem

Thank you
Philip.

I guess then that means that we'll just need to wait on this a little to see what happens?

Found the solution to my issue. Its not Super Orders but for some reason I virtual products don't have a Direct Credit option ??? Hmmmm ?

Turns out in my case it was setting the files' permission to mimic other files' permission level.

Thanks Philip!!

I absolutely love this contribution!!

Now i have another question, i noticed that all the invoices show 'balance due' even though the transaction has been settled. does this mean that from now on for every order i have to go in manually input the credit transaction record?

or is this only occuring in the past invoices because they weren't captured by the SO mod?

is there a way to hide the "purchase order" option from the payment method page when customers are checking out? i don't want it to be available, but in the readme.txt it said that it had to be installed.

regarding my last post, i still don't quite understand the workings of this mod. do i need to manually close each order up and enter "payment data" by hand every time?
i have over 700 past orders, that will take a long long time to update.. :(

Thanls!

I don't know much about the module itself as I no longer run a shop, just hammer the code instead.

Having said that I would think that one could "install" but not "activate" the purchase order method of payment so that it would not show to your customers but seuper orders could still reference it if necessary. e.g. change the setting to "false" so that in the payment modules section of ZC it comes up with an orange dot instead of green or red.

Philip.

Thanks Philip!!!

i was wondering about that, but wasn't sure if i would interrupt how the module works.

It's only a guess but at least the code would be available to the module if it needs it, if the payment module is installed, at least then the code is "in place" and so it should throw less errors in theory. The main problem with super orders is that it dates from 2005 in some cases and with later versions of ZC it does through some errors, the box that says "search is a payment is <=" doesn't work because security measures in recent versions of zencart have disabled it.

I keep on hoping for a volunteer to step up and upgrade this module but as you know, I maintain some already, so can only point out the more obvious errors.

Philip.