Handle Markdown in Prose and Other Fields about oscal-react-library HOT 8 CLOSED

• It probably should deal with both viewing/editing in markdown in some way

Any sort of complicated editing capabilities are not required as part of the initial implementation of markdown support. Only viewing is necessary for the initial component.

from oscal-react-library.

Markdown + the url parameter needs to be careful to not accidentally open up an XSS vulnerability.

from oscal-react-library.

https://github.com/remarkjs/react-markdown is another possible render.

from oscal-react-library.

@schen2166 & @kperk103 I wanted to also post the rough plan for getting this done here so more people can see.

1. Create the OSCALMarkdownProse component
   • At the most basic level it would export a ReactMarkdown component remarkjs/react-markdown: Markdown component for React (github.com)
   • It probably should deal with both viewing/editing in markdown in some way? I am not 100% on this aspect and think you two may know a bit more than me on it.
   • Tests should be easy and also means we do not have to actually implement it anywhere to merge in this pr
   • A very initial draft pr should be made by tomorrow afternoon. This can be extremely basic. Just start getting discussion going since people will most likely have opinions on implementation.
2. Implement the component where it makes sense
   • This will require some planning to split it up in a logical way
   • Hopefully your component makes this super easy to more or less just paste in
   • E2E tests should cover this and make it really easy? You might be able to get away with just component testing though.

Lets try to keep as much of the discussion on planning here and to use draft prs a lot. I think this task should be pretty easy with good planning but could easily get a little messy.

from oscal-react-library.

https://marked.js.org/ or something like it could be an option. But we'd definitely want to sanitize and probably find a way to strip any <script> or maybe even <style> tags in a sanitization process (since many Markdown parsers support raw HTML). A nice thing about Markdown is that it's fairly readable as-is without being rendered. We may want to consider using workers to asynchronously perform the rendering as well and we can cancel them if they work for too long.

What we really want to avoid is me being able to make a "malicious" control catalog and passing around links that load scripts or that make the UI thread lock up rendering markdown. Of course, the other thing would be if our default catalog that we load had a buggy markdown somewhere that did the same thing.

I am maybe being a little overly cautious here. There are probably other places that we're loading data from the internet and displaying it to users but this is one where we have far less control over the rendering pipeline.

from oscal-react-library.

Issue #556 is another subtask where there was markup written in prose in the backmatter. The commit there addresses the necessary changes for the backmatter

from oscal-react-library.

@kylelaker @brian-easyd Demo of Issue #156 for acceptance https://easydynamics-my.sharepoint.com/:v:/p/niqbal/EVohd_Csn51OnQ09gFAH2osB65GDEKvCnjOI69rnAWNQ9A?e=ysfjUo

from oscal-react-library.

I agree this is complete

from oscal-react-library.