406 Not Acceptable when adding YouTube video in admin on GoDaddy

[pricediscrimination]

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.

[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) ?

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?

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).

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

That's fair enough.

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?

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.

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.

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

So why not use this method?

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

[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) ?

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.

"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.

"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.

"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.

"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

"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.

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') . '&nbsp;' . zen_draw_input_field('youtube_vids', $pInfo->youtube_vids, zen_set_field_length(TABLE_PRODUCTS, 'youtube_vids')); ?></td>
</tr>

[RodG]

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.

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.

now since moving to C-Panel.

It almost certainly has nothing to do with cPanel either.

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.

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.

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.

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.

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.

[pricediscrimination]

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.

[RodG]

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

[pricediscrimination]

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

[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

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

[pricediscrimination]

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.

[RodG]

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