It may not be desirable to host all plugins on npm, allow for local packages to
be installed given a package name with a `file:` prefix.
This is still more restrictive than what yarn would support but allows us to still
verify the thelounge compatibility by reading the package.json file.
`yarn add` messes up with local filepaths and generates a lockfile that is
"outdated" as far as any other yarn commands go, which makes them error out.
For some reason `yarn install` fixes that and hence we run that after an install.
Here's the diff of yarn.lock between the broken state after `yarn add file:$path`
and `yarn install`
--- yarn.lock.2.afterAdd 2021-06-02 00:10:52.365134018 +0200
+++ yarn.lock.3.afterinstall 2021-06-02 00:13:27.122760442 +0200
@@ -2194,7 +2194,7 @@
safe-buffer "^5.1.2"
yallist "^3.0.3"
-thelounge-plugin-shortcuts@/home/reto/sourcecode/thelounge-plugin-shortcuts:
+"thelounge-plugin-shortcuts@file:../../sourcecode/thelounge-plugin-shortcuts":
version "1.0.12"
dependencies:
thelounge "4.2.0"
The only thing it does is switch an absolute path to a relative one for whatever
reason.
Tested on latest Chromium / Firefox. In case of .m4a files they want audio/x-m4a and not audio/m4a, in case of .flac files they want audio/flac and not audio/x-flac. The module we useed to detect the types however detects them only as audio/x-m4a and audio/x-flac as they are not offical IANA supported mime types (not in IANA spec == "x-" prefix): https://www.iana.org/assignments/media-types/media-types.xhtml Though flac is not in the IANA spec many programs such as the file command (https://man7.org/linux/man-pages/man1/file.1.html) and Chromium (flac) / Firefox (x-flac and flac) support audio/flac only or both.
We need to remove the metadata without breaking the animation.
For that we use sharp which incooperates libvips (binaries for most common distros included).
This also decreases client side upload complexity as we remove the metadata on the serverside.
Sharp: https://sharp.pixelplumbing.com/
libvips: https://libvips.github.io/libvips/
If we have no message provider:
- Search input field not renderd
- Search endpoint retuns empty resultset
Also removed redundancy by setting a main message provider.
By default we take the slug given in the request, if this is not set we try to give a filename from known types.
If we still have no filename we fallback to the previous method of setting no filename.
If the filename is non ascii we will only create the encoded "filename*" and not the ascii only "filename". This is to prevent other applications to save a file like "?????.png" if the filename contains non ascii chars.
For the browsers nothing will really change comapred to the behaviour before this change as good fallbacks if no content-disposition filename is set. But that is not the case for all application, thus it makes sense to include the proper way to set the filename.
The default socket.io server-side ping timeout was changed from 60 seconds to 5 seconds. In browsers based on Chrome, this is not enough time to respond when the browser is idle. The end result is that the server sets the user away and then back approximately once every minute if the client window is idle, which is undesirable.
This change restores the previous timeout value.
See https://github.com/socketio/socket.io/issues/3259#issuecomment-474523271.
YouTube puts the opengraph tags needed for the preview after ~300KB in the body
instead of the beginning of the <head> tag.
Instead of hardcoding the value, allow the server admin to set the policy as
they prefer.
Users are loaded at startup. Currently when using "advanced" LDAP
authentication this is true even if they no longer have a
valid entry in the LDAP server.
This commit uses the existing LDAP filter (specified in config.js's searchDN
used by the "advanced" LDAP mechanism) to weed out any users that no
longer have the relevant LDAP entry.
Local and "simple" LDAP auth mechanisms continue to use the existing
load all users approach. In the "simple" LDAP case this is because we
only have access to the hashed password, and so can't bind to LDAP.
The caller doesn't care which plugin is being used, so this commit
consolidates implementation details within auth.js
The motivation for this work is to prepare for extending the auth API
(to allow "advanced" LDAP to query user entry ontological state at start
up), by tidying up rather than duplicating the existing mechanism.
