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.

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.

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.

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.

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

1. Open the Add-ons Manager by going to Tools → “Extensions and Themes”;
2. Cog icon → “Debug add-ons”;
3. “Inspect” the Readeck add-on;
4. While keeping that devtools window open, submit a page to Readeck again;
5. 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.

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

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.

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?

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