What URLs does Kuboo need?

[Tailchakra]

Amazing piece of software you've got here, except I've got ubooquity behind a reverse proxy with nginx auth, this allows me to have all my services unauthed behind 1 overall auth.

location /comics/ {
auth_request /auth-4;
proxy_pass http://192.168.2.20:2202/comics/;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
add_header Vary “Accept-Encoding”;
add_header Access-Control-Allow-Origin *;
proxy_read_timeout 1800;
proxy_connect_timeout 1800;
proxy_request_buffering off;
proxy_buffering off;

location /comics/opds-comics/ {
    auth_request off;
    proxy_pass http://192.168.2.20:2202/comics/opds-comics/;
}

}

This allows me to have that auth and have /opds-comics/ "auth-less" (for lack of better words). Everything works except for that it can't reach the bookmarks. Therefor my question is this:

What are all the URLs that Kuboo needs so I can turn auth off for those particular URLs (Like bookmarks)

[befora]

This is the discussion before I wrote authentication for bookmarks here. I think this is the useful tidbits:

Tom 1 year ago
The API is behind the same authentication layer as all the other pages served by Ubooquity, which is not basic auth. Hence the issue.

I added basic auth support when I implemented the OPDS feed, because the OPDS specification requires it. But for everything else, authentication is done the following way:

Ubooquity serves a login pages, wich contains a server "salt" and the server current time
The user enters his crendentials
The browser sends the login and the hashed password (generated with the user's password, the server salt and the server time) to the server
The server returns the home page, with a cookie containg a user token
The token is included by the browser with each subsequent request
This way, the password is never sent in plain text over the network. (the token can still be intercepted and access gained, but it's still better than exposing the paswword)

I prefer to restric basic auth to the OPDS feed, because it's really unsafe when you don't use HTTPS.

So I'll try to quickly add an authentication API that can be used by external clients.

It will require some hashing work on client side to protect the password the way I described earlier, but I can provide code samples for that.

You have an interesting setup. Would you be willing to setup a mock server I could test on? I don't think I could give any useful advice without seeing logs. sethchhim@gmail.com

[befora]

URL for bookmark api

/user-api/bookmark?isBook=false&docId=<COMIC_ID>

[Tailchakra]

Mmh, I'll set up something for you in a while. Won't be home most of the rest of the week, so I'll have something next week around monday/tuesday.

The having to need a user does indeed affect what I want to achieve. I don't want my users to have the need to login again once they are already logged into the site, as is how I hoped Kuboo had a local cookies bookmark like Ubooquity has on the webclient. (My users never ever use the site, they use it solely through apps)

I'll mail you a mock server next week including what I want to achieve and why! On the road as we speak so I'm not really explaining it the best way possible haha.

--

I'm still trying to figure out how I want to do it myself, if only ubooquity had either registration or ldap - that would fix the entire issue

[befora]

I don't want my users to have the need to login again once they are already logged into the site, as is how I hoped Kuboo had a local cookies bookmark like Ubooquity has on the webclient.

Kuboo does use local bookmarks as default and then pulls from the remote api. If the remote pull is successful, it should update the local bookmark.

If you want your users to only use local bookmarks, I can implement:

• a settings toggle to prevent all remote api requests.
• a checkmark on server page to indicate reverse proxy to prevent all remote api requests

This is just a thought, look forward to your opinion when you have time.

[Tailchakra]

Mmh, that would definitely make things a lot easier. There's problably a tons cleaner solution to the need that I have, but a settings toggle to prevent remote api bookmarks would do the trick. I'd just have my users download Kuboo, have them insert https://www.domain.tld/comics/opds-comics and boom everything works. Having my ubooquity behind a reverse proxy like that makes opening comics impossible due to the bookmark api throttle.

That is though, if it's not too much of a "dirty" solution for you. Ofcourse, it's "less safe" - but the url I've set isn't guessable nor searchable by robots. The ones that do get on, well.. Then they deserve to read a comic or two for the effort 👍

[befora]

I have been thinking about this issue and wonder why doesn't the proxy relay the bookmark api requests. I believe it should work fine. You are right, the suggested solution I recommended is lazy. I would still like to test your mock setup myself and dig deeper.

[Tailchakra]

Mmh, let me do some nginx magic when I get to work. I have one specific question about /user-api/ though. To enlighten about my setup, I'm running two Ubooquities:

• One for Mangas
• One for Comics

This because I've got users who care about mangas but don't care about comics in the slightest and they've got two completely different naming schemes. I simply enable domain/manga for my manga users and domain/comics for comic users. I'm working towards a system where my users can simply click "tv, books and comics" in their settings page and they only get access to tv, books and comics.

Here's the question: Is it 192.168.2.20:2202/comics/user-api/ or is it 192.168.2.20:2202/user-api/? If it's 192.168.2.20:2202/user-api/, how nice would it play with reverse proxy? As there's no more URL base.

The issue here is this: With the reverse proxy I throw 192.168.2.20:2202/comics/ to domain.tld/comics - now would /user-api/ be domain.tld/comics/user-api/ or domain.tld/user-api/? e.g. what would kuboo check for?

[Tailchakra]

Weeelllll, I've screamed too early. Sorry for bothering you with this without trying things myself, haha! I did have to know the URL though, but apparently giving 192.168.2.20:2202/comics/user-api/ > domain.tld/comics/user-api/ full access works straight away! So no need to do anything from your side haha!

If you want I can still give you my config though?

[befora]

Ok nice work. No need to setup access for me since issue is resolved.