Skip to content
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

HTML dump: drawio files with wrong URL #1742

Open
sebix opened this issue Aug 25, 2024 · 4 comments
Open

HTML dump: drawio files with wrong URL #1742

sebix opened this issue Aug 25, 2024 · 4 comments

Comments

@sebix
Copy link
Contributor

sebix commented Aug 25, 2024

With #1741 already applied, we encountered another issue in the HTML dump.

  • Upload a .drawio (text) file as a subitem. Can be as simple as the attached one (Diagram.txt, rename to .drawio first)
  • moin dump-html
  • The page Sandkasten/Diagram.drawio shows a link to +get/+8e1c685bac8c4b2dbbda2f182a09b77b/Sandkasten/Diagram.drawio
  • File not found

The file is actually saved at +get/Sandkasten/Diagram.drawio

The error does not happen for .gpx files, but both file types are text.

@UlrichB22
Copy link
Collaborator

@sebix: Do you have an idea how to simplify the code regarding the different contenttypes?

@sebix
Copy link
Contributor Author

sebix commented Aug 26, 2024

Can you give me a hint which part of the code is relevant for this?

@UlrichB22
Copy link
Collaborator

I think it is the same area that I changed in #1741.

The condition to check whether files are copied as raw item or rendered from markup is based on the contenttype from meta data and additionally based on the file extension. Maybe it is a better idea to render only items with CONTENTTYPE_MARKUP and copy raw files for the other. Regarding CONTENTTYPE_TEXT you should test what the best solution is.

I am uncertain about the file extensions. For security reasons, do we need to check and restrict file extensions based on content type elsewhere, e.g. on item creation? When running dump-html, perhaps we can omit the file extension check?

@sebix
Copy link
Contributor Author

sebix commented Oct 11, 2024

I think it is the same area that I changed in #1741.

With the fix for #1741 applied, the bug still occurs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants