Feed of "Readeck"

hickey commented on pull request readeck/readeck#1182

2026-04-12T21:57:51+02:00

WIP: Add OIDC authentication to Readeck

Sorry, maybe standard was the wrong word to use. I was not using standard in a sense that go-oidc is part of the core Go lang modules or an x module. I was referring to that go-oidc would be the go-to module for implementing an OIDC client. I know that there are a few others like Goth which was interesting as it "supported" a lot of OIDC endpoints. Probably just has pre-configured settings for most of the endpoints, but I was not sure it would actually add any real value.

I do agree that OIDC is not a terribly complicated standard, but with any standard there are always little gotchas that are not apparent. I too am not a security expert and don't want to put something out there that people think is a secure piece of code and have it compromised because of something I never thought would be a problem.

hickey commented on pull request readeck/readeck#1182

2026-04-12T18:20:29+02:00

WIP: Add OIDC authentication to Readeck

If I understand what you are saying here (that you want to eliminate the go-oidc module and reimplement the module in native Go code) then I have to say that is a non-start for me. I am not looking to build another go-oidc module that probably will have errors in it and miss edge cases. The go-oidc module takes into account the differences between v1 and v2 of the OIDC specification. I am sure that there are other things done in the module that may accommodate specific OIDC servers or servers that are not (pre-v1) fully v1 compliant (but hopefully they are not in use any more).

Writing security code is not really a trivial matter as you probably already know and making a requirement that the standard OIDC module can not be used in favor of reimplementing it is just lunacy to me. But if that is your intent, then we can go ahead and close this PR and I will keep the branch for myself and merge it will future versions of Readeck for my use.

hickey commented on pull request readeck/readeck#1182

2026-04-12T18:06:05+02:00

WIP: Add OIDC authentication to Readeck

See below for why the state needs to be stored in the session to validate the origin of the authentication request and the access token will probably be used to renew the token when it expires. It may also be necessary to store the expiration time of the access token, but I have not determined that yet.

hickey commented on pull request readeck/readeck#1182

2026-04-12T18:03:16+02:00

WIP: Add OIDC authentication to Readeck

I am not sure I understand why you say that this is a non-starter. The HTTP request is not calling to the Readeck instance itself but to the OIDC authentication server to retrieve the configuration for the OIDC application settings.

This will probably be pulled out anyways as it appears that when the NewProvisioner() function in the go-oidc module retrieves the JSON document stored on the authentication server to configure the client.

hickey commented on pull request readeck/readeck#1182

2026-04-12T17:56:56+02:00

WIP: Add OIDC authentication to Readeck

One of my first comments described the flow from the user's standpoint which is pretty simple as far as the user interface. For the backend flow it is a bit more in depth and I will to my best to describe it as I understand it.

Once the OIDC authentication flow is initiated by the user pressing the OIDC login button, a random string is generated and sent to the OIDC authentication server. This is usually referred to as the state in the OIDC flow and is really used to validate that the authentication request was initiated from the application is really just a CSRF token. The application upon receiving a login request, will perform an HTTP redirect (GET) to the authentication server with a state, client_id, scope, response_type and request_uri parameters.

The client_id is generated on the authentication server to identify which application is requesting authentication. This is a static token that is stored in the application's configuration. The scope tells the authentication server what claims are requested by the application in the authentication response. This is commonly set to 'openid profile email'. openid is require and the profile requests items such as username and UID and of course email requests the user's email address. response_type is set to 'code' to (I believe) request an access token in the response. Finally the redirect_uri is the URL that the authentication server needs to send the response.

The user will then authenticate to the OIDC authentication server if necessary and the authentication server will return to the application using the redirect_uri which will be called with the state and code parameters. Again the state is used to validate that the request originated from the application so the returned state value needs to be compared to the stored state value when the authentication request was initiated. The code (which depending upon the OIDC implementation could be a string or a JWT) is then exchanged for the access and ID tokens. This is done by calling the OIDC token endpoint with the code value. The response will be a JSON document that contains these tokens and a few other items such as expiration time for the tokens.

