Help debugging 403 Error

ntarantinontarantino Member
in Help edited October 2012
I am helping a friend setup their WordPress site with Foxcart. Lately they have been receving a datafeed error:

Error sending subscription datafeed. Your script responded with an HTTP Status code of 403 2012-10-17 12:52:17
Agent: curl/7.19.7 (x86_64-pc-linux-gnu) libcurl/7.19.7 OpenSSL/0.9.8k zlib/ libidn/1.15

I am trying to figure out what I need to do in beginning to debug this. Am I reading the error correct by saying the issue is this URL :

Cause when I go there I get a 403 error... or this saying it´s something on the server side?

Thanks for any help or direction.

The URL is
Foxy Domain:
  • fc_adamfc_adam FoxyCart Team
    Am I reading the error correct by saying the issue is this URL

    Not quite. The URL noted there shows what URL triggered the sending of the datafeed - which is not a publicly available URL hence why you get the 403 error when you try to visit it. If you look at some of the other errors listed for the datafeed, specifically for the transaction datafeed, it's url is checkout.php as that is what triggers the transaction based datafeed.

    An error for your transaction datafeed looks like this:
    DataFeed Failed: (14525163) 2012-10-08 00:30:35 No data returned for **removed_url** [403]

    From Wikipedia, a HTTP status code of 403 is the following:
    403 Forbidden
    The request was a valid request, but the server is refusing to respond to it. Unlike a 401 Unauthorized response, authenticating will make no difference. On servers where authentication is required, this commonly means that the provided credentials were successfully authenticated but that the credentials still do not grant the client permission to access the resource (e.g. a recognized user attempting to access restricted content).

    The error you're seeing in the error log is what is being returned from the datafeed endpoint set. From looking at the store, the endpoint is part of the FoxyShop installation you have on the site. So basically FoxyCart is sending the datafeed to your endpoint, but all it's getting back from your end is the 403 status code. Also from looking at your transactions list, some transactions appear to have gone through successfully, so the issue only appears to be intermittent.

    So with all of that said, you'll need to look into why your server is sometimes returning a 403 when the datafeed is hit. Perhaps take a look at your server logs to see if you see any corresponding entries that might help point to an issue.
  • ntarantinontarantino Member
    edited October 2012
    I see in the error logs something isn´t playing nicely with the mod_security I have on the server. One of the errors came back like this:

    [Tue Oct 16 12:52:05 2012] [error] [client] ModSecurity: [file "/etc/httpd/modsecurity.d/10_asl_rules.conf"] [line "125"] [id "390614"] [rev "9"] [msg " UNSUPPORTED DELAYED Rules: Invalid character in ARGS"] [severity "CRITICAL"] Access denied with code 403 (phase 2). Found 61 byte(s) in ARGS:FoxySubscriptionData outside range: 1-255. [hostname ""] [uri "/foxycart-datafeed-3fbdabd8ca4a/"] [unique_id "UH265NhGWMYAAC0OTyIAAAAD"]
  • lukeluke FoxyCart Team
    Hey ntarantino. Yes, we've seen this before. Is there someone you can talk to that manages your hosting environment that can adjust the modsecurity rules for your script? In the future we plan to send everything base64 encoded to avoid this, but that's a large change for a lot of people so we haven't jumped into it yet.
  • Super, just let me know what we can adjust! Thanks.
  • lukeluke FoxyCart Team
    @ntarantino: sorry if I wasn't clear. You'll need to talk to the company that hosts the website your datafeed script is on. You'll then show them the modsecurity error and explain to them you have a script from a third party (us) that is trying to post to your system and you need to have them adjust their settings to let our script post to the site.

    If you're managing the server then you'll need to adjust your modsecurity settings which is probably outside of the level of support we can provide here in the forum.

    I hope that helps... not sure if it does. Does it?
Sign In or Register to comment.