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:

1. Ubooquity serves a login pages, wich contains a server "salt" and the server current time
2. The user enters his crendentials
3. 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
4. The server returns the home page, with a cookie containg a user token
5. 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.

Thanks for the info !

Very nice indeed !

I have updated the theme list on Ubooquity website to include it.

Appart from any potential memory leak in Ubooquity (there still might be some), Java will generally use as much memory as you give it when working on memory intensive operations (image handling in Ubooquity for instance).

To restrict the max amount of memory Ubooquity can use, your have to launch it using the command line and the "Xmx" flag.

For instance the line

java -Xmx512m -jar Ubooquity.jar

will launch Ubooquity and give it a maximum of 512 MB to work with.

I still have no lead to follow to try to understand this.

The only advice I can give is to check that there is no permission issues, as other users in this thread seem to have solved the problem this way.

According to your logs, all your Epub files seem to be unzipped (you have folders named "something.epub").

Ubooquity needs actual Epub files, not folders containing the inner parts of an Epub file.

About the bookmarks:

http://ubooquity.userecho.com/topics/499-expose-server-bookmarks-via-opds/

As far as I know, there is no concept of bookmark in the OPDS specifications.

But nothing prevents third party apps from using the bookmarking REST API added in 2.0.

I don't have enough time to write a proper doc, but it's really easy to use. For instance, the URL for comics bookmarks is:

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

To create, read or delete a bookmark, you just have to replace <COMIC_ID> with the actual id of the comic (already provided in the OPDS feed) and call the URL with the appropriate HTTP verb (i.e. PUT, GET or DELETE).

A comic bookmark is simply the page number as the body of the request.

For books, the URL is the same, with "isBook" set to true instead of false.

A book bookmark is the chapter number (as defined in the spine of the epub file) and the percentage of progression in the current chapter, separated by a #, e.g:

3#0.100277615274158379

The thing is, during those two years, my backlog kept growing.

So I now have even more features I want/need to implement before considering system specific features.

And the two reasons explained above still stand (although you're right about the file format having no impact on the feature).

So I'll decline again, sorry.

Shared directories and users (with their password) are stored in the preferences files (preferences.json).

Unfortunately for you, the format has changed between 1.x and 2.x.

If your concern is only the users, I'd advise to manually edit the new preferences file and add them using the info taken from the old preferences.xml file.

Let me know if you need additional info to do that.