* lint: pluginfw tsort.js
* Don't comment out the `console.log()` call
Disabling the log message is out of scope for the pull request.
* Put const and let on separate lines
* Convert `tsort` from function to arrow function
ESLint doesn't complain about this due to a bug in
prefer-arrow/prefer-arrow-functions rule:
https://github.com/TristonJ/eslint-plugin-prefer-arrow/issues/24
Co-authored-by: Richard Hansen <rhansen@rhansen.org>
Rewrite the `callAll` and `aCallAll` functions to support all
reasonable hook behaviors and to report errors for unreasonable
behaviors (e.g., calling the callback twice).
Now a hook function like the following works as expected when invoked
by `aCallAll`:
```
exports.myHookFn = (hookName, context, cb) => {
cb('some value');
return;
};
```
The debug statement mostly printed the following useless message over
and over, causing Travis CI logs to become truncated:
[DEBUG] pluginfw - [ undefined ] returning
Before this change, the authorize hook was invoked twice: once before
authentication and again after (if settings.requireAuthorization is
true). Now pre-authentication authorization is instead handled by a
new preAuthorize hook, and the authorize hook is only invoked after
the user has authenticated.
Rationale: Without this change it is too easy to write an
authorization plugin that is too permissive. Specifically:
* If the plugin does not check the path for /admin then a non-admin
user might be able to access /admin pages.
* If the plugin assumes that the user has already been authenticated
by the time the authorize function is called then unauthenticated
users might be able to gain access to restricted resources.
This change also avoids calling the plugin's authorize function twice
per access, which makes it easier for plugin authors to write an
authorization plugin that is easy to understand.
This change may break existing authorization plugins: After this
change, the authorize hook will no longer be able to authorize
non-admin access to /admin pages. This is intentional. Access to admin
pages should instead be controlled via the `is_admin` user setting,
which can be set in the config file or by an authentication plugin.
Also:
* Add tests for the authenticate and authorize hooks.
* Disable the authentication failure delay when testing.
I plan on splitting authFailure into authnFailure and authzFailure so
that separate authentication and authentication plugins can coexist
peacefully. This change will make it possible to mark the authFailure
hook as deprecated (which simply logs a warning).
Plugin authors are allowed to omit the function name in the `ep.json`
parts definition. For example:
```
{
"parts": [
{
"name": "ep_example",
"hooks": {
"authenticate": "ep_example",
"authFailure": "ep_example"
}
}
]
}
```
If omitted, the function name is assumed to be the same as the hook
name. Before this change, `hook_fn_name` for the example hooks would
both be `/opt/etherpad-lite/node_modules/ep_example`. Now they are
suffixed with `:authenticate` and `:authFailure`. This improves
logging, and it makes it possible to use `hook_fn_name` to uniquely
identify a particular hook function.
Every existing caller of `aCallFirst` expects a list and will throw an
exception if given `undefined`. (Nobody calls `callFirst`, except
maybe plugins.)
This commit fixes the error of not waiting the async code to finish.
As the forEach did not wait until the async code finish we may get a
hook set up incorrectly. To fix it, we use an "Array.map" to iterate and
wait the promises to be resolved and then returned
Makes IE11 work again but may cause an issue for plugin testing in IE11. IE plugin tests in IE11 will probably fail as the plugin code will not execute.
With this change, it is no longer necessary to "cd" to the Etherpad base
directory to start it: Etherpad runs from everywhere.
Known issues:
- unless the program is started as before (CWD == base directory) it is still
not possible to install & uninstall plugins via the web interface
--HG--
branch : absolute-paths
Since this code can end up loaded in browsers when using client side plugins,
avoid use of ES6 syntax features such as arrow functions until MSIE support is
finally dropped.
This change is only cosmetic. Its aim is do make it easier to understand the
async changes that are going to be merged later on. It was extracted from the
original work from Ray Bellis.
To verify that nothing has changed, you can run the following command on each
file touched by this commit:
npm install uglify-es
diff --unified <(uglify-js --beautify bracketize <BEFORE.js>) <(uglify-js --beautify bracketize <AFTER.js>)
This is a complete script that does the same automatically (works from a
mercurial clone):
```bash
#!/usr/bin/env bash
set -eu
REVISION=<THIS_REVISION>
PARENT_REV=$(hg identify --rev "${REVISION}" --template '{p1rev}')
FILE_LIST=$(hg status --no-status --change ${REVISION})
UGLIFYJS="node_modules/uglify-es/bin/uglifyjs"
for FILE_NAME in ${FILE_LIST[@]}; do
echo "Checking ${FILE_NAME}"
diff --unified \
<("${UGLIFYJS}" --beautify bracketize <(hg cat --rev "${PARENT_REV}" "${FILE_NAME}")) \
<("${UGLIFYJS}" --beautify bracketize <(hg cat --rev "${REVISION}" "${FILE_NAME}"))
done
```
Moving classes to html tag so it can be used to style other part of template depending on plugins like #users, #chat etc...
Rename plugin class with "plugin-" prefix, because there were conflicts with some plugins using the same .ep_font_color class to apply css rules
Compatibility with IE11 regressed in 23eab79946 while working for #3488.
That commit made use of modern js syntax, not supported by IE11.
- Removed arrow functions, replaced with normal functions.
- Removed the spread operator (<...iterable>) and the "new Set()" construct,
replaced with _.uniq()
At some point IE11 compatibility will be dropped.
Ditching it now, for such a small gain, is not wise.
Fixes#3500.
This commit implements the following behaviour:
1. adds a function clientPluginNames() to hooks.js (mimicking what is done in
static.js), which returns an array containing the list of currently installed
client side plugins. The array is eventually empty.
2. calls that function in pad.html at rendering time (thus server-side) to
populate a class attribute.
Example results:
- with no client-side plugins installed:
<div id="editorcontainerbox" class="">
- with some client-side plugins installed:
<div id="editorcontainerbox" class="ep_author_neat ep_adminpads">
Looking at the existing code (src/node/hooks/express/static.js#L39-L57), a
client-side plugin is defined as a plugin that implements at least a client side
hook.
NOTE: there is currently no support for notifying plugin removal/installation
to the connected clients: for now, in order to get an updated class list,
the clients will have to refresh the page.
Fixes#3488
