[Kavita] Using 36 character GUIDs for the OPDS URL is insane.

[darrenoc3]

Idea Description

The purpose of the OPDS URL is to download books onto reading devices, which typically have slow & cumbersome software keyboards. I guess someone thought it would be clever to use the Kavita API key as the URL, but this makes no sense from a practicality or security perspective (putting a secret key into a URL means it's no longer a secret). Nobody wants to type in a 36 character GUID by hand into multiple different clients.

Other solutions like Calibre and Calibre-web use a simple approach - http://localhost/opds

Idea Category

API

Duration of Using Kavita

No response

Before submitting

• I've already searched for existing ideas before posting.

[therobbiedavis]

At first I didn't want to reply because some of your phrasing comes off as condescension and brash however on a second read it seems you just may misunderstand the OPDS implementation, so I'll explain.

With Kavita's implementation each user has their own unique OPDS url which only shows media based off their permissions. The intention is for only the user to use this url and therefore a "security through obscurity" is the approach because most apps don't allow a basic auth on the feed.

On the other hand there is no role based permission on Calibre's implementation, it's just a generic easily guessable URL that shows everything for everyone.

We welcome suggestions, so what do you suggest? All I know is your don't want the API key in the feed url and you don't want a long url.

[DieselTech]

I'll add to that because while Kavita can be ran on a local network, it is mainly designed to be accessed remotely over the internet. Having just a blank opds URL would be a security risk. There needs to be some kind of auth system here.

[darrenoc3]

Security through obscurity is considered a meme for a reason, though. If anyone is exposing their Kavita server directly to the internet without a reverse proxy or VPN then they should at least use a client that supports basic authentication (I'm not personally aware of any OPDS clients that don't support this?). Stuffing 36 chars of entropy into a URL that's otherwise publicly accessible and unauthenticated doesn't make it any safer in real terms.

From what I know of the self hosting community, the average user that is self-hosting Kavita is likely 1) hosting only one library for personal use and 2) fairly tech savvy, so if I was making a suggestion would to optimise for that use case and if someone is dumb enough to expose that directly to the internet without any auth or other safeguards then that's on them. You could still achieve role-based OPDS by having additional /opds/$foo URLs for each additional user without needing to use lengthy GUIDs.

I think maybe you think I'm nitpicking here, but if you pick up an e-ink device (extremely low refresh rate, laggy software keyboard) and try to punch in a Kavita OPDS URL maybe you'll see where I'm coming from. Even making one typo in the GUID (somewhat likely given the precision of the input method) is a huge pain. It's a great project and it would be a shame if people bounced off it due to this.

[therobbiedavis]

I don't think you're nit-picky, I understand the desire for a shorter URL and better security. I will say that OPDS is pretty much a dead spec and I wish we didn't support it. The only reason we do is because it's still being used by a lot of apps.

Panels and Yomu both allow an optional login to be passed to the OPDS feed, and it looks like the spec does support it. I wonder if we didn't include it due to some legacy app that doesn't support it.

I'll need @majora2007 to comment on the rationale. https://drafts.opds.io/authentication-for-opds-1.0.html

[majora2007]

The only thing I'm taking away from this is that the user wishes for a shorter authentication url for devices that cannot load the webui to perform a copy/paste of the url.

This is a valid point, however, at this time I cannot commit to any changes in the system. I'm not interested in basic auth for OPDS.

[catofnineswords]

I am a user who was shocked to see the OPDS url being so ... long. While I might be inclined to cut'n'paste that url into my eReaders, I certainly won't be typing it out by hand, my friends and family would not. This method of accessing the feed is obscure and very tech-geek centric. I'd be tempted to put redirect urls on my site, just to get around this low effort solution.

OPDS is a well known and well used standard for ebook feeds and I have not seen anyone else call it dead. If you believe so, what alternative feed transport will you propose?

Whatever is chosen, +1 for a proper authentication. It's so very easy to get wrong.

[majora2007]

As of the upcoming v0.8.9 release (currently live in nightly), this is now solved. Users can create their own auth keys of length between 6-32 characters.