Content Server always prompts for library, but it shouldn't need to

[haertig]

Given the content Server setup below, why does it prompt me to select the library (of which there is only one, named "Calibre").

Once I have manually selected the library from the single choice available (silly), then the Content Server does indeed honor the setup I have that limits this user to only "vl:Novels". But why do I have to select the library on initial startup? Is there a workaround to stop this mandatory selection that isn't needed in the first place (the box next to "Calibre" is checked in the setup, but seems to be ignored)?

I'm running Calibre version 3.12

Thanks in advance for any tips/suggestions.

[kovidgoyal]

The home page display all recently read books as well as libraries and is designed to work in offline mode. THe library listing page is not. If you never want your users to use the server in offline mode, then get them to bookmark the library listing page instead of the home page.

[haertig]

Thanks for the reply. You have written some fantastic software here, and are extremely quick and helpful in addressing questions. I wish all people I interacted with were as good as you!

===

That's what I've been doing. But I found a bug in that route. Which is what made me start investigating hitting the main Content Server webpage and not a library bookmark.

The first time you access the Content Server using a bookmark to the library page, before the Content server has had any chance to store its local data in your browser, you get the login/password popup. You authenticate, and it puts you right on the library page that I want. Expected operation. After authenticating, I told the browser (Chromium version 62) to remember my password.

Then I exited the browser and did the exact same thing again. The login/password popup hit the screen for about 1/2 second, then automatically dismissed itself, then I got a "401 unauthorized" message from the Content Server. This is unexpected behavior. In the brief 1/2 second that the login/password popup appears, I can see that my saved login information is being displayed. the bad operation appears as if the login/password popup is being populated, but then immediately canceled rather than being submitted.

Additional info: When this behavior begins, if I keep clicking on the same library bookmark over and over, somewhere between the 4th and 6th click - it lets me in normally! I and not changing anything in my process, just clicking the bookmark repeatedly, and finally it works. [ I know, "Doing the same thing over and over and expecting a different result is the definition of insanity." But in this case, it worked! ]

More info: If, after this behavior begins, I go into Chromium settings and manually delete all of Calibre's locally stored data, then try the bookmark again, then it works fine this way too.

Yet more info: I cannot duplicate this behavior in Firefox (version 57). That browser works perfectly every time when using a bookmark directly to the library. So my initial guess is that this is some interaction between Chromium and locally stored data and authentication. I can't say this for sure, but that's the way it appears. If I turn off user authentication, then everything works fine.

Here is the error that I get:

Failed to load books from calibre library, with error:
Failed to communicate with "/calibre/interface-data/books-init?library_id=Calibre&sort=author_sort.asc%2Cseries.asc&1511363334946", with status: [401] Unauthorized

And here is the bookmark that I am using:

http://10.192.0.26/calibre/#library_id=Calibre&panel=book_list&sort=author_sort.asc,series.as

I have found through my testing that I have to include "library_id=Calibre" in the bookmarked URL. however, I do NOT need to include the "vl=Novels" part, as that seems to be handled by the user definition in Calibre (shown above, in my initial post).

[kovidgoyal]

That's odd, the content server code does not do anything with saving passwords, that'ss all handled by the browser. I dont see why it should behave that way. I see from the URL that you appear to be accessing the server using a URL prefix. Does the problem still occur without the prefix?

[haertig]

I've done some more testing. All of my above reports were accessing the Content Server via an NGINX reverse proxy (running on 10.192.0.26) The actual Content Server is running on 10.192.0.2.

If I access the Content Server directly, not via the NGINX proxy, then the strange behavior does NOT happen. It works just fine. So is NGINX possible caching something that is causing me this problem? I have set "proxy_buffering off", so I wouldn't expect that, but I am still learning NGINX and could be missing something. I'll have to investigate more.

FWIW, here are my Content Server reverse proxy settings. You can see that eventually I plan to require a client cert to access the Content Server, but that is commented-out now since I haven't gotten to that step yet.

#               ssl_verify_client optional;
                location /calibre {
#                       if ($ssl_client_verify != SUCCESS) {
#                               return 403;
#                       }
                        proxy_buffering off;
                        proxy_set_header X-Forwarded-For $remote_addr;
                        proxy_pass http://10.192.0.2:8080$request_uri;
                }

The entire reason I an using NGINX is because I want to use HTTPS with the Content Server, and also require client cert authentication. I realize that the Content Server allows for login/password authentication. My preference is for a higher level of security than that, hence the client certs. While I don't really desire the Content Servers login/password authentication, this is required when setting up "users", which also provides me with the ability to restrict access to only one virtual library (this is desirable, but not absolutely essential). The reason why ssl_verify_client is "optional" is because there are other "locations" that NGINX reverse proxies (unrelated to Calibre), and these other locations do not require client cert authentication. By doing things this way, I only have one set of SSL directives up at the "server" block level, and then I can choose to require/omit client cert authentication at the "location" level with the "if" statement. At least that's the plan - I haven't tested it yet.

I believe what I will finally end up doing is removing the user configuration from the Content Server. This should get rid of the authentication problems I am addressing in this thread. Getting rid of Content Server user configs will also get rid of my ability to lock users into only one virtual library. But that can be overcome by setting a bookmark that points to the library. With such a bookmark, but no user configuration, the user would be able to "escape" from the initial virtual library that the bookmark points them to, and view other vl's. That's not a terribly big deal. If they want to go to that effort, they deserve to confuse themselves. The confusion might come because I have a separate vl named "Wanted". These are books that I don't have, but want to obtain. I use that in conjunction with the excellent "Overdrive" Calibre plugin to search for wanted books in various public libraries (traditional physical buildings). If the user escapes from my "Novels" virtual library into my entire Calibre library, then my Novels (which I own) will be intermixed with my Wanted books (which are empty placeholders), possibly causing confusion.

