-
Notifications
You must be signed in to change notification settings - Fork 48
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
pkp/pkp-lib#1660 Customizable Reviewer Recommendations #444
base: main
Are you sure you want to change the base?
Conversation
73e1b28
to
664f865
Compare
6ffce94
to
843402d
Compare
a6bffdd
to
eb21d67
Compare
6a02187
to
3a9b03d
Compare
3a9b03d
to
9a47b49
Compare
9a47b49
to
fe6774b
Compare
406d064
to
253ac65
Compare
70c9f3f
to
b8beae3
Compare
3fc09e1
to
a3dc39d
Compare
this.openDialog({ | ||
name: 'delete', | ||
title: this.deleteRecommendationLabel, | ||
message: this.replaceLocaleParams(this.confirmDeleteMessage, { |
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.
This is an XSS flaw -- any HTML entered in the recommendation.title
will be passed through to the browser. (Also the other keys that mix user-supplied data in here.)
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.
@asmecher good spot . I had this left out as v-strip-unsafe-html
was not yet available for main
as we introduced in 3.4.0
. But then forgot to update these as v-strip-unsafe-html
was added just about a week ago in main branch .
One question , rather than applying this for replaceLocaleParams
every time like
message: this.replaceLocaleParams(this.confirmDeleteMessage, {
title: sanitizeHtml(this.localize(recommendation.title)),
})
should we add this sanitizeHtml
into the implementation of replaceLocaleParams
so that we don't need to make sure to add this every time ?
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.
XSS is by default prevented by vue.js, and in cases where we use (and sometime overuse) v-html, its now replaced with v-strip-unsafe-html. Therefore this will go through that. Every component is responsible to do the XSS protection.
Therefore Dialog handles that when rendering message.
<div v-strip-unsafe-html="message" />
No point to sanitize twice.
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.
@jardakotesovec, I used a <i>
tag to confirm that entered HTML was passed through, and I didn't check whether more malicious tags were filtered -- so it's possible that <i>
gets through because it's "safe", but worse HTML would be filtered. However, it's still incorrectly escaping the content. The reviewer recommendation title is plaintext, not a rich text field, so any entered content should be fully escaped before getting glued into the locale string.
import dialog from '@/mixins/dialog.js'; | ||
import fetch from '@/mixins/fetch'; | ||
import cloneDeep from 'clone-deep'; | ||
import ReviewerRecommendationsEditModal from './ReviewerRecommendationsEditModal.vue'; |
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 see that you created some components with options api and some with composition api. This looks bit of mix of both. Mainly options API, but also using composables which are mainly intended for composition API.
Any chance we could have this consistently using composition api.
There is no need to use ajaxError, dialog, fetch mixins. We have all these covered in useModal and useFetch. We already have lots of usage examples and these are actually quite well documented and I am also able to respond on mattermost for any usage questions.
@@ -0,0 +1,472 @@ | |||
<template> |
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 am putting these new 'managing' components to the src/managers
We could name it something like ReviewerRecommendationsManager
@@ -0,0 +1,472 @@ | |||
<template> | |||
<div data-cy="reviewer-recommendation-list-panel"> | |||
<PkpTable aria-label="Reviewer recommendations list"> |
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.
You can find more details in storybook - https://main--6555d3db80418bb1681b8b17.chromatic.com/?path=/docs/components-table--docs#general-guidelines
But long story short, aria-label is unnecessary. This table gets automatically linked to its label, which you did provide. So that fine. And even if would use aria-label somewhere it would have to be localised.
<TableCell> | ||
<label> | ||
<input | ||
class="text-blue-900 bg-gray-100 border-gray-300 focus:ring-blue-500 dark:focus:ring-blue-600 dark:ring-offset-gray-800 dark:bg-gray-700 dark:border-gray-600 h-5 w-5 rounded focus:ring-2" |
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.
Styled checkboxes probably come with redesigned forms.
So yeah, we don't have that yet. It would be fine to use unstyled checkbox meanwhile. But not big deal either way.
return RecommendationTranslations[reviewAssignment.recommendation] | ||
? t(RecommendationTranslations[reviewAssignment.recommendation]) | ||
: null; | ||
const recommendation = recommendations.filter( |
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.
for this use case I think recommendations.find would be better fit?
@@ -277,7 +276,7 @@ function getDays(config, reviewAssignment) { | |||
return null; | |||
} | |||
|
|||
export function useDashboardConfigReviewActivity() { | |||
export function useDashboardConfigReviewActivity(recommendations) { |
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.
very minor thing - I am trying to follow convention of using one object as first arguments, even if its one thing, because in future there might be more. So it could be useDashboardConfigReviewActivity({recommendations})
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.
Thanks @touhidurabir. This is very nicely integrated with new code base. I am not sure whether this is aimed for 3.5, so I would understand if some of the 'composition api' updates would be left out for timeline purposes.
But if you decide to do the upgrade and struggle with something feel free to message me directly on mattermost. I should be able to point you to some good example or something.
It's scheduled for 3.6, and I was considering pulling it forward to 3.5 -- but I'd rather spend a bit more time to get a clean implementation than rush it in. So let's leave it on the 3.6 milestone. |
…omponent to support OMP/OPS
for pkp/pkp-lib#1660