406 Not Acceptable when adding YouTube video in admin on GoDaddy

Have a custom field for video code in the new_product admin. Everything used to work fine before switching to Godaddy's (ugh) C-Panel hosting. They say it's a mod_security setting that can't be disabled in a shared hosting environment. I can log into myphpadmin and add the iframe there directly, and it works. But when adding it in the admin area of the site and try to save, it throws up a 406 with the following:

An appropriate representation of the requested resource /admin/product.php could not be found on this server.

Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request.

The odd things is that adding iframe video code to the regular product description field works just fine. Also, if I just type something in the text box of the custom field it will save the page fine. So something is happening with how the custom field is adding the video to the database.

pricediscrimination:

Have a custom field for video code in the new_product admin.

What is your definition of 'video code' ? Is it the video itself, a direct link to where the video is located, or perhaps an iframe with embedded code (either a link to the source, or the video itself) ?

pricediscrimination:

Everything used to work fine before switching to Godaddy's (ugh)

I think this is a good clue as to why it no longer works, don't you?

pricediscrimination:

They say it's a mod_security setting

This can also be many different things. For instance, are they disallowing links to certain sites, or perhaps a particular type of file, or maybe just iframes (which really should be avoided anyway).

pricediscrimination:

that can't be disabled in a shared hosting environment.

That's fair enough.

pricediscrimination:

I can log into myphpadmin and add the iframe there directly

This suggests that you are adding the code for an iframe with embeded data, directly into the database. This generally isn't how iFrames are added to a page/pages.

Where did you get the information to do it this way?

pricediscrimination:

and it works.

phpmyadmin is generally 'local' to the server that it is being used on, so if by 'it works' you mean the phpmyadmin is showing the iframe/video that would be because the mod_security rules are typically designed to restrict certain access requests from a remote host and since the phpadmin access is 'local' the same rules may not apply.

pricediscrimination:

But when adding it in the admin area of the site and try to save, it throws up a 406 with the following:
An appropriate representation of the requested resource /admin/product.php could not be found on this server

This looks like one of the possible mod_security error messages.

pricediscrimination:

The odd things is that adding iframe video code to the regular product description field works just fine.

So why not use this method?

pricediscrimination:

Also, if I just type something in the text box of the custom field it will save the page fine. So something is happening with how the custom field is adding the video to the database.

What happens if the "something" you type in the text box is the same as whatever it is the "custom field is adding to the database"? if 'something is happening' with it then surely you'd be able to look at what has gone into the database to see what this difference is?

The problem could be as simple as the database field isn't big enough to hold the data, or perhaps the input contains quotes, apostrophes or some other 'special' character that isn't being correctly escaped?

The 'mod_security' could be a red herring and simply being triggered by 'bad data'.

Sorry that I can't give a definitive answer, but without knowing exactly what you are doing, and what is triggering the error, all I can do is toss these ideas your way.

Cheers
RodG

RodG:

"Have a custom field for video code in the new_product admin."
What is your definition of 'video code' ? Is it the video itself, a direct link to where the video is located, or perhaps an iframe with embedded code (either a link to the source, or the video itself) ?

It is the standard embeddable iframe provided by youtube when you click embed. Looks like this:

<iframe width="853" height="480" src="//www.youtube.com/embed/qpgTC9MDx1o" frameborder="0" allowfullscreen></iframe>

The old embed code from them used to be an object.

RodG:

"Everything used to work fine before switching to Godaddy's (ugh)"
I think this is a good clue as to why it no longer works, don't you?

You mean because godaddy sucks? Yeah.

RodG:

"They say it's a mod_security setting"
This can also be many different things. For instance, are they disallowing links to certain sites, or perhaps a particular type of file, or maybe just iframes (which really should be avoided anyway).

It's likely iframes. The point is though that iframes work in the regular product description field, just not in the custom field now since moving to C-Panel.

RodG:

"I can log into myphpadmin and add the iframe there directly"
This suggests that you are adding the code for an iframe with embeded data, directly into the database. This generally isn't how iFrames are added to a page/pages.

Where did you get the information to do it this way?
What I meant was that I was testing it and added the iframe embed code in the database directly instead of via the ZC new product admin and the embed code displays on the front end just as it should. So my code is working properly, it's just not letting the iframe embed code write from my custom field in admin to the database table.