The ID token is used to authenticate the user and should be used to validate the user. The access token is used for authorization and provides information as to what the user has access to. In my case I am using Authentik and both the ID and access tokens are very similar, but that may be because I don't have a lot of settings in Authentik that would provide different authorizations.

The payload for the ID token asserts the following claims:

{
  "iss": "https://auth.wt0f.com/application/o/readeck/",
  "sub": "hickey",
  "aud": "H9uYxz2H6czUt08O0gZroxIAAUYj5hy0lgaM2IRg",
  "exp": 1775680621,
  "iat": 1775680321,
  "auth_time": 1775666408,
  "acr": "goauthentik.io/providers/oauth2/default",
  "amr": [
    "pwd"
  ],
  "sid": "d582cf9de4038d38e8dd095b1d892b83efa6fab7ced7b9e004f58b5d1ffbc6c3",
  "jti": "FFG2mtCp0Py1wVdKT8SUIt294yqZ9jAzePXEYkOK",
  "email": "hickey@kinetic-compute.com",
  "email_verified": false,
  "name": "Gerard Hickey",
  "given_name": "Gerard Hickey",
  "preferred_username": "hickey",
  "nickname": "hickey",
  "groups": [
    "authentik Admins",
    "NextCloud Admins",
    "Grafana Admins",
    "Proxmox-Admins",
    "Authentik Admin Tools",
    "Authentik Backend Services"
  ]
}

The claims in the access token is as follows:

{
  "iss": "https://auth.wt0f.com/application/o/readeck/",
  "sub": "hickey",
  "aud": "H9uYxz2H6czUt08O0gZroxIAAUYj5hy0lgaM2IRg",
  "exp": 1775667590,
  "iat": 1775667290,
  "auth_time": 1775666408,
  "acr": "goauthentik.io/providers/oauth2/default",
  "amr": [
    "pwd"
  ],
  "sid": "d582cf9de4038d38e8dd095b1d892b83efa6fab7ced7b9e004f58b5d1ffbc6c3",
  "jti": "mGOpPVJBVBXyz5DTQvyEct54NOcHXX1OFyw398YR",
  "email": "hickey@kinetic-compute.com",
  "email_verified": false,
  "name": "Gerard Hickey",
  "given_name": "Gerard Hickey",
  "preferred_username": "hickey",
  "nickname": "hickey",
  "groups": [
    "authentik Admins",
    "NextCloud Admins",
    "Grafana Admins",
    "Proxmox-Admins",
    "Authentik Admin Tools",
    "Authentik Backend Services"
  ],
  "azp": "H9uYxz2H6czUt08O0gZroxIAAUYj5hy0lgaM2IRg",
  "uid": "bADM3vh0ws6dp2s5f8fb46fh8i2tawMGToExAL3T",
  "scope": "profile email openid"
}

As one can see, both of these tokens are very similar but they are representing different needs for the application. Both JWTs are signed by the private key of the authorization server and gets verified by retrieving the public key from the authorization server.

At this point the application can continue with the authenticated user as if the user had logged in with another method. At some point in the future the access token will expire and a new access token will need to be retrieved from the authorization server. This aspect I don't have as much visibility into yet. There are references to a refresh_token that is included in the response that provides the access and ID tokens, but I am not receiving this from my Authentik server. It could be that Authentik does not provide a refresh_token or it is a matter of the configuration I have in the Authentik for the application. I am not sure which. Once I have the user being created/loaded I will be able to experiment and learn what needs to be done to generate new access tokens.

ghost_of_cerberus commented on pull request readeck/readeck#1163

2026-04-12T13:59:18+02:00

Extend username charset to allow '.'

No worries, @olivier. The intended solution appears to be much more robust. Looking forward to testing it out. :)

Minoru commented on issue readeck/browser-extension#127

2026-04-12T12:32:52+02:00

Fails with "Could not establish connection. Receiving end does not exist"

Thanks for the detailed instructions! Apparently 30 seconds come from Firefox:

mislav commented on issue readeck/browser-extension#127

2026-04-11T18:39:42+02:00

Fails with "Could not establish connection. Receiving end does not exist"

