Fix share access to attachments for notes protected by login:password #7828
Conversation
dosubot
bot
added
the
size:L
Summary of ChangesHello @x1arch, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request enhances the sharing functionality for notes protected by credentials, specifically by improving how attachments and other embedded content are accessed. It introduces flexible authentication mechanisms using cookies or query parameters to ensure secure delivery of content, alongside new configuration options to customize the shared page layout and content visibility. Highlights
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces a robust mechanism for handling access to protected attachments in shared notes, which was a significant limitation. The addition of cookie-based and query-param-based tokens is a good solution, and the new configuration labels provide great flexibility. The code is mostly well-structured, but I've identified a few areas that need improvement regarding type safety, code clarity, and potential security vulnerabilities. I've pointed out a critical type issue, a potential token leak, and several medium-severity issues related to maintainability and correctness.
|
@x1arch , so if I understand correctly the issue is that images and other assets are not rendered in password-protected shares, right? What's the reason why it's failing, aren't HTTP authorization headers sent again by the browser (cached credentials) for images as well, provided the domain and realm are the same? |
|
Originally it should, but not works. The same problem if you will try to use document headers img headers |
There was a problem hiding this comment.
FYI, I'm quite fine with the implementation, apart from the requested changes.
However, in the future please take the time to discuss first the request and perhaps even the implementation. It's much easier for me to review and test something that has already been discussed, and it also decreases the chances of being rejected after the work has already been done.
I would also appreciate it if we keep the PRs minimal. For example, in this PR there's also 5 different new labels that were introduced, with only 2 of them actually relating to the work at hand.
| function addContentAccessQuery(note: SNote | BNote, secondEl?:boolean) { | ||
| if (!(note instanceof BNote) && note.contentAccessor && note.contentAccessor?.type === "query") { | ||
| return secondEl ? `&cat=${note.contentAccessor.getToken()}` : `?cat=${note.contentAccessor.getToken()}`; | ||
| } | ||
| return "" | ||
| } |
There was a problem hiding this comment.
Why have three different mechanisms in place for content accessors? This creates a maintenance burden that I don't think is justified.
I would say that we choose one and stick to it.
Honestly, I prefer the query parameter one since it explicitly indicates access and perhaps it can even be more useful (think copy and pasting it into another Trilium instance, which will be able to download the image strictly from the URL instead of requiring a cookie).
|
|
||
| > If you faced with some problems, try to delete all `node_modules` and `.pnpm-store` folders, not only from the root, from every directory, like `apps/{app_name}/node_modules`and `/packages/{package_name}/node_modules` and then reinstall it by the `pnpm install`. | ||
| Share styles not compiling by default, if you see share page without styles, make `pnpm run server:build` and then run development server. |
There was a problem hiding this comment.
It's enough to do pnpm --filter=share-theme build instead of pnpm run server:build because that one takes a lot longer to execute.
2 participants
Split this PR: #7759
I faced with issue, browser do not sent Authorization header for pictures and attachments. I added cookie based authorization and query based authorization (for browsers with disabled cookies), could be configured by label
#shareExcludefor exclude note from share totally, implemented for remove scripts from share.#shareTemplateNoPrevNextfor hide bottom prev next navigation.#shareTemplateNoLeftPanelfor hide left panel totally.#shareContentAccessfor manually setup content access auth, default is cookie. Bould be basic / query / cookie.#shareAccessTokenTimeoutfor manually configure token expiration timeout in seconds. (default value is 10 minutes)Token lives in the note, I use one token for multiple access, otherwise the token will overrides by every request and users will interfere with each other.