RodG:

"and it works."
phpmyadmin is generally 'local' to the server that it is being used on, so if by 'it works' you mean the phpmyadmin is showing the iframe/video that would be because the mod_security rules are typically designed to restrict certain access requests from a remote host and since the phpadmin access is 'local' the same rules may not apply.

Exactly, something about how the custom field writes to the database is being blocked by mod_security, but how the normal product description field writes is not being blocked. I guess it means I need to make a change to the custom field code in collect_info.php

RodG:

"The odd things is that adding iframe video code to the regular product description field works just fine."
So why not use this method?

The reason for making an entirely separate custom field is so that you can have more control over displaying using the information in that field. If the video code is added to the product description field, then you are limited as to what you can do with it and where you put it, specifically if the product description field is already being used for other stuff.

RodG:

What happens if the "something" you type in the text box is the same as whatever it is the "custom field is adding to the database"? if 'something is happening' with it then surely you'd be able to look at what has gone into the database to see what this difference is?

The problem could be as simple as the database field isn't big enough to hold the data, or perhaps the input contains quotes, apostrophes or some other 'special' character that isn't being correctly escaped?

When adding an iframe embed code to the custom field, nothing makes it to the database because after clicking "preview" the page is stopped by a 406 error. Using youtube's old embed code (object based) works fine. It's not an issue with the database field being big enough because the object code is bigger and it works, and the iframe can be added directly to the database and works.

Godaddy just said that "Most likely the trigger is that you are trying to submit a URL via GET or POST".

This is the custom field code in admin (based on this):

   if (isset($_GET['pID']) && empty($_POST)) {
      $product = $db->Execute("select pd.products_name, pd.products_description, pd.products_url,
                                      p.products_id, p.youtube_vids, etc etc etc

<tr bgcolor="#eeeeee">
<td class="main">YouTube Vids:</td>
<td class="main"><?php echo zen_draw_separator('pixel_trans.gif', '24', '15') . ' ' . zen_draw_input_field('youtube_vids', $pInfo->youtube_vids, zen_set_field_length(TABLE_PRODUCTS, 'youtube_vids')); ?></td>
</tr>

pricediscrimination:

You mean because godaddy sucks? Yeah.

Personally I wouldn't say that (They've actually gotten a little better over the years), but yes, that is the general consensus.

pricediscrimination:

It's likely iframes. The point is though that iframes work in the regular product description field, just not in the custom field

Then I'd suggest that it isn't likely to be the iframes.

pricediscrimination:

now since moving to C-Panel.

It almost certainly has nothing to do with cPanel either.

pricediscrimination:

What I meant was that I was testing it and added the iframe embed code in the database directly instead of via the ZC new product admin and the embed code displays on the front end just as it should. So my code is working properly, it's just not letting the iframe embed code write from my custom field in admin to the database table.

Aha. Now I understand.

pricediscrimination:

Exactly, something about how the custom field writes to the database is being blocked by mod_security, but how the normal product description field writes is not being blocked. I guess it means I need to make a change to the custom field code in collect_info.php

Possibly, but I'd be inclined to suggest that it is something in the 'update_product.php' file that needs a change.
collect_info.php reads the data from the database for editing. update_product.php is what writes the edited data back to the database.

pricediscrimination:

When adding an iframe embed code to the custom field, nothing makes it to the database because after clicking "preview" the page is stopped by a 406 error. Using youtube's old embed code (object based) works fine. It's not an issue with the database field being big enough because the object code is bigger and it works, and the iframe can be added directly to the database and works.

Sounds reasonable... which brings us back to the update_product.php code.

pricediscrimination:

Godaddy just said that "Most likely the trigger is that you are trying to submit a URL via GET or POST".

LOL. Is there another way to submit a URL if it isn't via a GET or a POST?

I think we should ignore what Godaddy are saying for the time being.

pricediscrimination:

This is the custom field code in admin (based on this):

Aha. That's a good start, but it doesn't really give much info about what is required for the update_product.php file, which, in simple terms, just requires an addition to the $sql_data_array the name of the custom DB field, and a sanitised rendition of the $_POST field from the collect_info.php page.

The lack of this field doesn't explain the mod_security error, but it could imply that the custom DB field has been added to this file and isn't being correctly sanitised, so the 1st thing I'd be doing is replacing this file with an unmodifed copy, which should make the mod_security error 'go away' (IOW, you'll be able to edit/save all the other data fields ok), and when this is the case, re-add the new field and possibly debug with part of the new $_POST variable is actually triggereing the error (assuming the error is still triggered).