@Minoru I can not find any specific client-side timeout for the browser extension POSTing the page payload to the Readeck API:

 /**
  * savePage sends the page to Readeck.
  *
  * @async
  * @param {import("../content-script/content-script").PageObj} page Page object
  * @returns {Promise<import("../background").ApiResult>} A promise of the API call result
  */
 export async function savePage(page) {
   return await browser.runtime.sendMessage({
     type: "save-page",
     serverURL: get(serverURL),
     path: "api/bookmarks",
     params: {
       method: "post",
       headers: {
         Accept: "application/json",
         Authorization: `Bearer ${get(token)}`,
       },
     },
     page,
   })
 }

async function readeckApiCall(url, params) {

Could you inspect your browser extension to see if it prints anything useful to the JS console when this error happens?

Open the Add-ons Manager by going to Tools → “Extensions and Themes”;
Cog icon → “Debug add-ons”;
“Inspect” the Readeck add-on;
While keeping that devtools window open, submit a page to Readeck again;
Check whether the JS console has something printed that might hint to the request being aborted client-side prior to nginx responding with HTTP 499.

Minoru commented on issue readeck/browser-extension#127

2026-04-11T18:12:50+02:00

Fails with "Could not establish connection. Receiving end does not exist"

It didn't change a thing.

mislav pushed to html-refresh-directive at readeck/readeck

2026-04-11T17:33:23+02:00

b167631d2ab897a0dc0b212aac78e8317b968e4d Simplify tinymeta

mislav created pull request readeck/readeck#1185

2026-04-11T15:39:20+02:00

Summary

This extends Drop.Load() with support for HTML Refresh directive specified either via HTTP response header or via <meta> tag.

Fixes #1179

TODO:

Is Drop.Load() the correct place to implement this?
Should we set the HTTP Referer header when following this type of redirect? (The spec suggests we should.)
Set maximum redirect limit to prevent infinite redirect loops
Clean up the extension of the tinymeta package

Did you write it yourself?

I didn't use any AI tool to produce this contribution.

Did you add tests?

I added tests to my contribution

Did you run the tests?

The tests finished successfully

mislav pushed to html-refresh-directive at readeck/readeck

2026-04-11T15:33:40+02:00

0b66aae149e10e8ad88de73b96948421da20f044 WIP support HTML Refresh header

mislav created branch html-refresh-directive in readeck/readeck

2026-04-11T15:33:40+02:00

fschoell commented on issue readeck/readeck-ios#15

2026-04-11T14:07:24+02:00

Long articles are 'choppy'

ok yes beta works fine

Minoru opened issue readeck/browser-extension#127

2026-04-11T12:41:54+02:00

I'm using Nginx as a reverse proxy for Readeck. Most pages are saved just fine, but occasionally I'll bump into one that fails like this:

Nginx logs show code 499:

X.X.X.X - - [11/Apr/2026:10:32:19 +0000] "POST /api/bookmarks HTTP/2.0" 499 0 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:140.0) Gecko/20100101 Firefox/140.0"

Readeck logs don't show anything for that request.

The page is https://blog.voron.me/r1bng_dxpedition?utm_source=teletype&utm_medium=feed_rss&utm_campaign=voronspb Previously it was failing to get saved because client_max_body_size in Nginx was set to 100M; I bumped that to 300M and now running into this error.

It might be some timeout. I didn't time it precisely, but it takes between 20 and 30 seconds between me clicking the "Save" button and this error appearing.

Extension version is 2.6.3, Firefox 140.9.1esr on Debian 13. As I said, I ran into this issue previously, including on my Android phone, so this isn't some new regression or anything like that.

fabiante commented on issue readeck/readeck#1152

2026-04-11T10:20:10+02:00

Custom favicon

I agree with you that even this seemingly small detail is already something that needs care long-term and will increase complexity. My initial response shows that pretty well.

fabiante commented on issue readeck/readeck#1152

2026-04-11T10:06:20+02:00

Custom favicon

I would like to implement this. I have already changed the favicons locally, but that's just playing around.

fabiante commented on issue readeck/readeck#399

2026-04-11T08:56:47+02:00

Set link expiration time

The current configuration option (public_share_ttl) allows to change the value of the shared link "globally".

monki pushed to main at readeck/readeck-ios

