ep_openid_connect 3.0.21 → 3.0.23

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -33,7 +33,7 @@ jobs:
33
33
  - uses: pnpm/action-setup@v6
34
34
  name: Install pnpm
35
35
  with:
36
- version: 10
36
+ package_json_file: ./etherpad-lite/package.json
37
37
  run_install: false
38
38
  - name: Get pnpm store directory
39
39
  shell: bash
@@ -23,7 +23,7 @@ jobs:
23
23
  - uses: pnpm/action-setup@v6
24
24
  name: Install pnpm
25
25
  with:
26
- version: 10
26
+ package_json_file: ./etherpad-lite/package.json
27
27
  run_install: false
28
28
  - name: Get pnpm store directory
29
29
  shell: bash
@@ -34,7 +34,6 @@ jobs:
34
34
  - uses: pnpm/action-setup@v6
35
35
  name: Install pnpm
36
36
  with:
37
- version: 10
38
37
  run_install: false
39
38
  - name: Get pnpm store directory
40
39
  shell: bash
package/CONTRIBUTING.md CHANGED
@@ -1,133 +1,74 @@
1
- # Contributor Guidelines
2
- (Please talk to people on the mailing list before you change this page, see our section on [how to get in touch](https://github.com/ether/etherpad-lite#get-in-touch))
3
-
4
- ## Pull requests
5
-
6
- * the commit series in the PR should be _linear_ (it **should not contain merge commits**). This is necessary because we want to be able to [bisect](https://en.wikipedia.org/wiki/Bisection_(software_engineering)) bugs easily. Rewrite history/perform a rebase if necessary
7
- * PRs should be issued against the **develop** branch: we never pull directly into **master**
8
- * PRs **should not have conflicts** with develop. If there are, please resolve them rebasing and force-pushing
9
- * when preparing your PR, please make sure that you have included the relevant **changes to the documentation** (preferably with usage examples)
10
- * contain meaningful and detailed **commit messages** in the form:
11
- ```
12
- submodule: description
13
-
14
- longer description of the change you have made, eventually mentioning the
15
- number of the issue that is being fixed, in the form: Fixes #someIssueNumber
16
- ```
17
- * if the PR is a **bug fix**:
18
- * the first commit in the series must be a test that shows the failure
19
- * subsequent commits will fix the bug and make the test pass
20
- * the final commit message should include the text `Fixes: #xxx` to link it to its bug report
21
- * think about stability: code has to be backwards compatible as much as possible. Always **assume your code will be run with an older version of the DB/config file**
22
- * if you want to remove a feature, **deprecate it instead**:
23
- * write an issue with your deprecation plan
24
- * output a `WARN` in the log informing that the feature is going to be removed
25
- * remove the feature in the next version
26
- * if you want to add a new feature, put it under a **feature flag**:
27
- * once the new feature has reached a minimal level of stability, do a PR for it, so it can be integrated early
28
- * expose a mechanism for enabling/disabling the feature
29
- * the new feature should be **disabled** by default. With the feature disabled, the code path should be exactly the same as before your contribution. This is a __necessary condition__ for early integration
30
- * think of the PR not as something that __you wrote__, but as something that __someone else is going to read__. The commit series in the PR should tell a novice developer the story of your thoughts when developing it
31
-
32
- ## How to write a bug report
33
-
34
- * Please be polite, we all are humans and problems can occur.
35
- * Please add as much information as possible, for example
36
- * client os(s) and version(s)
37
- * browser(s) and version(s), is the problem reproducible on different clients
38
- * special environments like firewalls or antivirus
39
- * host os and version
40
- * npm and nodejs version
41
- * Logfiles if available
42
- * steps to reproduce
43
- * what you expected to happen
44
- * what actually happened
45
- * Please format logfiles and code examples with markdown see github Markdown help below the issue textarea for more information.
46
-
47
- If you send logfiles, please set the loglevel switch DEBUG in your settings.json file:
1
+ # Contributing to ep_openid_connect
48
2
 
3
+ Thanks for helping improve `ep_openid_connect` — a plugin for [Etherpad](https://etherpad.org/). LLM/Agent contributions are explicitly welcome, provided they follow the rules below.
4
+
5
+ For shared rules that apply to all Etherpad code (linear commits, deprecation policy, feature flags, stability guarantees), please read [ether/etherpad's CONTRIBUTING.md](https://github.com/ether/etherpad/blob/develop/CONTRIBUTING.md). This document only covers what's specific to plugin work.
6
+
7
+ ## Plugin-specific rules
8
+
9
+ * **Target branch:** PRs go to `main` on this repo. Plugin repos do not use git-flow's `develop` branch.
10
+ * **Linear commits, no merge commits.** Rebase if needed.
11
+ * **Every bug fix must include a regression test in the same commit.**
12
+ * **Internationalization (i18n):** every user-facing string lives in `locales/<lang>.json` and is referenced via `data-l10n-id` in templates or `html10n.get(key)` in code. No hardcoded English in markup.
13
+ * **Accessibility (a11y):** no nested interactive elements (no `<button>` inside `<a>`); every interactive control has an accessible name; keyboard focus order matches visual order. Note that on icon-only controls you should rely on Etherpad's html10n to populate `aria-label` from the `data-l10n-id` translation — adding a hardcoded English `aria-label` blocks that and leaves the control untranslated.
14
+
15
+ ## Local development
16
+
17
+ `ep_openid_connect` is a plugin, so you develop it inside a checkout of [ether/etherpad](https://github.com/ether/etherpad).
18
+
19
+ ```bash
20
+ # Once: clone etherpad alongside this repo
21
+ git clone https://github.com/ether/etherpad.git
22
+ cd etherpad
23
+ pnpm install
24
+
25
+ # Install ep_openid_connect from your local clone
26
+ pnpm run plugins i --path ../ep_openid_connect
27
+
28
+ # Start the dev server (port 9001)
29
+ pnpm --filter ep_etherpad-lite run dev
49
30
  ```
50
- /* The log level we are using, can be: DEBUG, INFO, WARN, ERROR */
51
- "loglevel": "DEBUG",
31
+
32
+ Edits in `../ep_openid_connect/` are picked up after a server restart.
33
+
34
+ ## Tests
35
+
36
+ Tests live inside this repo and are executed by Etherpad's test harness:
37
+
38
+ * Backend (Mocha): `static/tests/backend/specs/`
39
+ * Playwright (frontend E2E): `static/tests/frontend-new/specs/`
40
+
41
+ Run them from the etherpad checkout:
42
+
43
+ ```bash
44
+ # Backend (no separate server needed, harness boots one)
45
+ pnpm --filter ep_etherpad-lite run test
46
+
47
+ # Playwright (requires `pnpm run dev` in another terminal)
48
+ pnpm --filter ep_etherpad-lite run test-ui
52
49
  ```
53
50
 
54
- The logfile location is defined in startup script or the log is directly shown in the commandline after you have started etherpad.
55
-
56
- ## General goals of Etherpad
57
- To make sure everybody is going in the same direction:
58
- * easy to install for admins and easy to use for people
59
- * easy to integrate into other apps, but also usable as standalone
60
- * lightweight and scalable
61
- * extensible, as much functionality should be extendable with plugins so changes don't have to be done in core.
62
- Also, keep it maintainable. We don't wanna end up as the monster Etherpad was!
63
-
64
- ## How to work with git?
65
- * Don't work in your master branch.
66
- * Make a new branch for every feature you're working on. (This ensures that you can work you can do lots of small, independent pull requests instead of one big one with complete different features)
67
- * Don't use the online edit function of github (this only creates ugly and not working commits!)
68
- * Try to make clean commits that are easy readable (including descriptive commit messages!)
69
- * Test before you push. Sounds easy, it isn't!
70
- * Don't check in stuff that gets generated during build or runtime
71
- * Make small pull requests that are easy to review but make sure they do add value by themselves / individually
51
+ Lint locally before pushing:
52
+
53
+ ```bash
54
+ pnpm run lint
55
+ ```
72
56
 
73
57
  ## Coding style
74
- * Do write comments. (You don't have to comment every line, but if you come up with something that's a bit complex/weird, just leave a comment. Bear in mind that you will probably leave the project at some point and that other people will read your code. Undocumented huge amounts of code are worthless!)
75
- * Never ever use tabs
76
- * Indentation: JS/CSS: 2 spaces; HTML: 4 spaces
77
- * Don't overengineer. Don't try to solve any possible problem in one step, but try to solve problems as easy as possible and improve the solution over time!
78
- * Do generalize sooner or later! (if an old solution, quickly hacked together, poses more problems than it solves today, refactor it!)
79
- * Keep it compatible. Do not introduce changes to the public API, db schema or configurations too lightly. Don't make incompatible changes without good reasons!
80
- * If you do make changes, document them! (see below)
81
- * Use protocol independent urls "//"
82
-
83
- ## Branching model / git workflow
84
- see git flow http://nvie.com/posts/a-successful-git-branching-model/
85
-
86
- ### `master` branch
87
- * the stable
88
- * This is the branch everyone should use for production stuff
89
-
90
- ### `develop`branch
91
- * everything that is READY to go into master at some point in time
92
- * This stuff is tested and ready to go out
93
-
94
- ### release branches
95
- * stuff that should go into master very soon
96
- * only bugfixes go into these (see http://nvie.com/posts/a-successful-git-branching-model/ for why)
97
- * we should not be blocking new features to develop, just because we feel that we should be releasing it to master soon. This is the situation that release branches solve/handle.
98
-
99
- ### hotfix branches
100
- * fixes for bugs in master
101
-
102
- ### feature branches (in your own repos)
103
- * these are the branches where you develop your features in
104
- * If it's ready to go out, it will be merged into develop
105
-
106
- Over the time we pull features from feature branches into the develop branch. Every month we pull from develop into master. Bugs in master get fixed in hotfix branches. These branches will get merged into master AND develop. There should never be commits in master that aren't in develop
107
-
108
- ## Documentation
109
- The docs are in the `doc/` folder in the git repository, so people can easily find the suitable docs for the current git revision.
110
-
111
- Documentation should be kept up-to-date. This means, whenever you add a new API method, add a new hook or change the database model, pack the relevant changes to the docs in the same pull request.
112
-
113
- You can build the docs e.g. produce html, using `make docs`. At some point in the future we will provide an online documentation. The current documentation in the github wiki should always reflect the state of `master` (!), since there are no docs in master, yet.
114
-
115
- ## Testing
116
- Front-end tests are found in the `tests/frontend/` folder in the repository. Run them by pointing your browser to `<yourdomainhere>/tests/frontend`.
117
-
118
- Back-end tests can be run from the `src` directory, via `npm test`.
119
-
120
- ## Things you can help with
121
- Etherpad is much more than software. So if you aren't a developer then worry not, there is still a LOT you can do! A big part of what we do is community engagement. You can help in the following ways
122
- * Triage bugs (applying labels) and confirming their existence
123
- * Testing fixes (simply applying them and seeing if it fixes your issue or not) - Some git experience required
124
- * Notifying large site admins of new releases
125
- * Writing Changelogs for releases
126
- * Creating Windows packages
127
- * Creating releases
128
- * Bumping dependencies periodically and checking they don't break anything
129
- * Write proposals for grants
130
- * Co-Author and Publish CVEs
131
- * Work with SFC to maintain legal side of project
132
- * Maintain TODO page - https://github.com/ether/etherpad-lite/wiki/TODO#IMPORTANT_TODOS
133
58
 
59
+ * JS/CSS/HTML: 2 spaces, no tabs.
60
+ * `pnpm run lint` must pass (configured via `eslint-config-etherpad`).
61
+ * Avoid breaking changes to public hooks, the line-attribute storage shape, or HTML export output. The backend export spec enforces a stable shape.
62
+
63
+ ## Bug reports
64
+
65
+ Please include:
66
+
67
+ * Etherpad version, ep_openid_connect version, browser + OS
68
+ * Steps to reproduce
69
+ * What you expected, what actually happened
70
+ * Server log excerpt (set `"loglevel": "DEBUG"` in `settings.json` for verbose output)
71
+
72
+ ## AI agents
73
+
74
+ If you are an LLM/agent contributor, also read [`AGENTS.md`](AGENTS.md) — it documents the file layout, helper usage, and standing rules for autonomous edits.
package/index.js CHANGED
@@ -2,7 +2,6 @@
2
2
 
3
3
  const Ajv = require('ajv/dist/jtd');
4
4
  const {URL} = require('url');
5
- const {Issuer, generators} = require('openid-client');
6
5
 
7
6
  let logger = {};
8
7
  for (const level of ['debug', 'info', 'warn', 'error']) {
@@ -14,7 +13,14 @@ const defaultSettings = {
14
13
  user_properties: {},
15
14
  };
16
15
  let settings;
17
- let oidcClient = null;
16
+ let oidcConfig = null;
17
+ // openid-client@6 is ESM-only, so it must be loaded with a dynamic import from
18
+ // this CommonJS module. The reference is cached after the first call.
19
+ let oidc = null;
20
+ const loadOidc = async () => {
21
+ if (oidc == null) oidc = await import('openid-client');
22
+ return oidc;
23
+ };
18
24
 
19
25
  const validSettings = new Ajv().compile({
20
26
  properties: {
@@ -53,23 +59,35 @@ const validateSubClaim = (sub) => {
53
59
  }
54
60
  };
55
61
 
56
- const discoverIssuer = async (issuerUrl) => {
57
- issuerUrl = new URL(issuerUrl);
62
+ const isHttp = (urlString) => {
63
+ try {
64
+ return new URL(urlString).protocol === 'http:';
65
+ } catch (e) {
66
+ return false;
67
+ }
68
+ };
69
+
70
+ const discoverConfig = async (issuerUrl, clientId, clientAuth) => {
71
+ const url = new URL(issuerUrl);
58
72
  // https://openid.net/specs/openid-connect-discovery-1_0.html#IssuerDiscovery says that the URI
59
73
  // must not have query or fragment components.
60
- if (issuerUrl.search) {
61
- throw new Error(`Unexpected query in issuer URL (${issuerUrl}): ${issuerUrl.search}`);
74
+ if (url.search) {
75
+ throw new Error(`Unexpected query in issuer URL (${url}): ${url.search}`);
62
76
  }
63
- if (issuerUrl.hash) {
64
- throw new Error(`Unexpected fragment in issuer URL (${issuerUrl}): ${issuerUrl.hash}`);
77
+ if (url.hash) {
78
+ throw new Error(`Unexpected fragment in issuer URL (${url}): ${url.hash}`);
65
79
  }
66
- let issuer;
80
+ // openid-client@6 rejects http:// issuers by default; opt back in for
81
+ // localhost / private-network providers (matches v5 behaviour).
82
+ const options = url.protocol === 'http:'
83
+ ? {execute: [oidc.allowInsecureRequests]}
84
+ : undefined;
67
85
  try {
68
- issuer = await Issuer.discover(issuerUrl.href);
86
+ return await oidc.discovery(url, clientId, undefined, clientAuth, options);
69
87
  } catch (err) {
70
88
  // The URL used to get the issuer metadata doesn't exactly follow RFC 8615; see:
71
89
  // https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderConfig
72
- const discoveryUrl = new URL(issuerUrl);
90
+ const discoveryUrl = new URL(url);
73
91
  if (!discoveryUrl.pathname.includes('/.well-known/')) {
74
92
  discoveryUrl.pathname =
75
93
  `${discoveryUrl.pathname.replace(/\/$/, '')}/.well-known/openid-configuration`;
@@ -80,22 +98,36 @@ const discoverIssuer = async (issuerUrl) => {
80
98
  `Does your issuer support Discovery? (hint: ${discoveryUrl})`);
81
99
  throw err;
82
100
  }
83
- logger.info('OpenID Connect Discovery complete.');
84
- return issuer;
85
101
  };
86
102
 
87
- const getIssuer = async (settings) => {
88
- if (settings.issuer) return await discoverIssuer(settings.issuer);
89
- return new Issuer(settings.issuer_metadata);
103
+ const buildConfig = async (settings) => {
104
+ // openid-client@5 defaulted the token endpoint auth method to
105
+ // `client_secret_basic`; v6 defaults to `client_secret_post`. Pin the
106
+ // method explicitly so existing IdP registrations keep working.
107
+ const clientAuth = oidc.ClientSecretBasic(settings.client_secret);
108
+ if (settings.issuer) {
109
+ const config =
110
+ await discoverConfig(settings.issuer, settings.client_id, clientAuth);
111
+ logger.info('OpenID Connect Discovery complete.');
112
+ return config;
113
+ }
114
+ const config =
115
+ new oidc.Configuration(settings.issuer_metadata, settings.client_id, undefined, clientAuth);
116
+ if (isHttp(settings.issuer_metadata && settings.issuer_metadata.issuer)) {
117
+ oidc.allowInsecureRequests(config);
118
+ }
119
+ return config;
90
120
  };
91
121
 
92
122
  exports.init_ep_openid_connect = async (hookName, {logger: l}) => {
93
123
  if (l != null) logger = l;
124
+ await loadOidc();
94
125
  };
95
126
 
96
127
  exports.loadSettings = async (hookName, {settings: {ep_openid_connect: s = {}}}) => {
97
- oidcClient = null;
128
+ oidcConfig = null;
98
129
  settings = null;
130
+ await loadOidc();
99
131
  if (!validSettings(s)) {
100
132
  logger.error('Invalid settings. Detailed validation errors:', validSettings.errors);
101
133
  return;
@@ -121,12 +153,7 @@ exports.loadSettings = async (hookName, {settings: {ep_openid_connect: s = {}}})
121
153
  // Make sure base_url ends with '/' so that relative URLs are appended:
122
154
  if (!settings.base_url.endsWith('/')) settings.base_url += '/';
123
155
  logger.debug('Settings:', {...settings, client_secret: '********'});
124
- oidcClient = new (await getIssuer(settings)).Client({
125
- client_id: settings.client_id,
126
- client_secret: settings.client_secret,
127
- response_types: ['code'],
128
- redirect_uris: [endpointUrl('callback')],
129
- });
156
+ oidcConfig = await buildConfig(settings);
130
157
  logger.info('Configured.');
131
158
  };
132
159
 
@@ -137,16 +164,22 @@ exports.expressCreateServer = (hookName, {app}) => {
137
164
  // otherwise the user could be caught in an infinite redirect loop.
138
165
  try {
139
166
  logger.debug(`Processing ${req.url}`);
140
- if (oidcClient == null) {
167
+ if (oidcConfig == null) {
141
168
  logger.warn('Not configured; ignoring request.');
142
169
  return next();
143
170
  }
144
- const params = oidcClient.callbackParams(req);
145
171
  const oidcSession = req.session.ep_openid_connect || {};
146
172
  if (oidcSession.callbackChecks == null) throw new Error('missing authentication checks');
147
- const tokenset =
148
- await oidcClient.callback(endpointUrl('callback'), params, oidcSession.callbackChecks);
149
- const userinfo = await oidcClient.userinfo(tokenset);
173
+ const currentUrl = new URL(req.originalUrl || req.url, settings.base_url);
174
+ const tokens = await oidc.authorizationCodeGrant(oidcConfig, currentUrl, {
175
+ expectedNonce: oidcSession.callbackChecks.nonce,
176
+ expectedState: oidcSession.callbackChecks.state,
177
+ pkceCodeVerifier: oidcSession.callbackChecks.code_verifier,
178
+ idTokenExpected: true,
179
+ });
180
+ const claims = tokens.claims();
181
+ const userinfo =
182
+ await oidc.fetchUserInfo(oidcConfig, tokens.access_token, claims && claims.sub);
150
183
  validateSubClaim(userinfo.sub);
151
184
  // The user has successfully authenticated, but don't set req.session.user here -- do it in
152
185
  // the authenticate hook so that Etherpad can log the authentication success. However, DO "log
@@ -165,33 +198,36 @@ exports.expressCreateServer = (hookName, {app}) => {
165
198
  return next(err);
166
199
  }
167
200
  });
168
- app.get(ep('login'), (req, res, next) => {
169
- logger.debug(`Processing ${req.url}`);
170
- if (oidcClient == null) {
171
- logger.warn('Not configured; ignoring request.');
172
- return next();
201
+ app.get(ep('login'), async (req, res, next) => {
202
+ try {
203
+ logger.debug(`Processing ${req.url}`);
204
+ if (oidcConfig == null) {
205
+ logger.warn('Not configured; ignoring request.');
206
+ return next();
207
+ }
208
+ if (req.session.ep_openid_connect == null) req.session.ep_openid_connect = {};
209
+ const oidcSession = req.session.ep_openid_connect;
210
+ const code_verifier = oidc.randomPKCECodeVerifier(); // RFC7636
211
+ const code_challenge = await oidc.calculatePKCECodeChallenge(code_verifier);
212
+ const nonce = oidc.randomNonce();
213
+ const state = oidc.randomState();
214
+ oidcSession.callbackChecks = {nonce, state, code_verifier};
215
+ const url = oidc.buildAuthorizationUrl(oidcConfig, {
216
+ redirect_uri: endpointUrl('callback'),
217
+ scope: settings.scope.join(' '),
218
+ nonce,
219
+ state,
220
+ code_challenge,
221
+ code_challenge_method: 'S256',
222
+ });
223
+ res.redirect(303, url.toString());
224
+ } catch (err) {
225
+ return next(err);
173
226
  }
174
- if (req.session.ep_openid_connect == null) req.session.ep_openid_connect = {};
175
- const oidcSession = req.session.ep_openid_connect;
176
- const commonParams = {
177
- nonce: generators.nonce(),
178
- scope: settings.scope.join(' '),
179
- state: generators.state(),
180
- };
181
- oidcSession.callbackChecks = {
182
- ...commonParams,
183
- code_verifier: generators.codeVerifier(), // RFC7636
184
- };
185
- res.redirect(303, oidcClient.authorizationUrl({
186
- ...commonParams,
187
- // RFC7636
188
- code_challenge: generators.codeChallenge(oidcSession.callbackChecks.code_verifier),
189
- code_challenge_method: 'S256',
190
- }));
191
227
  });
192
228
  app.get(ep('logout'), (req, res, next) => {
193
229
  logger.debug(`Processing ${req.url}`);
194
- if (oidcClient == null) {
230
+ if (oidcConfig == null) {
195
231
  logger.warn('Not configured; ignoring request.');
196
232
  return next();
197
233
  }
@@ -200,7 +236,7 @@ exports.expressCreateServer = (hookName, {app}) => {
200
236
  };
201
237
 
202
238
  exports.authenticate = (hookName, {req, res, users}) => {
203
- if (oidcClient == null) return;
239
+ if (oidcConfig == null) return;
204
240
  logger.debug('authenticate hook for', req.url);
205
241
  const {ep_openid_connect: {userinfo} = {}} = req.session;
206
242
  if (userinfo == null) { // Nullish means the user isn't authenticated.
@@ -228,7 +264,7 @@ exports.authenticate = (hookName, {req, res, users}) => {
228
264
  };
229
265
 
230
266
  exports.authnFailure = (hookName, {req, res}) => {
231
- if (oidcClient == null) return;
267
+ if (oidcConfig == null) return;
232
268
  // Normally the user is redirected to the login page which would then redirect the user back once
233
269
  // authenticated. For non-GET requests, send a 401 instead because users can't be redirected back.
234
270
  // Also send a 401 if an Authorization header is present to facilitate API error handling.
@@ -268,7 +304,7 @@ exports.authnFailure = (hookName, {req, res}) => {
268
304
  };
269
305
 
270
306
  exports.preAuthorize = (hookName, {req}) => {
271
- if (oidcClient == null) return;
307
+ if (oidcConfig == null) return;
272
308
  if (req.path.startsWith(ep(''))) return true;
273
309
  return;
274
310
  };
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "ep_openid_connect",
3
- "version": "3.0.21",
3
+ "version": "3.0.23",
4
4
  "description": "Etherpad plugin to authenticate users against an OpenID Connect provider.",
5
5
  "main": "index.js",
6
6
  "repository": {
@@ -24,7 +24,7 @@
24
24
  "homepage": "https://github.com/ether/ep_openid_connect#readme",
25
25
  "dependencies": {
26
26
  "ajv": "^8.20.0",
27
- "openid-client": "^5.7.1"
27
+ "openid-client": "^6.8.4"
28
28
  },
29
29
  "devDependencies": {
30
30
  "eslint": "^8.57.1",