Open BloodDrag0n opened 1 year ago
@spassarop - Can you answer this question? Thx
Regarding var
you can add a new <regexp>
tag based on others such as "cssOnsiteUri", placed inside <common-regexps>
section of your policy file. Then you can reference it on any property that applies, the same as the "cssOnsiteUri" example. A valid regexp for that could be var\(--\w+(-\w+)*\)
, be as strict as you need to, preferably.
However, I'm not sure Batik-CSS (AntiSamy's CSS parser) supports CSS variables. In that case, the var
usage may be useless because the output won't contain any surviving variables. To confirm this I need to do some deep debugging first, but that is my preliminary answer.
Thank you for your response, I am using CssParser instead of BatikCSS, but I am not sure whether that supports CSS variables too.
Batik CSS is a dependency to parse the CSS to analyze, CssParser uses it internally. If Batik considers CSS variables as invalid CSS “code”then CssParser never gets to see them, it would not be the first time Batik provides less than we expect.
On Thu, 19 Jan 2023 at 05:48 Suganth M @.***> wrote:
Thank you for your response, I am using CssParser instead of BatikCSS, but I am not sure whether that supports CSS variables too.
— Reply to this email directly, view it on GitHub https://github.com/nahsra/antisamy/issues/286#issuecomment-1396628522, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHL3BMN3EYAM6XLPDJR7DVTWTD5U5ANCNFSM6AAAAAAT52ZE3I . You are receiving this because you were mentioned.Message ID: @.***>
I did the heavy debugging. The org.apache.batik.css.parser.Scanner
class has it's own criteria when it encounters hyphens and it does not contemplate the existence of CSS variables. The logic automatically expects other character combination following a hyphen and the parser gets messed up internally, spitting CSS nothing like the original with empty stuff.
To sum up, the Batik-CSS dependency does not support CSS variables and AntiSamy cannot work with them as it never gets to see them in the internal parser's output. I guess this would result in wontfix
because it is far from what we can achieve by coding, correct me if I'm wrong @davewichers.
@spassarop - you are the expert on these internal details so I trust your analysis. I think our only real option here, if you want to investigate is replacing the CSS parser with something newer, more transparent, more open, but that's up to you. There are a number of won't fix, like this that are all stuck because of Batik. If you decide to research, open an issue like: "Investigate replacing Batik CSS". And you can link that ticket to all the won't fixes caused by Batik doing things internally we can' see/change/affect. We should maybe even create that ticket even if you don't want to spend time actually investigating this, just to link all the related issues together.
Yeah, all that seems reasonable.
El mar, 24 ene 2023 a las 11:57, Dave Wichers @.***>) escribió:
@spassarop https://github.com/spassarop - you are the expert on these internal details so I trust your analysis. I think our only real option here, if you want to investigate is replacing the CSS parser with something newer, more transparent, more open, but that's up to you. There are a number of won't fix, like this that are all stuck because of Batik. If you decide to research, open an issue like: "Investigate replacing Batik CSS". And you can link that ticket to all the won't fixes caused by Batik doing things internally we can' see/change/affect. We should maybe even create that ticket even if you don't want to spend time actually investigating this, just to link all the related issues together.
— Reply to this email directly, view it on GitHub https://github.com/nahsra/antisamy/issues/286#issuecomment-1402083490, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHL3BMMZNWY7ZBP42TRQG5DWT7UWVANCNFSM6AAAAAAT52ZE3I . You are receiving this because you were mentioned.Message ID: @.***>
Thank you @spassarop and @davewichers for the detailed clarification, even if we use some other css parser instead of batik css, is there any possibilities on supporting custom css variables in antisamy. My organisation is using CSS Parser 0.9.20. I don't know whether it has support or not, but will I can't work with the variables in that either.
I can't discard the possibility that there is a working parser with that feature. But as Dave wrote, that needs intense research to find out if all current features are available. Also if such library exists, a strong refactoring and testing process must be carried on because the current code is tightly coupled with Batik-CSS.
Anyway, until that happens, there is no way AntiSamy can be adapted to support CSS variables.
I'm linking the new issue #293 as suggested.
I want to whitelist the custom css properties in my page and I can't find any reference for the custom css properties to write in my policy file, can anyone provide me with a clarificarion.