Cheers
RodG

ps. I'm about to head off to bed (2:20am) so you'll probably get no more reply from me until tomorrow.

RodG:

Aha. That's a good start, but it doesn't really give much info about what is required for the update_product.php file, which, in simple terms, just requires an addition to the $sql_data_array the name of the custom DB field, and a sanitised rendition of the $_POST field from the collect_info.php page.

The lack of this field doesn't explain the mod_security error, but it could imply that the custom DB field has been added to this file and isn't being correctly sanitised, so the 1st thing I'd be doing is replacing this file with an unmodifed copy, which should make the mod_security error 'go away' (IOW, you'll be able to edit/save all the other data fields ok), and when this is the case, re-add the new field and possibly debug with part of the new $_POST variable is actually triggereing the error (assuming the error is still triggered).

Cheers
RodG

ps. I'm about to head off to bed (2:20am) so you'll probably get no more reply from me until tomorrow.

Thank you very much for the late night replies. update_product.php has this line for $sql_data_array = array:

'youtube_vids' => zen_db_prepare_input($_POST['youtube_vids'])

Tried all of this with the stock files, but as I mentioned the regular product description area allows for the iframe anyway with or with the custom field there.

pricediscrimination:

Thank you very much for the late night replies. update_product.php has this line for $sql_data_array = array:

'youtube_vids' => zen_db_prepare_input($_POST['youtube_vids'])

> 
> Tried all of this with the stock files, but as I mentioned the regular product description area allows for the iframe anyway with or with the custom field there.


There should probably be a comma at the end of that line. 

I assume that there is no error if/when you remove the line completely?  

Cheers
RodG

RodG:

There should probably be a comma at the end of that line.

I assume that there is no error if/when you remove the line completely?

Cheers
RodG

It's the last line there so no comma, but perhaps one should be added anyway?

Just removed the line and tried it, same 406 error.

It's late there... TBC

pricediscrimination:

It's the last line there so no comma, but perhaps one should be added anyway?

Just removed the line and tried it, same 406 error.

It's late there... TBC

One more thing....

after the $sql_data_array code block, add the following line of code

print_r($_POST['youtube_vids'*]) ; die ;

*This should display the the contents of the post variable (unless the mod_security gets to it 1st).

Cheers
RodG

RodG:

One more thing....

after the $sql_data_array code block, add the following line of code

print_r($_POST['youtube_vids'*]) ; die ;

*This should display the the contents of the post variable (unless the mod_security gets to it 1st).

Cheers
RodG

Just did it as you instructed. No go. Same error.

pricediscrimination:

Just did it as you instructed. No go. Same error.

OK, so there is defintely something in that $_POST variable that is triggering the error.

Can you please confirm if the problem goes away (or not) if you remove
'youtube_vids' => zen_db_prepare_input($_POST['youtube_vids'*]) *

Cheers
RodG

RodG:

OK, so there is defintely something in that $_POST variable that is triggering the error.

Can you please confirm if the problem goes away (or not) if you remove
'youtube_vids' => zen_db_prepare_input($_POST['youtube_vids'*]) *

Cheers
RodG

Removing this line did not change anything.

Also what would explain these two things:
-iframe works fine in the regular product description field
-other text works fine in the custom field

pricediscrimination:

Removing this line did not change anything.

Oh, that's a worry. Does the 'preview' page display ok? (I'm guessing it does)

pricediscrimination:

Also what would explain these two things:
-iframe works fine in the regular product description field
-other text works fine in the custom field

This is what I'm trying to determine, but you've just thrown me through a bit of a loop because the removal of that line would/should have gotten rid of the error IF that is the $_POST variable that is causing the error.

The fact that the problem still exists implies that I/we are barking up the wrong tree. :(

Cheers
RodG

RodG:

Oh, that's a worry. Does the 'preview' page display ok? (I'm guessing it does)

This is what I'm trying to determine, but you've just thrown me through a bit of a loop because the removal of that line would/should have gotten rid of the error IF that is the $_POST variable that is causing the error.

