[7641] Multiple share fixes (parents, access to attachments with credentials, exclude note from share)

[x1arch]

1. Fix share parents by the path share/{share_parent_id}/{share_note} Cloned collection, after sharing, on shared page have generated wrong links for left menu, when you have more than 2 clones. #7641
2. Added new attribute #shareExclude for exclude note from share totally, implemented for remove scripts from share.
3. Updated readme, dev section

It fix my problem, will be grateful if someone test it more precisely.

I tested attachments, images all is works like a charm. Old routes /{note_id} redirects by default to /{parent_id}/{note_id}.

[gemini-code-assist]

Summary of Changes

Hello @x1arch, I'm Gemini Code Assist¹! 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 refactors the sharing mechanism to properly handle parent-child relationships in shared notes by introducing a new URL path structure. It also adds a new #shareExclude attribute to control which notes are accessible via sharing, improving security and content management. Additionally, it includes updates to development documentation and .gitignore for better project maintainability.

Highlights

• Share Parent Path Fix: Implemented a new URL structure for shared notes, allowing them to be accessed via share/{share_parent_id}/{share_note}. This ensures correct parent-child relationships in shared content and updates the getSharedSubTreeRoot logic to consider the parent ID.
• #shareExclude Attribute: Introduced a new attribute #shareExclude that prevents a note from being shared or accessed directly. This is particularly useful for hiding sensitive content like scripts from shared views and is reflected in routing and note visibility filters.
• Relative Path Adjustments: Updated numerous internal links and asset paths within shared notes (e.g., CSS, JS, images, attachments, and linked notes) to correctly resolve relative URLs in the new nested sharing structure, ensuring assets load correctly.
• Documentation & Dev Experience Improvements: Enhanced the README.md with detailed dependency installation instructions for Debian and Alpine, and added troubleshooting tips for pnpm issues. The new #shareExclude attribute is also documented in the User Guide.

Using Gemini Code Assist

The 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 /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

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 .gemini/ folder in the base of the repository. Detailed instructions can be found here.

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

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request correctly implements a new URL structure for shared notes to handle multiple parent paths and adds a #shareExclude attribute. However, there's a critical issue with how relative paths to assets and API endpoints are constructed throughout the code. With the new nested URL structure, many of these paths will be broken. I've provided suggestions to fix these paths. Additionally, I've pointed out a minor code simplification in the new route handler.

[x1arch]

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 #shareContentAccess, default cookie, token expiration timeout could be configured via #shareAccessTokenTimeout in seconds, by default 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.

Added two attributes for modify share template, now it could be possible to hide left panel (#shareTemplateNoLeftPanel) or bottom prev next navigation (#shareTemplateNoPrevNext).

[eliandoran]

@x1arch , would it be possible for you to split the functionalities in different PRs?
Changing the share URL format needs thorough consideration since it can break the existing user functionality. I've noticed there is a redirect in place, but for example some people might have strict rewrite rules in the reverse proxy which might prevent them from accessing the share functionality after an upgrade.

[x1arch]

it can break the existing user functionality.

Not sure about that, could you provide real config example which could broke anything? I've add one more section in path can't imagine rewrite rule which could be broken by that. By default it will use the same behavior like now, just take random parent and show it. I tested it with caddy and nginx it works as expected without any modifications.

would it be possible for you to split the functionalities in different PRs?

Of course I could, but that will mean, the path changed PR never will be merged, right?

for example some people might have strict rewrite rules

They could update rewrite rules, isn't it?

PS in theory we could add parent id to cookie and allow switch it to path by the label, as it made with access. I don't like this option because it is implicit behavior, but you're the boss.

[eliandoran]

it can break the existing user functionality.

Not sure about that, could you provide real config example which could broke anything? I've add one more section in path can't imagine rewrite rule which could be broken by that. By default it will use the same behavior like now, just take random parent and show it. I tested it with caddy and nginx it works as expected without any modifications.

I'll investigate.

would it be possible for you to split the functionalities in different PRs?

Of course I could, but that will mean, the path changed PR never will be merged, right?

Not necessarily, I'm not against the idea but I think we need to refine it first. Nevertheless, splitting it helps things get merged faster.

for example some people might have strict rewrite rules

They could update rewrite rules, isn't it?

They sure could, but it's best to avoid breaking changes. We have to balance the benefit of the change versus the impact.

PS in theory we could add parent id to cookie and allow switch it to path by the label, as it made with access. I don't like this option because it is implicit behavior, but you're the boss.

What about using query parameters to specify the path? That shouldn't break anything, right?

[x1arch]

What about using query parameters to specify the path? That shouldn't break anything, right?

I don't like it, when we use path, we do not need modify template all works as is (I mean the left menu, bottom navigation), with query we need to modify every link. And it's looking ugly, like not from here, it's ok, if user don't see it (as with attachments) but for address line, no sir.