-
Notifications
You must be signed in to change notification settings - Fork 96
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
decode entities in toast message #1640
Conversation
Hiya, First off, thank you for this contribution. We added a new pull request template to this repository yesterday - but it looks like your PR description isn't using it. Did the template show up when you created this pull request? |
hey @GuySartorelli it did show but i have to admit i didn't read it :-/ it seems to me that since everything was already pretty much explained in the linked issue that felt like doing the work twice and i was already quite busy getting the two pr ready |
I've added the template back in - please add any manual testing steps, or if there aren't any that are specific to this PR, please point back at the reproduction steps in the issue. Please also tick all of the boxes that you have done, and do whatever is still not done based on the checklist. |
Hi @GuySartorelli. While i understand the need to raise the quality level of the PR to avoid burdening the team, sometimes it feels like a real pain to get across some changes. Ultimately, it's up to the team to determine how/where things go (eg: NOT using the current method of escaping text that is not XSS safe), or to refactor the utility to do so somewhere that makes sense so that i can be used across the whole project. |
The idea here is that we've added a new template to make things faster - by following the template, there's a higher degree of certainty that all of the small things have been done, and that there's enough context for someone (me in this case) to come along and review the work. This is a new process we're trying, and I'd really appreciate your help in testing the process by following it. Frankly I'm not going to spend my time reviewing this or the related PR this side of christmas if the process isn't being followed, because if the process isn't followed it increases the amount of effort that goes into reviewing the PRs. |
:-) yup i understand that fully but it's pretty much the same thing for me, it's not really easy to explain to a customer that it took half a day to solve some badly escaped characters due to the open source nature of the project => the main issue remaining are: |
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.
A few things here I'm unsure about.
Please also update the commit message to include FIX
at the start (see commit message guidelines)
client/src/legacy/LeftAndMain.js
Outdated
var statusMessage = function(text, type) { | ||
text = jQuery('<div/>').text(text).html(); // Escape HTML entities in text | ||
jQuery.noticeAdd({text: text, type: type, stayTime: 5000, inEffect: {left: '0', opacity: 'show'}}); | ||
jQuery.noticeAdd({text: decodeEntities(text), type: type, stayTime: 5000, inEffect: {left: '0', opacity: 'show'}}); |
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.
On line 191 we have a message that is being passed into a decodeURIComponent
function - it seems likely there's a risk of double-decoding there, if that's even a thing. Should we remove the call to decodeURIComponent
on that line?
statusMessage(decodeURIComponent(msg), msgType);
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.
The same thing is happening in
if(msg) statusMessage(decodeURIComponent(msg), (status === 'success') ? 'success' : 'error'); |
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.
as far as i'm aware, there is only a risk of double encoding, not double decoding but i may be wrong here
at any rate, "it seems to work" on my end with my changes. i know that's not a very satisfactory answer :-)
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.
I guess the thing I'm worried about (and it is an extreme edge case so maybe we can ignore it? I'd want feedback from others in @silverstripe/core-team though) is if someone intentionally wants the encoded form.
e.g. a page called "Are " and ' the same thing?
"
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.
i'm not sure either, i just did what needed in order to fix all my use cases :)
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.
I've just tried creating a page called Are " and ' and ' the same thing?
both with this (and the framework) PR, and without them.
In both cases, the toast displays like this:
So this PR is still not handling some characters (&
specifically in this case) correctly.
Can you please look into that?
802906e
to
d921e36
Compare
so i have made a small update
|
It's worth notice that I cannot reproduce the original issue with I do see a problem with |
Ahh, I see! By scrutinising the screenshot I realised that's a I think any fix for this will need to unify those two approaches - i.e. whatever code sitetree is used for decoding/sanitising/etc toast messages should be used my gridfields, and vice-versa. |
@GuySartorelli so i finally got some time to get to the bottom of this Here is the situation Indeed, in the cms it's working fine. This is the current code: It works, because the title is not escaped and rawurlencoded We could do the same thing and I'll be happy to update my PR silverstripe/silverstripe-framework#11105 accordingly and drop this one (ie: remove the escaping, and add the rawurlencode) It does raise the question of :
|
Not sure - there's nothing in the PR that shows why it would be necessary. I suspect it was just a copy-paste from somewhere doing something different-but-similar.
I strongly suspect it just wasn't known to be unsafe - I wouldn't have known if you hadn't mentioned it. |
I've merged the framework PR which solves the majority of the toast problems. I'd support swapping out For this PR, if you're up for it, could you please tackle the problem where |
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.
Works great! Just one small change request.
I tested out the title About Us &'😅<script></script>
in the pages admin and in a model admin.
Works with every scenario in the pages admin.
Works with saving in the model admin, but other actions (publishing, unpublishing, archiving) transform the emoji:
Published Company "About Us &'ð��<script></script>"
@GuySartorelli yes, it seems indeed the Versioned gridfield has the same issue And var name updated. |
01abe48
to
6f46868
Compare
Rebased and built JS. Once CI is green I'll merge. |
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.
Works great locally. Thanks again!
Description
Decodes toast message entities, which are encoded before they're sent from the server. See also silverstripe/silverstripe-framework#11105
Side bonus : this is much safer than using jquery
Manual testing steps
Go to model admin to a record with a ' in the name or any utf8 character like ö or an emoji
Click save
Discover the utf8 encoded ' that is not displayed properly in the toast message
Issues
Pull request checklist