The fact that the problem still exists implies that I/we are barking up the wrong tree. :(

Cheers
RodG

With the iframe code, the 406 error kicks in before the preview is even viewable. With anything else but iframe, the preview is normal.

pricediscrimination:

With the iframe code, the 406 error kicks in before the preview is even viewable. With anything else but iframe, the preview is normal.

OK, so this brings us back to a different piece of the code for further investigation, specifically /admin/product.php (assuming it even gets that far).

The program flow goes like this:

collect_info.php reads the data from the DB and displays it for edit. When the 'preview' button is pressed it posts the data to the product.php code, and finally when the update button is pressed it passes the $_POST data to the update_product.php code.

It now looks like the error is being triggered with the POST data to the product.php code......

And that is about as far as I can take you tonight.... The day is just starting in other parts of the world so hopefully someone else will take these current findings further while I'm sleeping :)

G'night.
RodG

RodG:

OK, so this brings us back to a different piece of the code for further investigation, specifically /admin/product.php (assuming it even gets that far).

The program flow goes like this:

collect_info.php reads the data from the DB and displays it for edit. When the 'preview' button is pressed it posts the data to the product.php code, and finally when the update button is pressed it passes the $_POST data to the update_product.php code.

It now looks like the error is being triggered with the POST data to the product.php code......

I just downloaded a fresh ZC fileset and replaced my products.php with a new one. Nothing changed.

pricediscrimination:

I just downloaded a fresh ZC fileset and replaced my products.php with a new one. Nothing changed.

Sorry, but I think I misled you here. I didn't think that the problem would be with this file. I was suggesting that this is the file where we should be looking to see what the $_POST data from the collect_info.php page/file contains.

This means finding a suitable place in the file to add the line:
print_r($_POST['youtube_vids']) ; die ;

The intention being to inspect the variable for anything (other than 'iframe') that could/would possible trigger the mod_security rule.

I'm still working on the assumption that it isn't the iframe itself causing the problem, and this assumption is based on the fact that "iframe works fine in the regular product description field"

If it turns out that there isn't anything amiss with the $_POST data contents, the next thing to do would be to populate the input field with the exact same data/code that you are currently using but without the 'iframe' part. (In fact doing this may even be a quicker/easier test/check).

Again, the point of this exercise isn't so much to fix the problem, but to identify the exact cause. (Is it the iframe, or is it something else).

If it does turn out to be the iframe itself we can then look into why it is causing a problem with this particular input, but not in the product description field.

Hopefully you can see where I'm coming from?

Cheers
RodG

RodG:

If it turns out that there isn't anything amiss with the $_POST data contents, the next thing to do would be to populate the input field with the exact same data/code that you are currently using but without the 'iframe' part. (In fact doing this may even be a quicker/easier test/check).

Hi again, RodG. Just tested the input field with the exact same data/code that I am currently using but without the 'iframe' part. Successfully goes to the preview screen. Tried again with iframe in there and back to the 406.

RodG:

If it does turn out to be the iframe itself we can then look into why it is causing a problem with this particular input, but not in the product description field.

Hopefully you can see where I'm coming from?

Yes, I see where you are coming from, this is the odd part. The product description field can write the iframe code to the database but not the custom input field.

pricediscrimination:

... Yes, I see where you are coming from, this is the odd part. The product description field can write the iframe code to the database but not the custom input field.
Very ODD. Question is: what is the exact mod_security rule being triggered? Can you get this from your hosting provider?

The fix might be as single as changing a name / id or input type... But without knowing what rule is being triggered we are just guessing wildly.

lhungil:

Very ODD. Question is: what is the exact mod_security rule being triggered? Can you get this from your hosting provider?

The fix might be as single as changing a name / id or input type... But without knowing what rule is being triggered we are just guessing wildly.

It's GoDaddy, a basic question like that is asking too much from them. This is the kind of reply you'd get:

"Most likely the trigger is that you are trying to submit a URL via GET or POST. However that being said we cannot replicate the issue without the steps to duplicate and the other information we previously requested. Please provide this information so we can review further."

The information they wanted was IP address and admin password so they could get in there and try to post something lol.

LOL. So the hosting provider is no help... Perhaps you could store something other than the full iframe HTML snippet.

Maybe just convert the field to hold the youtube video ID (or just the URL without the protocol), and in the template reconstruct the URL / iframe (or use oembed)?