-
Notifications
You must be signed in to change notification settings - Fork 9.4k
Add Function isEncoded to Base64 and check ids of image in tiny mce #11025
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Can I help with something @okorshenko @orlangur ? |
Please do correct me if I'm wrong, but it seems that it's not possible to guarantee that a string was base64-encoded. |
The problem it's assume that you can have a widget and this is encoded in base64. In this case if string is encoded in base64 proceed to decode. If not base64 because is a normal string not try to decode. |
I'm not sure whether you understand my point. Let me try to illustrate it with an example: would you say that I'm pretty sure that the kind of solution you suggest here doesn't cover this case. It just can't do that and I'm pretty sure you'll see that if you perform some tests on it. The only way to reliably fix this issue IMHO is to prefix any base64 data with an explicit header when it's encoded , similar to the data-uri prefix used when embedding base64 images into |
Oh sorry, Now I understand you. I Can make this change with prefix, but I don't know if can be accepted by core team. |
@@ -364,6 +364,7 @@ var Fieldset = { | |||
var Base64 = { | |||
// private property | |||
_keyStr: 'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/=', | |||
_notBase64 : /[^A-Z0-9+\/=]/i, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
More precise regexp may be used to verify is string looks like base64 encoded or not:
(?:[A-Za-z0-9+/]{4})*(?:[A-Za-z0-9+/]{2}==|[A-Za-z0-9+/]{3}=)
@osrecio, @korostii In my opinion placing some prefix would not be correct as this would be implicit knowledge about how this string is used and will lead to code coupling and bugs in future. Instead, we may use one of the following approaches:
In the same time I think that possibility to validate that some data is in Base64 format is a good feature to have (it is necesary condition but not sufficient). |
With all due respect, it's actually the exact opposite. Right now the knowledge is absent (there might be base64, or might be not). If you add an explicit prefix, then you know for sure whether it's base64 or not.
It's not possible to validate whether a string is base64 with 100% accuracy, there will always be false positives. Please carefully see my comment above for a counter-example. Sure, the
Data URLs seem like the perfect choice here, no need to invent a bicycle. Please also note that in either case adding an additional format would be backwards-incompatible, just like the recent change to use JSON instead of PHP-serialized data in 2.2. |
Agree now knowledge is absent. And this should be fixed. What I'm trying to say that if we will add just prefix then we will need to add this prefix handling in a lot of places. A risk to forget correctly handle this prefix may create new bugs in unpredictable places (we can not control how this string is used ion 3rd party extensions). So we need to join data (let's say some string format) and knowledge how they should be processed in one place. This knowledge should not belong to Base64 but to some another abstraction.
But we may say with 100% accuracy that something is not base64 encoded string. So it may be useful to "fail early".
Totally agree. I also would prefer Data URLs. But JavaScript objects with Actually, BiC is also blocker for implementing simple prefix addition as this would be format change. Usage of prefix is not making possible to detect base64 strings but introduces own custom format on top of base64 |
Closing due to inactivity. Feel free to reach me out anytime later if you wish to continue work on this pull request and it will be reopened. |
BTW: This issue still exists on Magento CE 2.2.5. I got the same error when pasting in this line:
The '-' in the id causes the error. |
(https://user-images.githubusercontent.com/58260277/70425955-354fe100-1a98-11ea-8a21-08bc3078a19f.png) Still the issue is reproduced on magento2.3.3 |
Added function to Base64 js class to avoid error with
window.atob
Description
Added function
isEncoded
to Base64 js classAdded check in setup.js in
decodeWidgets
function to check if id is Base64Encoded StringAdded check in editor_plugin.js in
tinyMCE.init
function to check if id is Base64Encoded StringFixed Issues (if relevant)
Manual testing scenarios
Content -> Pages -> New Page
<img src='test.jpg' id='test />
or<img src='test.jpg' data-id='test />
error: error in [unknown object].fireEvent(): event name: tinymceSetContent error message: Failed to execute 'atob' on 'Window': The string to be decoded is not correctly encoded.
Contribution checklist