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

[arabshapt]

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.

[DavidPesticcio]

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:

[vbatts]

Sharable links would be helpful

[JFPCreations]

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.

[nichwall]

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

[advplyr]

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.

[nichwall]

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

[Torstein-Eide]

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)

[advplyr]

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

[nichwall]

(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.

[Torstein-Eide]

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.