Google Reader API: Add feed icon URL endpoint

[jocmp]

Adds an endpoint to the Google Reader integration to serve feed icon URLs.

The /icon/{iconHash} route is an unauthorized endpoint. This is consistent with other feed readers like FreshRSS (icon source code).

To obfuscate the Icon ID, the icon hash is used instead. The SHA-256 hash should generate a hexadecimal value which is url safe.

The subscription output looks something like this:

{
  "subscriptions": [
    {
      "id": "feed/2",
      "title": "Miniflux",
      "categories": [
        {
          "id": "user/1/label/All",
          "label": "All",
          "type": "folder"
        }
      ],
      "url": "https://miniflux.app/feed.xml",
      "htmlUrl": "https://miniflux.app/",
      // New!
      "iconUrl": "http://localhost:8080/reader/api/0/icon/de85ae3cff9c2356c54beb6f09eb7ec4ff9dde0ee485e5b2b36ecf0835241fa5"
    }
]

Have you followed these guidelines?

• I have tested my changes
• There are no breaking changes
• I have thoroughly tested my changes and verified there are no regressions
• My commit messages follow the Conventional Commits specification
• I have read this document: https://miniflux.app/faq.html#pull-request

[jvoisin]

To obfuscate the Icon ID, the icon hash is used instead. The SHA-256 hash should generate a hexadecimal value which is url safe.

What's the point of this?

[jocmp]

@jvoisin I went with this direction given a comment from the initial "Share article" PR #475 (comment)

Not sure if you need to expose the entryID to the public URL. The share token should be enough. Just to avoid exposing internal IDs publicly. The share code/token could have a unique constraints as well in the SQL migration.

So in the same way, this avoids exposing the internal Icon or Feed IDs for these endpoints.

[fguillot]

This API call should probably return a 404 if the icon hash is not found in the database instead of 500 with the body {"error_message":"store: unable to fetch icon: sql: no rows in result set"}.

[jocmp]

Updated. This should now return the standard 404 message

// GET http://localhost:8080/reader/api/0/icon/foobar
{
  "error_message": "resource not found"
}

[fguillot]

Updating IconByHash() to take sql.ErrNoRows into consideration is more appropriate because we need to make the distinction between a database error and no result found.

Look at store.IconByID() and api.getIconByIconID() if you need an example.

[jocmp]

gotcha, I re-added the 500 handling and added in 404 handling that will also catch sql.ErrNoRows.

[fguillot]

It would be nice to use HTTP caching similar to the web ui in feed_icon.go.

[jocmp]

Good call. I copied over that code but happy to work out an abstraction if desired.

Testing in my browser, the second call correctly returns 304 Not Modified.

[jvoisin]

So in the same way, this avoids exposing the internal Icon or Feed IDs for these endpoints.

Then you might want to use something like an HMAC instead, as an attacker could simply download a bunch of favicon from popular feeds, and check if they exist on the navidrome instance.

[jocmp]

HMAC could work. I'll take another pass at this.

[fguillot]

HMAC requires a secret key. How would that be implemented?

[jocmp]

There's a few options, really open to any:

Option 1: Integration level

Add a secret to the integrations table, e.g. googlereader_salt. From there, generate the HMAC on the subscription list request with the secret and the Icon ID:

ALTER TABLE integrations ADD COLUMN googlereader_salt text ...;

On result, check googlereader_salt + iconID pairs until there's a match. Read that match from the icons table and serve the binary result.

The upside is that this would only add a single row to the database, and only populate it if the Google Reader integration is enabled. The downside is that it's relatively resource intensive: several SQL queries, and re-computation of HMACs on each request.

Option 2: Icon level

With this option, the secret isn't added as an HMAC, it's generated alongside each icon either as a random string or something like a UUIDv4. The generated URL will use the unique, random alphanumeric value in the same way that the "share article":

ALTER TABLE icons ADD COLUMN share_code text ...;

The subscription list will use /icon/{shareCode} and on result the share code will make a simple lookup on the icon table based on the shareCode value.

The upside with this approach is that it's much lighter. No extra hashing involved. The downside is that it shifts the complexity from computation to database storage.

All things equal, option 2 would be my approach to avoid hashing and heavy SQL queries.