starred/audiobookshelf
1
0
Fork 0
mirror of https://github.com/advplyr/audiobookshelf.git synced 2026-05-30 23:40:40 +02:00
Code Issues 1.0k Packages Projects Releases 10 Wiki Activity

[Enhancement]: Sharing presigned link to specific book/books #1134

New Issue
Closed
opened 2026-04-24 23:33:38 +02:00 by adam · 10 comments
adam commented 2026-04-24 23:33:38 +02:00
Owner
Copy Link
Copy Source

Originally created by @arabshapt on GitHub (May 11, 2023).

Describe the feature/enhancement

Imagine you are listening to an audiobook and want to share it and maybe also a timestamp/progress point to not only share access to a book but also to this specific part in the book.
It should be easy to choose the right point. Because typically we want to share a part that we heard about a minute or so ago.
I don't know how challenging it is, but it would be great if I could share a book without adding a new user. This link should have an expiration date and it should be throttled in case the link gets leaked and hundreds of devices try to access the book.
Thank you for this project.

Originally created by @arabshapt on GitHub (May 11, 2023). ### Describe the feature/enhancement Imagine you are listening to an audiobook and want to share it and maybe also a timestamp/progress point to not only share access to a book but also to this specific part in the book. It should be easy to choose the right point. Because typically we want to share a part that we heard about a minute or so ago. I don't know how challenging it is, but it would be great if I could share a book without adding a new user. This link should have an expiration date and it should be throttled in case the link gets leaked and hundreds of devices try to access the book. Thank you for this project.
adam added the enhancement label 2026-04-24 23:33:38 +02:00
adam closed this issue 2026-04-24 23:33:38 +02:00
adam commented 2026-04-24 23:33:41 +02:00
Author
Owner
Copy Link
Copy Source

@DavidPesticcio commented on GitHub (Feb 27, 2024):

This could also include having a normal link to a book or podcast, with optional timestamp, for sharing with another user - which would simply require them to login with their credentials. Which was exactly what I wanted to be able to do today. 😄 👍

@DavidPesticcio commented on GitHub (Feb 27, 2024): This could also include having a normal link to a book or podcast, with optional timestamp, for sharing with another user - which would simply require them to login with their credentials. Which was exactly what I wanted to be able to do today. :smile: :+1:
adam commented 2026-04-24 23:33:41 +02:00
Author
Owner
Copy Link
Copy Source

@vbatts commented on GitHub (Apr 18, 2024):

Sharable links would be helpful

@vbatts commented on GitHub (Apr 18, 2024): Sharable links would be helpful
adam commented 2026-04-24 23:33:41 +02:00
Author
Owner
Copy Link
Copy Source

@JFPCreations commented on GitHub (Jun 19, 2024):

Just what I'm looking for. I'd like to be able to share a link to one episode, but without having the person to be a user. So a public link to one episode or book, with or without timestamp. Also, the link can have an expiration date. Thank you.

@JFPCreations commented on GitHub (Jun 19, 2024): Just what I'm looking for. I'd like to be able to share a link to one episode, but without having the person to be a user. So a public link to one episode or book, with or without timestamp. Also, the link can have an expiration date. Thank you.
adam commented 2026-04-24 23:33:42 +02:00
Author
Owner
Copy Link
Copy Source

@nichwall commented on GitHub (Jun 19, 2024):

You can share a book or podcast episode without needing someone to sign in by using an RSS feed. This just makes the files available, there is not a time stamp option.

https://www.audiobookshelf.org/guides/rss_feeds

@nichwall commented on GitHub (Jun 19, 2024): You can share a book or podcast episode without needing someone to sign in by using an RSS feed. This just makes the files available, there is not a time stamp option. https://www.audiobookshelf.org/guides/rss_feeds
adam commented 2026-04-24 23:33:42 +02:00
Author
Owner
Copy Link
Copy Source

@advplyr commented on GitHub (Jul 9, 2024):

Added in v2.11.0

This is not full featured yet. There are some remaining items. A guide will be written mentioning these also.

Current limitations:

  1. Only for books now but will be extended to podcast episodes.
  2. The share audio player only supports direct playing. Audio files must be playable directly by the clients browser.
  3. There is no separate page in config listing the open shares but there is a library filter to see open shares

The UI also may be updated in the future to put in a timestamp to share a specific time in the media item. If you add a ?t=1234 where 1234 is the number of seconds that is supported already.

