Add ability to share elements with 'unique' URL #249

Open
opened 2026-02-04 17:58:30 +03:00 by OVERLORD · 39 comments
Owner

Originally created by @alex2702 on GitHub (Jan 29, 2017).

Desired Feature:
It would be great to have a way to share single books/chapters/pages with a single party without requiring them to have an account. I realize it is possible to just make an element available to the public but this is not a great solution if I want to share content with multiple parties. Let‘s say I want to share book A with person X and book B with person Y. I don‘t think there is a way to do this without sharing books A and B with X and Y by making both books publicly available.
What I am thinking about is an obscured link with a hash like Google Docs does it.
I haven't been using BookStack for too long, so maybe I'm missing a clever way to achieve this with the existing permission system?

Originally created by @alex2702 on GitHub (Jan 29, 2017). **Desired Feature:** It would be great to have a way to share single books/chapters/pages with a single party without requiring them to have an account. I realize it is possible to just make an element available to the public but this is not a great solution if I want to share content with multiple parties. Let‘s say I want to share book A with person X and book B with person Y. I don‘t think there is a way to do this without sharing books A **and** B with X **and** Y by making both books publicly available. What I am thinking about is an obscured link with a hash like Google Docs does it. I haven't been using BookStack for too long, so maybe I'm missing a clever way to achieve this with the existing permission system?
OVERLORD added the 🛠️ Enhancement label 2026-02-04 17:58:30 +03:00
Author
Owner

@ssddanbrown commented on GitHub (Jan 30, 2017):

@wutfan Thanks for this request. I agree this would be a great feature and there's not currently a way to do this.

@ssddanbrown commented on GitHub (Jan 30, 2017): @wutfan Thanks for this request. I agree this would be a great feature and there's not currently a way to do this.
Author
Owner

@tomershvueli commented on GitHub (Jul 8, 2019):

I would also love to see this functionality!

@tomershvueli commented on GitHub (Jul 8, 2019): I would also love to see this functionality!
Author
Owner

@cunba-ai commented on GitHub (Jul 9, 2019):

3227cef715

Hijack the authenticate and bypass the url prefix '/books/', '/search/', '/uploads/images/', set the permission of one book to public, close global 'public access', and I have this feature with minimum code changes.

Hope for the official implements with QRCode url.

@cunba-ai commented on GitHub (Jul 9, 2019): https://github.com/koios-sh/BookStack/commit/3227cef715ec0b29dd82ca78171519df40cd9f1d Hijack the authenticate and bypass the url prefix '/books/', '/search/', '/uploads/images/', set the permission of one book to public, close global 'public access', and I have this feature with minimum code changes. Hope for the official implements with QRCode url.
Author
Owner

@jrnp97 commented on GitHub (Feb 4, 2022):

Any update? :)

@jrnp97 commented on GitHub (Feb 4, 2022): Any update? :)
Author
Owner

@sense-design commented on GitHub (Mar 31, 2022):

This would be a great feature

@sense-design commented on GitHub (Mar 31, 2022): This would be a great feature
Author
Owner

@Jeremylepr commented on GitHub (Apr 9, 2022):

This feature really need to be implemented.

@Jeremylepr commented on GitHub (Apr 9, 2022): This feature really need to be implemented.
Author
Owner

@Shootify commented on GitHub (May 19, 2022):

yes please...

@Shootify commented on GitHub (May 19, 2022): yes please...
Author
Owner

@caydenmb commented on GitHub (May 19, 2022):

Agreed, I would utilize this feature a lot.

@caydenmb commented on GitHub (May 19, 2022): Agreed, I would utilize this feature a lot.
Author
Owner

@Dylan-Miles commented on GitHub (Nov 22, 2022):

This feature would be very useful!

@Dylan-Miles commented on GitHub (Nov 22, 2022): This feature would be very useful!
Author
Owner

@aware2 commented on GitHub (Mar 22, 2023):

+1 for this feature ❤️

@aware2 commented on GitHub (Mar 22, 2023): +1 for this feature ❤️
Author
Owner

@onthebackof commented on GitHub (May 21, 2023):

Would be great 👍

@onthebackof commented on GitHub (May 21, 2023): Would be great 👍
Author
Owner

@mfx-jgoetzinger commented on GitHub (May 31, 2023):

+1

@mfx-jgoetzinger commented on GitHub (May 31, 2023): +1
Author
Owner

