406 Not Acceptable when adding YouTube video in admin on GoDaddy

[pricediscrimination]

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

I'd like to do this, just didn't know how or where to start.

[lhungil]

I'd like to do this, just didn't know how or where to start.

Fist thing to check: does entering just the URL trigger the mod_security block? If not, one can just store the URL in the database field and in the Zen Cart template (for your product type - probably product_general) add the iframe portion needed for youtube (or use oembed to dynamically generate the video display code - which works with most streaming video services not just youtube).

If mod_security does not allow the URL, you could store just the youtube video IDs (I do this for a non Zen Cart site - for a different reason) and then add the youtube URL portion and call oembed (or just generate the iframe + iframe URL yourself; I seem to recall there being a pattern)...

[RodG]

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.

Can you post copies of the code that you are using. Both the original, and the one with the iframe part removed.

The product description field can write the iframe code to the database but not the custom input field.

As previously stated, this is why I'm not 100% convinced that it is the iframe part that is causing the problem, and I'd like to verify that we are both on the same page in regards to what you have removed from the original.

Also, as an adjunct to lhungil's comments that there are other methods that you can use, it *may* eventually come to that, but it still depends on *exactly* it is that is triggering the mod_sec rule. It would be 'silly' to go this route if a solution can be found with a minor tweak of your input data.

*HOWEVER* as I said in my opening reply, storing iframes and iframe data in the database is quite unusual anyway, but you did give a somewhat valid reason why you have taken this approach which will be somewhat negated with the proposed method (which again, may turn out to be unavoidable anyway).

Theoretically, if the same input/code works with the product description it *should* work with your custom field.

Cheers
RodG

[pricediscrimination]

Can you post copies of the code that you are using. Both the original, and the one with the iframe part removed.

For example:

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

This is just the regular YouTube embed code.

Anything removed from this code just shows up as text. It's only the "ifram" that is tripping it up. I can do:

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

or any other combination and the text will appear where the iframe video should show up.

As previously stated, this is why I'm not 100% convinced that it is the iframe part that is causing the problem, and I'd like to verify that we are both on the same page in regards to what you have removed from the original.

Also, as an adjunct to lhungil's comments that there are other methods that you can use, it *may* eventually come to that, but it still depends on *exactly* it is that is triggering the mod_sec rule. It would be 'silly' to go this route if a solution can be found with a minor tweak of your input data.

*HOWEVER* as I said in my opening reply, storing iframes and iframe data in the database is quite unusual anyway, but you did give a somewhat valid reason why you have taken this approach which will be somewhat negated with the proposed method (which again, may turn out to be unavoidable anyway).

Theoretically, if the same input/code works with the product description it *should* work with your custom field.

Cheers
RodG

The proposed method is quite nice actually, it allows for far more customization via CSS etc. This is how oembed works on Wordpress themes. You just the URL to the video and it displays it. However, as you said this wouldn't solve the problem as to why the iframe is allowed in the product description field and not in the custom field.

[RodG]

For example:

Just for clarification, when I asked you to provide the *exact* code, that is what I meant. I don't know if your *example* is the same as the *exact* code or not.

Anyway.......

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

I have two more tests that I'd like you to make.

The first is to try this code:

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

