markdown-it-include
markdown-it-include copied to clipboard
Add support for "absolute" root syntax
This PR introduces support with the "absolute" path syntax:
- if the include path is specified in a relative syntax (e.g.
./L1/foo.md) or without any leading path (e.g.L1/foo.md), then the inclusion occurs the same way as yet - if the include path has a leading slash (e.g.
/foo.md), the inclusion path is computed from the root path as declared inoptions.root
It allows to include files without having to know where the included files is located relatively to the parent file.
It may fix issue #13 by referencing the included file from the root directory by using this "absolute root" syntax.
@m4dz I think I heard you at Snow Camp, nice to comment your PR ;-) However, as me mentionned in this PR https://github.com/camelaissani/markdown-it-include/pull/22 using absolute paths can be a huge security problem because a smart markdown writer can leak some system conf files (if the server isn' t properly configured).
So without challenging the value of your proposal, be sure that anyone that uses this trick will deeply understand what risk he takes. Anyway, I let @camelaissani decide what is better for his module ;-)
@m4dz thank you for the contribution.
Actually I'm considering to forbid to include files with path starting by a /. As written by @riegelTech it might open a door to leak some files which are not intended to be included in a markdown. Using a / in the include path is a way to get rid of the rootdir and point anywhere in the system.
However your PR is interesting as it brings the support of relative paths which have not specified ./ at the begining (L1/L2/r.md with your code becomes ./L1/L2/r.md)
About issue #13, I'm not sure this PR will help. From what I understood what it is expected there is to change somehow the img url accordingly to the include path. IMO, it is not something that can be tackled in this plugin.
WDYT about modifying your PR to keep only the fix you made on the relative path?
Thanks for your feedback all!
I probably misdescribed this feature, so let me bring some light to it 😃
Currently, when you include a file with a path starting with a /, the plugin follows the unix convention and looks to the file from the filesystem root.
With this PR, any include path starting with a / is looked from the rootdir rather than the root of the filesystem. To me, it allows different things:
- being able to include files anywhere from the
rootdir, without having to think on complex relative paths depending on the filesystem structure inside therootdir, and independently where your original file is located (i.e. include/my/partials/file.mdwill always include the file located to[rootdir]/my/partials/file.mdregardless the location of the file querying for inclusion) - propose an alternative fix to #22 as any file starting with a
/is now looked fromrootdirand not from/
(sorry for my misreference to #13, this PR is unrelated)
We can see it as a chroot system for the inclusion file lookup 🤩
Does it makes more sense? Or did I missed something in your reviews?
Thanks!
Hey @camelaissani, any news about this one? Tell me if you need some feedback from me 😃