@advplyr commented on GitHub (Jul 9, 2024): Added in [v2.11.0](https://github.com/advplyr/audiobookshelf/releases/tag/v2.11.0) This is not full featured yet. There are some remaining items. A guide will be written mentioning these also. Current limitations: 1. Only for books now but will be extended to podcast episodes. 2. The share audio player only supports direct playing. Audio files must be playable directly by the clients browser. 3. There is no separate page in config listing the open shares but there is a library filter to see open shares The UI also may be updated in the future to put in a timestamp to share a specific time in the media item. If you add a `?t=1234` where 1234 is the number of seconds that is supported already.
adam commented 2026-04-24 23:33:43 +02:00
Author
Owner
Copy Link
Copy Source

@nichwall commented on GitHub (Jul 9, 2024):

An initial guide is available at https://www.audiobookshelf.org/guides/media-item-shares/

@nichwall commented on GitHub (Jul 9, 2024): An initial guide is available at https://www.audiobookshelf.org/guides/media-item-shares/
adam commented 2026-04-24 23:33:44 +02:00
Author
Owner
Copy Link
Copy Source

@Torstein-Eide commented on GitHub (Jul 14, 2024):

Great work @advplyr .

This is a feature i have missed.

I notice there is a limit around 23 days, is this by design?

Would it not be more secure to use UUID as default? uuid=$(cat /proc/sys/kernel/random/uuid)

@Torstein-Eide commented on GitHub (Jul 14, 2024): Great work @advplyr . This is a feature i have missed. I notice there is a limit around 23 days, is this by design? Would it not be more secure to use UUID as default? `uuid=$(cat /proc/sys/kernel/random/uuid)`
adam commented 2026-04-24 23:33:44 +02:00
Author
Owner
Copy Link
Copy Source

@advplyr commented on GitHub (Jul 15, 2024):

What do you mean limit around 23 days?

I based the random slug off of how the filebrowser server does it https://github.com/filebrowser/filebrowser
The difference is the slug is editable in Abs implementation so you could make it longer if you wanted

@advplyr commented on GitHub (Jul 15, 2024): What do you mean limit around 23 days? I based the random slug off of how the filebrowser server does it https://github.com/filebrowser/filebrowser The difference is the slug is editable in Abs implementation so you could make it longer if you wanted
adam commented 2026-04-24 23:33:45 +02:00
Author
Owner
Copy Link
Copy Source

@nichwall commented on GitHub (Jul 16, 2024):

(It would probably be good to open new issues with the Share feature so they can be tracked easier than in successive comments, but keeping these logs together with the conversation)

Using server version 2.11.0, I also found that shares that are 23 days or shorter will be created correctly, but shares that are 25 days or longer are not created correctly. If I open a share for 23 days, then delete it and create a new share of 24 days (without closing the modal) the share will be accessible. If I just try and create a share for 24 days, I could not get that to work consistently. I did not see this same behavior with 25+ minutes or hours.

Log for "23 days" share:

2024-07-15 20:10:21.790   INFO   [ShareManager] Scheduled media item share "89a96859-8e4d-479c-b4a6-967c94452e73" to expire in 1987198480ms
2024-07-15 20:10:27.551   DEBUG  [ApiCacheManager] device.afterCreate: Clearing cache
2024-07-15 20:10:27.552   INFO   [ShareManager] Adding new open share playback session "Abaddon's Gate"

Log for "24 days" share:

2024-07-15 20:11:46.118   INFO   [ShareManager] Scheduled media item share "2c50c1b5-d50a-439e-9e66-a9ab4a4efb4c" to expire in 2073599281ms
2024-07-15 20:11:54.907   DEBUG  [ApiCacheManager] device.afterCreate: Clearing cache
2024-07-15 20:11:54.907   INFO   [ShareManager] Adding new open share playback session "Abaddon's Gate"

Log for "25 days" share:

2024-07-15 20:13:20.940   INFO    [ShareManager] Scheduled media item share "337f3ff4-3a85-47df-83a0-2fa5b690dcdb" to expire in 2159999107ms
2024-07-15 20:13:20.943   INFO    [ShareManager] Removing expired media item share "337f3ff4-3a85-47df-83a0-2fa5b690dcdb"
2024-07-15 20:13:21.430   DEBUG   [ApiCacheManager] Object.afterBulkDestroy: Clearing cache
2024-07-15 20:13:25.652   WARN    [ShareController] Media item share not found with slug fnmX7txUpM

Sometimes the 24 days share works, and sometimes it doesn't. Not sure what could be causing it to immediately expire.
Screenshot from 2024-07-15 20-15-56

@nichwall commented on GitHub (Jul 16, 2024): (It would probably be good to open new issues with the Share feature so they can be tracked easier than in successive comments, but keeping these logs together with the conversation) Using server version 2.11.0, I also found that shares that are 23 days or shorter will be created correctly, but shares that are 25 days or longer are not created correctly. If I open a share for 23 days, then delete it and create a new share of 24 days (without closing the modal) the share will be accessible. If I just try and create a share for 24 days, I could not get that to work consistently. I did not see this same behavior with 25+ minutes or hours. Log for "23 days" share: ``` 2024-07-15 20:10:21.790 INFO [ShareManager] Scheduled media item share "89a96859-8e4d-479c-b4a6-967c94452e73" to expire in 1987198480ms 2024-07-15 20:10:27.551 DEBUG [ApiCacheManager] device.afterCreate: Clearing cache 2024-07-15 20:10:27.552 INFO [ShareManager] Adding new open share playback session "Abaddon's Gate" ``` Log for "24 days" share: ``` 2024-07-15 20:11:46.118 INFO [ShareManager] Scheduled media item share "2c50c1b5-d50a-439e-9e66-a9ab4a4efb4c" to expire in 2073599281ms 2024-07-15 20:11:54.907 DEBUG [ApiCacheManager] device.afterCreate: Clearing cache 2024-07-15 20:11:54.907 INFO [ShareManager] Adding new open share playback session "Abaddon's Gate" ``` Log for "25 days" share: ``` 2024-07-15 20:13:20.940 INFO [ShareManager] Scheduled media item share "337f3ff4-3a85-47df-83a0-2fa5b690dcdb" to expire in 2159999107ms 2024-07-15 20:13:20.943 INFO [ShareManager] Removing expired media item share "337f3ff4-3a85-47df-83a0-2fa5b690dcdb" 2024-07-15 20:13:21.430 DEBUG [ApiCacheManager] Object.afterBulkDestroy: Clearing cache 2024-07-15 20:13:25.652 WARN [ShareController] Media item share not found with slug fnmX7txUpM ``` Sometimes the 24 days share works, and sometimes it doesn't. Not sure what could be causing it to immediately expire. ![Screenshot from 2024-07-15 20-15-56](https://github.com/user-attachments/assets/10a56eee-47ec-4f50-b2e5-3f0400ff20c7)
adam commented 2026-04-24 23:33:45 +02:00
Author
Owner
Copy Link
Copy Source

@Torstein-Eide commented on GitHub (Jul 16, 2024):

What do you mean limit around 23 days?

I made #3164, like @nichwall points out it get removed after 1-3 ms, if the timelimit is longer then ~23 days.

I based the random slug off of how the filebrowser server does it https://github.com/filebrowser/filebrowser The difference is the slug is editable in Abs implementation so you could make it longer if you wanted

I know we can make it longer.

Slugs are okay if you combined with some authentication.

Is it bad to think that the program should default to security? and the user can make it less secure?

  • immich, uses 67 random characters.
  • sharry, uses 47 random characters.
  • Dropbox, Uses 44+25 random characters

Rate limit of access to new share per IP can also increase time. like if IP x.x.x.x tries /share/1234567890a when for the next request from IP x.x.x.x to f.eks /share/a1234567890, sleep for 1 sec before responing.

@Torstein-Eide commented on GitHub (Jul 16, 2024): > What do you mean limit around 23 days? I made #3164, like @nichwall points out it get removed after 1-3 ms, if the timelimit is longer then ~23 days. > I based the random slug off of how the filebrowser server does it https://github.com/filebrowser/filebrowser The difference is the slug is editable in Abs implementation so you could make it longer if you wanted I know we can make it longer. Slugs are okay if you combined with some authentication. Is it bad to think that the program should default to security? and the user can make it less secure? * [immich](https://github.com/immich-app/immich/), uses 67 random characters. * [sharry](https://github.com/eikek/sharry), uses 47 random characters. * Dropbox, Uses 44+25 random characters Rate limit of access to new share per IP can also increase time. like if IP x.x.x.x tries /share/1234567890a when for the next request from IP x.x.x.x to f.eks /share/a1234567890, sleep for 1 sec before responing.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
authentication
backlog
bug
chapter editor
config-issue
ebooks
encoding/embedding
enhancement
help wanted
listening sessions & progress
planned
possible plugin
progress sync
pull-request
Mirrored from GitHub Pull Request
 sorting/filtering/searching
unable to reproduce
upload
users & permissions
waiting
No Label enhancement
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam (Adam Melkus)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/audiobookshelf#1134
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?