IOW, change the two 'iframe's to 'abcdef', and let me know if the mod_security us still triggered. (note: this code won't actually function. All I/we are testing for is the triggering of the mod security rule)

Anything removed from this code just shows up as text. It's only the "iframe" that is tripping it up. I can do:

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

It is *still* not possible to come to this conclusion with 100% certainty, because not only have you removed the possible iframe trigger, but you have *also* made the length of the input data 12 characters shorter (which is why I'm asking you to replace the iframe text with an equal number of other characters).

The proposed method is quite nice actually,

It is also the way this kind of thing is generally done (which I why I was questioning your method from the very outset).

However, as you said this wouldn't solve the problem as to why the iframe is allowed in the product description field and not in the custom field.

Correct. Furthermore I/we are now 'this close' (holding finger and thumb together) to determining with 100% certainty whether it really is the 'iframe' causing the error or not.

If the replacement of 'iframe' with 'abcdef' *doesn't* trigger the error, I think I've identified the cause of the problem (and the fix will be quite easy).

If the replacement of 'iframe' with 'abcdef' *does* trigger the error, the cause will have also been identified, but the fix is going to take a little more work.

Cheer
RodG

[pricediscrimination]

Just for clarification, when I asked you to provide the *exact* code, that is what I meant. I don't know if your *example* is the same as the *exact* code or not.

Anyway.......

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

I have two more tests that I'd like you to make.

The first is to try this code:

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

IOW, change the two 'iframe's to 'abcdef', and let me know if the mod_security us still triggered. (note: this code won't actually function. All I/we are testing for is the triggering of the mod security rule)




It is *still* not possible to come to this conclusion with 100% certainty, because not only have you removed the possible iframe trigger, but you have *also* made the length of the input data 12 characters shorter (which is why I'm asking you to replace the iframe text with an equal number of other characters).



It is also the way this kind of thing is generally done (which I why I was questioning your method from the very outset).



Correct. Furthermore I/we are now 'this close' (holding finger and thumb together) to determining with 100% certainty whether it really is the 'iframe' causing the error or not.

If the replacement of 'iframe' with 'abcdef' *doesn't* trigger the error, I think I've identified the cause of the problem (and the fix will be quite easy).

If the replacement of 'iframe' with 'abcdef' *does* trigger the error, the cause will have also been identified, but the fix is going to take a little more work.

Cheer
RodG

Hi RodG! Yes that is the exact code from YouTube. Can be found on any YouTube and is used by the millions everyday by YouTubers.

Tried the abcdef and proceeds to preview and saves the product listing as it should. This is also evident when using YouTube's "old" embed code which used to be an object based code. They have since began supporting iframe, which apparently is the culprit with this custom field.

[RodG]

Hi RodG! Yes that is the exact code from YouTube. Can be found on any YouTube and is used by the millions everyday by YouTubers.

Shame on them. Thier code is technically incorrect.

src="//www.youtube.com/embed/whatever" is missing the protocol specifier. The correct syntax here would be:
src="http://www.youtube.com/embed/whatever"

Tried the abcdef and proceeds to preview and saves the product listing as it should.

Tadaaa! We have now definitively shown that it is the iframe that is triggering the mod_security rule.

We can now move forward......

This is also evident when using YouTube's "old" embed code which used to be an object based code. They have since began supporting iframe

Shame on them. While the rest of the world has been slowly moving *away* from iframes towards the more modern embed and/or object methods they are moving towards it.

, which apparently is the culprit with this custom field.

This is no longer an 'apparently' situation. It is a fact that we have just proven.

Oh well.... all is not lost yet.

Please try entering:

<object width="853" height="480" data="http://www.youtube.com/v/qpgTC9MDx1o"> </object>

And/or

<embed width="853" height="480" src="http://www.youtube.com/v/qpgTC9MDx1o">

Cheers
RodG

[pricediscrimination]

Please try entering:

<object width="853" height="480" data="http://www.youtube.com/v/qpgTC9MDx1o"> </object>

And/or

<embed width="853" height="480" src="http://www.youtube.com/v/qpgTC9MDx1o">

Cheers
RodG

The object code works as it should.
The embed code works too.


BTW, here is the youtube screenshot for laughs



Tried the iframe with the "http:" for more laughs but no go.

[RodG]

The object code works as it should.
The embed code works too.

Sweet. So problem solved eh? It appears that GoDaddy are only stopping the iframes.

I'm still at bit a loss why it would work in the product descriptions though - Perhaps its because it is embedded deep within another $_POST variable rather than being a variable unto itself. It's about the only thing that would be different (and would certainly explain things)

BTW, here is the youtube screenshot for laughs

What can I say, other than the simple fact that the larger the business the more likely they are to ignore industry standards and do things *their* way. I'm kinda piffed at Google these days for this kind of practice.

Tried the iframe with the "http:" for more laughs but no go.

I didn't think that this would take care of your problem, but I'll wager that there are some *browsers* that will have a hard time and/or produce an error when they encounter a URL without the "http:" specifier. Such browsers would be quite rare these days as most will check for this and automatically add it if it isn't found.

It's very poor practice though to have to rely on the browsers to make it correct though. I can't help but wonder if youtube have gotten rid of their experienced developers and replaced them with newbies that don't understand the history of why iframes and incorrectly specified URL's pose a security risk. <huge sigh>

This doesn't bode well for the future. Developers for large corporations are making the same mistakes that us 'oldies' identified and warned people about decades ago.

Anyway, unless you have any more questions I think I'm done here. However you may still want to consider lhungil's suggestion
"you could store just the youtube video IDs and then add the youtube URL portion and call oembed (or just generate the iframe + iframe URL yourself". I have several reasons for saying this:

1) It is basically the 'right' way to do it
2) It'll give you more control over the display/output (Can be controlled with .CSS)
3) It takes a bit of 'trickery' to insert/retrieve the quotes and apostrophes from a database
4) It is more efficient (because the DB trickery isn't needed).
5) It is less susceptible to bad things happening from SQL injections. (IOW, less hackable)
6) Sooner or later GoDaddy may decide to blacklist the embed/object methods as well as iframes

... and those are just off the top of my head.

Cheers
RodG

[pricediscrimination]

Sweet. So problem solved eh?

I wish but it isn't yet. Before moving to C-PAnel hosting (the onset of this iframe debacle) there were already hundreds of products listed with the iframe code. Now those are not editable unless the videos are removed and code readded to the database manually (or using the old object code).

Also, I'd like to keep it all the same ie: hundreds with iframe, keep it all iframe especially since that seems to be what youtube is supporting most moving forward.

I could try the idea of just adding the URL as a variable and making the code use that variable within a set iframe code but frankly I don't even know where to start. I was able to get the custom field working with posts from here, but I don't know how to make the input of that field into a variable used by a code to display the videos. Also this would mean going back and redoing all of the existing iframes...