@artworklv commented on GitHub (May 31, 2023):

I totally agree, having the ability to share things using a unique URL would be an excellent feature to have!

@artworklv commented on GitHub (May 31, 2023): I totally agree, having the ability to share things using a unique URL would be an excellent feature to have!
Author
Owner

@scaphandroid commented on GitHub (Jun 20, 2023):

+1 !

@scaphandroid commented on GitHub (Jun 20, 2023): +1 !
Author
Owner

@skarados commented on GitHub (Nov 30, 2023):

Yes please! +1!

@skarados commented on GitHub (Nov 30, 2023): Yes please! +1!
Author
Owner

@chdcomputers commented on GitHub (Dec 5, 2023):

I also agree and I would like to add the following ideas:

  1. To have control over the obscured link. Probably by assigning a GUID or something else as a unique ID to each of them.
  2. Add expiration date so after a specified date and time the link won't be available any more.
  3. To have the ability to share the same thing with more than one obscured links.
  4. Add an optional description for the obscured link which will be logged (audited) along with the visits to those links
  5. The visits to these links should trigger a webhook

Cheers!

@chdcomputers commented on GitHub (Dec 5, 2023): I also agree and I would like to add the following ideas: 1. To have control over the obscured link. Probably by assigning a GUID or something else as a unique ID to each of them. 2. Add expiration date so after a specified date and time the link won't be available any more. 3. To have the ability to share the same thing with more than one obscured links. 4. Add an optional description for the obscured link which will be logged (audited) along with the visits to those links 5. The visits to these links should trigger a webhook Cheers!
Author
Owner

@lucas-strummer commented on GitHub (Mar 11, 2024):

+1! Thank you!

@lucas-strummer commented on GitHub (Mar 11, 2024): +1! Thank you!
Author
Owner

@Limerick-gh commented on GitHub (Mar 11, 2024):

+1
That would be missing piece to establish Bookstack within my department, since we don't want the hassle of username/password authentication with the end-users.

@Limerick-gh commented on GitHub (Mar 11, 2024): +1 That would be missing piece to establish Bookstack within my department, since we don't want the hassle of username/password authentication with the end-users.
Author
Owner

@DanMundy commented on GitHub (Mar 27, 2024):

+1

@DanMundy commented on GitHub (Mar 27, 2024): +1
Author
Owner

@DerMilderJoghurt commented on GitHub (Apr 4, 2024):

+1

@DerMilderJoghurt commented on GitHub (Apr 4, 2024): +1
Author
Owner

@fegrue commented on GitHub (May 26, 2024):

+1

@fegrue commented on GitHub (May 26, 2024): +1
Author
Owner

@virtadpt commented on GitHub (May 27, 2024):

This would be really helpful - kind of like the sharable links that Wallabag has.

@virtadpt commented on GitHub (May 27, 2024): This would be really helpful - kind of like the sharable links that Wallabag has.
Author
Owner

@megaxorg commented on GitHub (Aug 22, 2024):

Would be great

@megaxorg commented on GitHub (Aug 22, 2024): Would be great
Author
Owner

@prplk commented on GitHub (Sep 21, 2024):

+1

@prplk commented on GitHub (Sep 21, 2024): +1
Author
Owner

@ssddanbrown commented on GitHub (Oct 12, 2024):

Been trying to think this through so just jotting down my thoughts so they're not stuck in my head.

Proposal

  • Share menu on content (books, chapters, pages, probably not shelves) to create share links.
  • Share links lead to their own routes/controllers/views.
    • Super minimal UI & feature-set, with just content and page/context navigation.
    • Safer than punching through auth an adding extra visibility/access control.
    • Book/Chapter could complicate routing a tad with navigation within
      • plus would ideally need to handle internal cross-reference links.
  • Role permission needed for creating share link, disabled by default.
  • Overview of created links in settings/admin area.
  • Probably would need an indication/view of existing share links in entity permission controls view.
  • Share link would be entry in DB
    • Linked to entity
    • Stored creator & created date details.
    • Actual share unique ID a random gen 32 char (URL safe) value
      • Keep thinking this should have some added level of protection but we'd really want this to be accessible/reversible (to show and reuse as active share links) and any extra level of protection seems redundant.