[haertig]

I have moved forward a bit and gotten HTTPS working with the NGINX reverse proxy for the Content Server.

And I have gotten the "require client cert for authentication" working too. So now my Content Server is nice and secure. NGINX will not let anyone past the front gate until they provide a client cert that I have personally signed.

Next step is for me to turn OFF the Content Server's "Require username and password to access the content server" checkbox. But if I do that, this will apparently also disable the user config setting of "Allow guest to make changes (i.e. grant write access?)" BTW, "guest" is the name of the user profile I previously set up.

I don't want anybody to be able to make changes via the Content Server, but it appears that the only way to prohibit this is to configure user profiles, which is what I was just trying to turn off. So I looked around in the Content Server web user interface, and I cannot find anything, anywhere, where the user could change anything. So if I were to "grant write access" (which I don't want to do anyway), what exactly would I be granting them access to do? I can't find anything available for writing. Or is this setting reserved for potential future use only, and has no effect in the current implementation?

FWIW, here are the server blocks I am using in NGINX to accomplish all this:

        server {
                listen 80;
                return 301 https://$host$request_uri;
        }

        server {
                listen 443 ssl http2;
                server_name my.domain.name localhost 10.192.0.26 default_server;
                root /var/www;

                ssl_certificate /etc/letsencrypt/live/my.domain.name/fullchain.pem;
                ssl_certificate_key /etc/letsencrypt/live/my.domain.name/privkey.pem;
                ssl_client_certificate /etc/ssl/certs/ca.crt;
                ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
                ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PSK:!AES128';
                ssl_ecdh_curve secp384r1;
                ssl_prefer_server_ciphers on;
                ssl_stapling off;
                ssl_stapling_verify off;
                ssl_session_timeout 24h;
                ssl_session_cache shared:SSL:50m;
                ssl_session_tickets off;
                ssl_verify_client optional;

                location /calibre {
                        if ($ssl_client_verify != SUCCESS) {
                                return 403;
                        }
                        proxy_buffering off;
                        proxy_set_header X-Forwarded-For $remote_addr;
                        proxy_pass http://10.192.0.2:8080$request_uri;
                }
        }

Next up, is to review my SSL settings (the ciphers that I specified, other stuff, etc.) to make sure that is solid and secure before turning this loose on the open internet.

[kovidgoyal]

Currently there are no major write actions that can be performed, but that will change in the future see https://github.com/kovidgoyal/calibr...e/srv/TODO.rst

[haertig]

Originally Posted by kovidgoyal

Currently there are no major write actions that can be performed, but that will change in the future see https://github.com/kovidgoyal/calibr...e/srv/TODO.rst

In that case, it would be nice if you could add the following radio buttons (choose only one) for Content Server write permissions:

• Allow write for all users
• Deny write for all users
• Allow/Deny write for users based on user profile (implies that user profiles MUST be in use)

Additionally, it would be nice if you'd allow the following radio buttons (again, choose only one):

• No authentication for all users
• Authentication required for all users (individual passwords defined in each user profile, but can be null)

And in the user profile the choice:

• Allow user to change their password
• Password can only be changed by Calibre administrator

Thus, you could define a "guest" login, without password, that has only read permissions. I'm not saying this is wise, given the potential for copyright violations. But some Calibre administrators may want to make books they personally have written available for free, thus copyright is not an issue. You never really know how Calibre will be used in the wild.

I remember in a different thread I mentioned something about allowing user profiles without authentication (because I was planning to provide my own, as demonstrated in this thread) and you replied that you wouldn't do that, because it wasn't secure and administrators could inadvertently cause copyright violations. But I might counter this by saying that if you don't set up user profiles at all, then it certainly isn't secure either, since there is no authentication in that case. And the single authentication method you do provide is login/password, which is the most easily abused by users, most easily hacked by bad guys, and weakest form of authentication available anywhere. Plus, these logins/passwords are sent in the clear I assume, so a man-in-the-middle with a packet sniffer gains access too (I didn't do any testing/sniffing to see if this is indeed the case, but I'm postulating that it probably is). I would be happy to see a big bold warning in Calibre reminding people that they should not have the Content Server available in the internet-at-large without authentication, and passwords should be of decent length and complexity. But leave it as a warning/suggestion, not a mandatory configuration. Some administrators may want to enforce better security (maybe with reverse proxy and client certs, maybe with VPN, whatever). Let them. And some may want to tempt fate and have no security at all. Well, ... let them too. It also seems inconsistent to enforce login/password if user profiles are enabled, but not enforce it if profiles are not used.

Don't get me wrong - I'm not complaining, I'm just making a suggestion. I think Calibre is one of the best thought out and best implemented pieces of software I have ever had the pleasure of using.

[kovidgoyal]

write actions are dangerous. I am absolutely not willing to open write actions to un-authenticated users. Sure in your particular use case, its fine because you have moved authentication out of the content server. But in general if it were possible to allow un-auth write then people would do it, and one of those un-auth write servers would get all its books deleted by some mischevious person and then I'd have to deal with angry posts along the lines of "calibre ate all my books".

[kovidgoyal]

Also I dont know if it is possible with nginx but if you really want to move authentication out of the content server intot he proxy server, all your need to do is turn on basic auth in the content server and simply have the proxy server write the appropriate auth header into the requests it forwards to the content server.