FBReader as an OPDS browser and OPDS feed authentication.

[geometer]

Hello All,

I'm glad to say FBReader (an e-book reader, http://www.fbreader.org/)
now supports OPDS feeds browsing. Unfortunately different sites use
slightly different versions of OPDS, so the code should be customized
for each feed separately. At the moment we've included into FBReader a
support for 3 sites: feedbooks.com, smashwords.com and shucang.com,
however we plan to extend this list in future versions.

We're also interested to make more close integration with the
libraries and the first feature we want to implement is an
authentication on a library sites. I understand an authentication is
not a subject of OPDS standard however I think the standard can do
something for this.

My suggestion is to add a description of a list of authentication
features into a root OPDS file. Currently this file includes a URL
with search request description (or just a 'search URL' for other
sites). It might be very useful for a client (e.g., for FBReader) to
have a similar description of the authentication feature: 'a sign-in
URL', 'a sign-out URL' and may be 'a sign-up URL'. A description of
the authentication method might be also useful.

Any comments?

Best,

-- Nikolay Pultsin

[Hadrien Gardeur]

Hello Nikolay,

I'm glad to say FBReader (an e-book reader, http://www.fbreader.org/)
now supports OPDS feeds browsing. Unfortunately different sites use
slightly different versions of OPDS, so the code should be customized
for each feed separately. At the moment we've included into FBReader a
support for 3 sites: feedbooks.com, smashwords.com and shucang.com,
however we plan to extend this list in future versions.

Glad that we have another OPDS-compatible reading system on board !

When you talk about different versions of OPDS you probably mean:

• pre-OPDS/Stanza catalogs
• OPDS catalogs

At Feedbooks we support both: if you send Stanza's user-agent you get the pre-OPDS catalog support, otherwise you get OPDS. This shouldn't be a problem in the future as existing catalogs will switch to the OPDS syntax (but we really need to focus on writing the specs soon).

 

We're also interested to make more close integration with the
libraries and the first feature we want to implement is an
authentication on a library sites. I understand an authentication is
not a subject of OPDS standard however I think the standard can do
something for this.

I think that this is a very important feature too, and although we might not include all the details about authentication in the main specs, we'll need at least an informational document dedicated to this.

I expect to see two different kind of authentication in OPDS:

• HTTP Basic Auth (with SSL)
• OAuth (token-based authentication)

While HTTP Basic Auth is very important and quite easy to support, I really believe that OAuth is the right choice for the open Web.

With Basic Auth, we could be tempted to use a session cookie to keep the user authenticated, or a "magic cookie" with a specific hash that wouldn't be linked to the current session and automatically re-authenticate the user the next time that they visit the catalog.

With OAuth, no such thing would be recommended, and we would send the headers with every request (let's be RESTful and therefore, stateless). 

My suggestion is to add a description of a list of authentication
features into a root OPDS file. Currently this file includes a URL
with search request description (or just a 'search URL' for other
sites). It might be very useful for a client (e.g., for FBReader) to
have a similar description of the authentication feature: 'a sign-in
URL', 'a sign-out URL' and may be 'a sign-up URL'. A description of
the authentication method might be also useful.

Any comments?

Well, that's certainly one way of doing things but with authentication, I tend to prefer keeping things at an HTTP level rather than at an Atom level.

Stanza uses various headers to display a different authentication dialog. Along with yout 401 status code, you get these headers to display something a little more helpful for the user.

We could decide together to create specific HTTP headers for OPDS (for example X-OPDS-Registration) or maybe for some of them rely on the Link header draft.

In OAuth, you need the URL of various endpoints to properly perform the OAuth-dance and such headers would be absolutely necessary.

Hadrien

[geometer]

Hi Hadrien,

> Glad that we have another OPDS-compatible reading system on board !
> When you talk about different versions of OPDS you probably mean:
>

>    - pre-OPDS/Stanza catalogs
>    - OPDS catalogs

Yes. Moreover while OPDS specification is not stable there are
different versions
of 'pre-OPDS'. :)

> At Feedbooks we support both: if you send Stanza's user-agent you get the
> pre-OPDS catalog support, otherwise you get OPDS. This shouldn't be a
> problem in the future as existing catalogs will switch to the OPDS syntax
> (but we really need to focus on writing the specs soon).

Oh, I didn't know about this feature. :) Anyway FBReader sends
'FBReader' as a user-agent
name so we use truly OPDS version. :)

> I expect to see two different kind of authentication in OPDS:
>

>    - HTTP Basic Auth (with SSL)
>    - OAuth (token-based authentication)

>
> While HTTP Basic Auth is very important and quite easy to support, I really
> believe that OAuth is the right choice for the open Web.

That sounds good. As far as feedbooks.com is a "model" implementation
of
the OPDS stuff, does feedbooks provide OAuth method at the moment?
And anyway is there a document that describes current feedbooks
authentication
features?