Permission Complications
  • Not confident on what permissions these links should have. There's lots of options/assumptions that could be considered here. But I'm not keen on complicating matters here for potential needs and scenarios.
    • I'm leaning toward full view access for simplicity (in implementation and understanding/UX)
      • But then there's extra risk of over exposure which we'd probably need significant warnings at appropriate levels (for the role permission, when creating a link, when managing permissions) which spreads quite a bit of UI mess.
  • Permissions will complicate image & attachment access (which we'd really need to provide).
@ssddanbrown commented on GitHub (Oct 12, 2024): Been trying to think this through so just jotting down my thoughts so they're not stuck in my head. ### Proposal - Share menu on content (books, chapters, pages, probably not shelves) to create share links. - Share links lead to their own routes/controllers/views. - Super minimal UI & feature-set, with just content and page/context navigation. - Safer than punching through auth an adding extra visibility/access control. - Book/Chapter could complicate routing a tad with navigation within - plus would ideally need to handle internal cross-reference links. - Role permission needed for creating share link, disabled by default. - Overview of created links in settings/admin area. - Probably would need an indication/view of existing share links in entity permission controls view. - Share link would be entry in DB - Linked to entity - Stored creator & created date details. - Actual share unique ID a random gen 32 char (URL safe) value - Keep thinking this should have some added level of protection but we'd really want this to be accessible/reversible (to show and reuse as active share links) and any extra level of protection seems redundant. ##### Permission Complications - Not confident on what permissions these links should have. There's lots of options/assumptions that could be considered here. But I'm not keen on complicating matters here for *potential* needs and scenarios. - I'm leaning toward full view access for simplicity (in implementation and understanding/UX) - But then there's extra risk of over exposure which we'd probably need significant warnings at appropriate levels (for the role permission, when creating a link, when managing permissions) which spreads quite a bit of UI mess. - Permissions will complicate image & attachment access (which we'd really need to provide).
Author
Owner

@bmoellerTS commented on GitHub (Oct 23, 2024):

ich würde mich über diese Funktion auch sehr freuen

@bmoellerTS commented on GitHub (Oct 23, 2024): ich würde mich über diese Funktion auch sehr freuen
Author
Owner

@Thoroslives commented on GitHub (Oct 25, 2024):

This feature is a must for me, I often make small little docs to share but have to export them at the moment as there's no way to share the individual doc with only that person without allowing all public to view all docs (this is without creating an account etc)

@Thoroslives commented on GitHub (Oct 25, 2024): This feature is a must for me, I often make small little docs to share but have to export them at the moment as there's no way to share the individual doc with only that person without allowing all public to view all docs (this is without creating an account etc)
Author
Owner

@CarrnellTech commented on GitHub (Oct 30, 2024):

+1

@CarrnellTech commented on GitHub (Oct 30, 2024): +1
Author
Owner

@cgct commented on GitHub (Nov 14, 2024):

+1

@cgct commented on GitHub (Nov 14, 2024): +1
Author
Owner

@edersong commented on GitHub (Dec 10, 2024):

It's the only feature that this awesome application is lacking of 😀

@edersong commented on GitHub (Dec 10, 2024): It's the only feature that this awesome application is lacking of 😀
Author
Owner

@LegendaryFire commented on GitHub (Dec 10, 2024):

Just search this up and ran across this thread actually, definitely a +1 from me as well.

@LegendaryFire commented on GitHub (Dec 10, 2024): Just search this up and ran across this thread actually, definitely a +1 from me as well.
Author
Owner

@vytas911 commented on GitHub (Jan 16, 2025):

would be much appreciated +1

@vytas911 commented on GitHub (Jan 16, 2025): would be much appreciated +1
Author
Owner

@netAction commented on GitHub (Jan 19, 2025):

+1

The discussed features are much more than the desired features. Google Docs does not add any code to the share URL. You simply share the regular URL of that document. Viewing a shared Google Docs page is like Bookstack without shelves and books overview page. The guest role should have an option to disable "recent activity" panel, "recent pages" panel and /books.

Pro: The URL of a page is always the same. Everyone has the same deep link. Sharing can be done with the already existing guest role functionality. External users can use links between all books and pages until they reach something that is not shared with public.

Con: The names of books can be guessed. If your project's documentation has the url /books/alice, you know there will be something at /books/bob and /books/cindy. Easy fix: Always add a code to book URLs in case they might be shared later.

@netAction commented on GitHub (Jan 19, 2025): +1 The discussed features are much more than the desired features. Google Docs does not add any code to the share URL. You simply share the regular URL of that document. Viewing a shared Google Docs page is like Bookstack without shelves and books overview page. The guest role should have an option to disable "recent activity" panel, "recent pages" panel and /books. Pro: The URL of a page is always the same. Everyone has the same deep link. Sharing can be done with the already existing guest role functionality. External users can use links between all books and pages until they reach something that is not shared with public. Con: The names of books can be guessed. If your project's documentation has the url /books/alice, you know there will be something at /books/bob and /books/cindy. Easy fix: Always add a code to book URLs in case they might be shared later.
Author
Owner

@netAction commented on GitHub (Jan 20, 2025):

A simplification of the proposal from @ssddanbrown:

Share menu on content

Yes to the menu but it could just create a reading permission for the guest group

Share links lead to their own routes/controllers/views

I don't like multiple URLs for the same content very much and don't think it's neccessary.

Super minimal UI & feature-set, with just content and page/context navigation.

Sounds great and would make Bookstack usable as poor man's CMS. Like for documentations.

Stripping out the lists of recent changes, list of books etc. even hides books that the receiver of the URL should not see. The minimal UI differentiates the books from each other.

Book/Chapter could complicate routing a tad with navigation within
plus would ideally need to handle internal cross-reference links.

Another reason for keeping the existing URLs. The OP mentioned Google Docs and they keep the URL too. Editors could even link between books.

Overview of created links in settings/admin area.

This feature is useful and would be versatile if it would not cover share links but all group permissions.

Probably would need an indication/view of existing share links in entity permission controls view.

Yes! A share link feels like guest group access anyway. It could simply be guest access.

Keep thinking this should have some added level of protection but we'd really want this to be accessible/reversible (to show and reuse as active share links) and any extra level of protection seems redundant.

As a security feature, a random code could be added to every new book/chapter/page path. Just a random string at the end like /books/holiday-plans/page/trip-df5g6df5g6

The security might be even a reason against dedicated share links. Because share links can't hide one page of a shared book. Group access rules can.

@netAction commented on GitHub (Jan 20, 2025): A simplification of the proposal from @ssddanbrown: > Share menu on content Yes to the menu but it could just create a reading permission for the guest group > Share links lead to their own routes/controllers/views I don't like multiple URLs for the same content very much and don't think it's neccessary. > Super minimal UI & feature-set, with just content and page/context navigation. Sounds great and would make Bookstack usable as poor man's CMS. Like for documentations. Stripping out the lists of recent changes, list of books etc. even hides books that the receiver of the URL should not see. The minimal UI differentiates the books from each other. > Book/Chapter could complicate routing a tad with navigation within > plus would ideally need to handle internal cross-reference links. Another reason for keeping the existing URLs. The OP mentioned Google Docs and they keep the URL too. Editors could even link between books. > Overview of created links in settings/admin area. This feature is useful and would be versatile if it would not cover share links but all group permissions. > Probably would need an indication/view of existing share links in entity permission controls view. Yes! A share link feels like guest group access anyway. It could simply be guest access. > Keep thinking this should have some added level of protection but we'd really want this to be accessible/reversible (to show and reuse as active share links) and any extra level of protection seems redundant. As a security feature, a random code could be added to every new book/chapter/page path. Just a random string at the end like /books/holiday-plans/page/trip-df5g6df5g6 The security might be even a reason against dedicated share links. Because share links can't hide one page of a shared book. Group access rules can.
Author
Owner

@yrosman commented on GitHub (May 6, 2025):

+1

@yrosman commented on GitHub (May 6, 2025): +1
Author
Owner

@Thoroslives commented on GitHub (May 9, 2025):

Is there any progress on this feature request? I feel its a big one and its not received any response from the dev for a good long while

@Thoroslives commented on GitHub (May 9, 2025): Is there any progress on this feature request? I feel its a big one and its not received any response from the dev for a good long while
Author
Owner

@matteosavio commented on GitHub (May 10, 2025):

+1

@matteosavio commented on GitHub (May 10, 2025): +1
Author
Owner

@MundMBo commented on GitHub (Jun 12, 2025):

+1

@MundMBo commented on GitHub (Jun 12, 2025): +1
Author
Owner

@Kofl commented on GitHub (Jan 4, 2026):

+1

@Kofl commented on GitHub (Jan 4, 2026): +1
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/BookStack#249