Tag Archives: php

PHP, System Administration

suhosin to [internal web app]: you talk too much

Following up on my earlier post, I’ve had to make some further configuration adjustments to avoid suhosin-related restrictions in one of our custom web applications. This particular application has a function that generates a summary of data from student assessments. The summaries can be generated based on groupings of packets and items. Depending on the filtering parameters selected there can be a fairly large number of packets and items. Not all of the packets necessarily contain the items of interest, but it’s always easier to select all if you want an overall summary of item performance.

I recently noticed the following alert in the system log:

ALERT – configured POST variable limit exceeded – dropped variable ‘included_packet_ids[]’ (attacker USER_IP_ADDRESS, file REPORT_FILTERING_PAGE)

One of the reasons I use POST variables on this page is to avoid the relatively small data size limit of GET. Suhosin adds additional limits, including in the number of times you can reference an individual variable.  Our limit was set at 1000, meaning there were over 1000 packets selected. This points to a need to adjust how the filter “selects all” … but for now I’ve adjusted the suhosin limit upward by modifying the suhosin.post.max_vars setting.

References:

PHP, System Administration, WordPress

suhosin to WordPress: go on a diet

1 Comment

We were seeing a lot of suhosin alerts in the system messages log of the type:

ALERT – script tried to increase memory_limit to 268435456 bytes which is above the allowed value (attacker SERVER_IP_ADDRESS, file WP_MAIN_ADMIN_PAGE, line 96)

The source of the issue is WordPress. The application is trying to raise the memory limit and suhosin won’t let it. Apparently WordPress will try to set a 256MB memory limit before executing certain functions. The necessity of adjusting this setting seems questionable to me, but I also understand that it’s often better to play it safe when developing software for public consumption.

I don’t particularly like applications attempting to specify their own resource usage in a web environment. In my mind applications should specify a required/recommended memory limit in the system requirements and stay away from adjusting this setting behind-the-scenes. Tell me during setup if the current setting may result in non-optimal performance or even a halt in script execution. That’s not how it’s done here, but really no harm is done in the long run beyond the annoyance of suhosin throwing errors at the system logs.

There are two easy fixes to the problem:

  1. Set the PHP memory limit to 256MB
  2. Modify the suhosin.memory_limit parameter to 256MB

In our particular situation it’s just as easy to set the PHP memory limit. There’s always a risk of overloading the physical resources, but this site receives little enough traffic that I’m not concerned about the right confluence of request occurring to cause a crash.

References:

ALERT – script tried to increase memory_limit to 268435456 bytes which is above the allowed value
Web Development

AbleCommerce Tax Zone Modification

1 Comment

One of the features of AbleCommerce is the ability to charge taxes based on address. The feature is nice, but has one major flaw … the tax rate has to managed manually. We actually have only a few states where we are required to charge taxes, but one of those is California which is horribly convoluted. The problem boils down to, essentially, the need to track the tax rate for each zip code individually. You can’t even really use blocks of zip codes because a locality’s zip codes may not be consecutive.

AbleCommerce uses the concept of zones for assigning tax rates. For our purposes a zone can be applied based on state or a combination of state and a list of zip codes. Because of California’s tax rules and AbleCommerce’s tax rule management functionality we have to create a separate zone for each tax rate. The zip code list is just a comma-separated string of zip codes. Maintaining the information for the >1000 zip codes is difficult to do in this format.

I created a simple PHP-based page that keeps track of each zip code and its associated tax rate. While not perfect, this goes a long way towards simplifying maintenance of this information. A link to this page can be located in the AbleCommerce administrative section under Configure->Regions->Zones.

AbleCommerce has one other issue that has to be addressed. The default AbleCommerce installation limits a zone’s zip code filter to 255 characters (or about 40 zip codes) in the database and on the web form. Due to the situation with California taxes we have some zones that have significantly more than 40 zip codes and would require the creation of over 70 zones. To get around this problem I removed the web form limit and modified the database field ac_shipZones@PostalCodeFilter to be varchar(8000).