> Well, that's certainly one way of doing things but with authentication, I
> tend to prefer keeping things at an HTTP level rather than at an Atom level.
> Stanza uses various headers to display a different authentication dialog.
> Along with yout 401 status code, you get these headers to display something
> a little more helpful for the user.
> We could decide together to create specific HTTP headers for OPDS (for
> example X-OPDS-Registration) or maybe for some of them rely on the Link
> header draft.
> In OAuth, you need the URL of various endpoints to properly perform the
> OAuth-dance and such headers would be absolutely necessary.

Ok, looks like I should read more about OAuth before asking my new
questions. :)

Best,

-- Nikolay

[Hadrien Gardeur]

Yes. Moreover while OPDS specification is not stable there are
different versions
of 'pre-OPDS'. :)

Well, the only two OPDS catalogs that I can think of would be Feedbooks and the Internet Archive. You'll see a few differences since we rely on the partial/full entry mechanism on Feedbooks and the IA has an atom:content field that probably makes it compatible somehow with Stanza but an OPDS client should be able to parse both without any specific hack.

 

That sounds good. As far as feedbooks.com is a "model" implementation

of
the OPDS stuff, does feedbooks provide OAuth method at the moment?
And anyway is there a document that describes current feedbooks
authentication
features?

We do have OAuth support on Feedbooks. We haven't documented our OAuth endpoints yet because I can't find any standard solution for OAuth discovery and also because I'm now closely following the development of OAuth WRAP, which could be a far easier solution to implement.

For the documentation about our authentication features it's a chicken and egg problem: I haven't worked on it yet because I'm waiting for discussions at an OPDS-level about HTTP headers.

I might document our HTTP Basic Auth, sessions and cookies support in the upcoming weeks even if we haven't finished the discussions about OAuth.

 

Ok, looks like I should read more about OAuth before asking my new

questions. :)

Take a look at OAuth WRAP too.

Hadrien

[DavidP57]

Hi,

Great news about FBReader and OPDS, however there is a feature I'd
like you to add, if possible...
Let's set up the context : I developped a tool named calibre2opds
(https://launchpad.net/calibre2opds), which creates both an HTML
catalog and an OPDS feed from the content of the Calibre database.
When used with a publishing service (such as Dropbox), this OPDS
catalog can instantly be used in ODPS-compliant readers (such as
Stanza or Aldiko).

I'd like, if possible, that the user of FBReader can add a custom OPDS
catalog ; the catalog I generate is OPDS, compatible with Stanza, so
it wouldn't be difficult to do, IMHO : simply reuse the reading code
from Feedbooks...

All best,
David.

On 21 déc 2009, 16:18, geometer <geome...@fbreader.org> wrote:
> Hello All,
>

> I'm glad to say FBReader (an e-book reader,http://www.fbreader.org/)

[geometer]

Hi David,

Thank you for your suggestion.

In fact, the set of OPDS feeds supported by FBReader is already
configurable: you can add/edit files in the config catalog
(/usr/share/FBReader/network for linux version). Of course, this way
is not suitable for users. We plan to add a user interface.

Best,

-- Nikolay

[DavidP57]

Hi Nikolay,

I tried copying the .xml file you set up for feedbooks, and edit it
with my feed URL, but it didn't work. I don't know why, opening the
catalog makes FbReader crash.
Is there a log file somewhere that I can look at ?
If you want to try it, the demo catalog is here :
http://davidsoft.free.fr/calibre2opds/demo/_catalog/catalog.xml ; it
does not contain ePub files per se, for obvious reasons, but if you
want a true catalog I can set up one for you and give you the URL in
private...

All best,
David.

[geometer]

David,

Please look at this file: http://www.fbreader.org/test/davidsoft.free.fr.xml.
FBReader can browse your catalog if you put the file into /usr/share/
FBReader/network. I'm not sure why the end-level catalog shows no
books.

Best,

-- Nikolay

[David Pierron]

Hi Nikolay, thanks for testing !

I'm happy to see that it works, when I tried yesterday it didn't. I must have done something wrong in the XML file.

I can't test it right now because I'm home, on a Mac... I'll do this tomorrow from work.

There are no books in this catalog, it's void of download links because it's a demo, and this way I can publish it without risking my ass ;)

However, if you want to test books download you can try my personal library : http://dl.dropbox.com/u/958355/calibre_library/_catalog/catalog.xml

Please keep it private though !

All best,

David.

Le 3 févr. 2010 à 16:37, geometer a écrit :

David,

Please look at this file: http://www.fbreader.org/test/davidsoft.free.fr.xml.
FBReader can browse your catalog if you put the file into /usr/share/
FBReader/network. I'm not sure why the end-level catalog shows no
books.

Best,

-- Nikolay

-- 

http://davidsoft.free.fr --- De l'influence du ciel bleu sur le moral des motocyclistes

http://www.goodreads.com/user/show/1941488 -- Goodreads

http://davidsoft.free.fr/calibre2opds/calibre2opds -- calibre2opds