2026-04-10T23:44:17+02:00

35cda891b4f033dad0c384e3a68d08e11ead04c8 Merge pull request #42 from ilyas-hallak/bugfix/issue-27-settings-persistence ef54a492b4218c072e3ca387acffd33c16513a47 fix: adapt reader UI to color theme and add hide summary toggle 86c5ff87c662f4530210ca892ea1ba6e76eac66f fix: move CSS help sheet to top-level to prevent dismissing parent sheet 00c0f2090db624fd573460508d168833ec47ed53 fix: prevent settings from being reset on partial saves (#27) b22cb935479ab1b5070d05051fc5b96ebf14cbbb Merge pull request #41 from ilyas-hallak/feat/issue-40-article-summary

monki pushed to bugfix/issue-27-settings-persistence at readeck/readeck-ios

2026-04-10T23:35:45+02:00

ef54a492b4218c072e3ca387acffd33c16513a47 fix: adapt reader UI to color theme and add hide summary toggle

monki pushed to bugfix/issue-27-settings-persistence at readeck/readeck-ios

2026-04-10T23:05:53+02:00

86c5ff87c662f4530210ca892ea1ba6e76eac66f fix: move CSS help sheet to top-level to prevent dismissing parent sheet

monki pushed to bugfix/issue-27-settings-persistence at readeck/readeck-ios

2026-04-10T22:56:44+02:00

00c0f2090db624fd573460508d168833ec47ed53 fix: prevent settings from being reset on partial saves (#27) b22cb935479ab1b5070d05051fc5b96ebf14cbbb Merge pull request #41 from ilyas-hallak/feat/issue-40-article-summary c42177c85dedc7932547a84ab4f4648899c1c6e4 refactor: inject factory into ArticleSummaryViewModel with default .shared 92eea4d01309cc561ae095cc074cb8f259e7fc71 refactor: extract SummarizationRepository and HTMLStringUtils from UseCase 3cc3adce0ce02d4d4130e74d2605839336e57fe5 fix: make summary card header reliably tappable for collapse/expand

monki created branch bugfix/issue-27-settings-persistence in readeck/readeck-ios

2026-04-10T22:56:44+02:00

monki commented on issue readeck/readeck-ios#37

2026-04-10T15:57:03+02:00

Follow The Money articles content not visible when shared from Safari

It's possible with Readeck 0.22, and I will implement this in the next few weeks in the app. It’s one of the most wished features. :)

mislav commented on issue readeck/readeck#1181

2026-04-10T15:29:24+02:00

Browser Bookmarklet

Hi, thanks for the detailed feature request. Agreed that Readeck could in theory make the bookmarklet experience better; for example, take a look at the thoughts I shared on the same topic on our community forum: https://community.readeck.org/d/65-bookmarklet/5

However, since nearly every browser out there is able to install the Readeck browser extension, which offers a much better and complete experience of sending web pages to Readeck than a bookmarklet ever could, I'm wondering whether there is even a use-case for a bookmarklet over the browser extension? What do you think?

mislav commented on issue readeck/browser-extension#122

2026-04-10T15:14:47+02:00

Chrome sends AVIF images to Readeck

Thanks; confirmed that the latest browser extension fixes the issue for me in Chrome!

monki commented on issue readeck/readeck-ios#37

2026-04-10T08:13:32+02:00

Follow The Money articles content not visible when shared from Safari

Sounds good! :)

mislav created pull request readeck/browser-extension#126

2026-04-09T23:55:03+02:00

YouTube seems to have removed <meta name> and <meta property> tags
(at least for me) pertaining to the video being watched, with the only
remaining metadata being stored in JSON-LD with the type "VideoObject". This
wasn't among any of the allow-listed "article" types, so it was completely
ignored.

This adds VideoObject to known article types so that the bookmark form might
make use of video metadata.

mislav pushed to fix-youtube-titles at readeck/browser-extension

2026-04-09T23:54:58+02:00

c762ba668e58c3e127b57ba7d34ca6fdb269edfc Fix YouTube video title getting pre-populated when adding bookmark

mislav created branch fix-youtube-titles in readeck/browser-extension

2026-04-09T23:54:57+02:00