Using the muc_room_default_persistent = true method I now have a different error: connection.GET_SESSION_ID_ERROR
I just closed the browser and joined in a private tab.
Folks, Iāve finally made it working by updating to the freshest version of Prosody
Prosody 0.11.5
# Lua environment
Lua version: Lua 5.2
LuaRocks: Not installed
# Network
Backend: select
# Lua module versions
DBI: 0.7
lfs: LuaFileSystem 1.6.3
lxp: LuaExpat 1.3.0
socket: LuaSocket 3.0-rc1
ssl: 0.6
1 Like
You can try to adjust the module posted above to fit your needs, that is do not allow to delete the password and donāt let rooms go stale (perhaps just remove the muc-room-destroyed hook.
Restart prosody to enable the module.
Now create a room, set a password and leave the room. Check that a plaintext file has been created in prosodyās data folder in a folder called <your-muc-component>/persistent_muc_passwords/<urlencoded_muc_name>.dat
Then also enable the prosody module described here: https://modules.prosody.im/mod_muc_config_restrict.html and add the muc#roomconfig_roomsecret option. Restart prosody again. For each room you want to setup, create a file similar to the file you checked in the last step. Make sure these are only readable by the prosody user.
This is still just a workaround, as anybody who joins a room first (i.e. the moderator) will see the Remove Password button. However, clicking this button shows an error message stating that passwords were not supported.
Hope this helps!
3 Likes
I am using docker as well and would to have this setup. Is it possible for you to layout in a more detailed guide? I am struggling on where the modules locations are and if we need to turn that on in the docker-compose.yml file (via .env).
I am using docker too in a test system.
If you do not change CONFIG in .env, file location in a standard configuration are
~/.jitsi-meet-cfg/prosody/conf.d/jitsi-meet.cfg.lua
~/.jitsi-meet-cfg/prosody-plugins-custom/mod_persist_muc_passwords.lua
In docker-compose.yml you have a add a line for a prosody module
prosody: image: jitsi/prosody expose: - '5222' - '5347' - '5280' volumes: - ${CONFIG}/prosody:/config - ${CONFIG}/prosody-plugins-custom:/prosody-plugins-custom
And you have to create the directory ~/.jitsi-meet-cfg/prosody-plugins-custom/
1 Like
Alternatively, if you donāt want to change the docker-compose.yml, just change the plugin_paths option in ~/.jitsi-meet-cfg/prosody/conf.d/jitsi-meet.cfg.lua to include "/config/prosody-plugins-custom". Then put the module in ~/.jitsi-meet-cfg/prosody/prosody-plugins-custom/mod_persist_muc_passwords.lua
1 Like
Thanks a lot for your script! I managed to install it and it works - half-way:
- It still asks for the operatorās password. Am I supposed to turn the
restrict_create_room(?) off again? - Itās still possible to delete the password.
Sorry if I misunderstood any of the above instructions. I came from a āquick installā and didnāt expect to deep dive into the system just to set up a password.
(edit: found some details I have to re-read)
To prevent the password from being deleted, you can enable the mod_muc_config_restrict.lua module mentioned above.
You are asked to provide the operatorās password because you setup a secure domain - if everybody should be able to create a room try to undo the respective configuration. Note that in this case whoever joins the room first will be the roomās moderator which is likely not what you want.
Thanks for everyone thatās helped as well, and I think it is working as intended.
- I have authentication turned on (internal)
- When I ācreateā a room and set the password, that password carries over from session to session (i.e. I close out the window completely and go back in), so that is working as intended
- However, because I have authentication on, when a room does not have a participant anymore (everyone left) and then join back in, it requires someone to authenticate first, and then the room password kicks in; is there a way to not have authentication on a room that had been created?
2 Likes
Iām stuck on the very same problem right now.
I wonder if it makes sense to remove the authentication and just use the roomās password. Using any unknown room would require a password nobody knows.
As soon as I figured out why my settings donāt apply, Iāll start tinkering with the script @plokta provided.
My concern is that I have this running on a public-facing VPS and I donāt want anyone and everyone to use up my bandwidth. With my scenario, ideally I would like to only let authenticated users create persistent rooms that require passwords.
That being said, I think @plokta solution is the best workaround. I have authentication so not everyone can just create a room, and passwords are persistent.
I have an almost working version for my needs (only pre-configured rooms with passwords - no accounts):
Iām not using any secure domain.
/etc/prosody/conf.d/domain.tld.cfg.lua
Component "conference.domain.tld" "muc"
modules_enabled = {
"muc_meeting_id";
"muc_domain_mapper";
"muc_config_restrict";
"persist_muc_passwords";
}
admins = { "focus@auth.domain.tld" }
default_storage = "memory";
storage = {
persistent_muc_passwds = "internal";
}
muc_config_restricted = {
"muc#roomconfig_roomsecret";
}
/usr/lib/prosody/modules/mod_persist_muc_passwords.lua (modified script of @plokta )
local store = module:open_store("persistent_muc_passwds", "map");
if not store then
module:log("error","Failed to open storage.");
return nil;
end
module:hook("muc-room-created", function (event)
local room = event.room;
module:log("debug","hooked room create for %s", room);
local old_pass = store:get(room.jid, "password");
if not old_pass then
-- default password for unknown rooms; not to be shared with anyone
old_pass = "some-admin-password" -- should be moved into some config file
module:log("debug", "No password to restore for room %s", room);
end
module:log("debug", "Loaded old password '%s' for room %s", old_pass, room);
-- restore old pass for the mucroom
local success = room:set_password(old_pass);
if not success then
module:log("warn", "Failed to set old password %s for restored room %s.", old_pass, room);
end
module:log("debug", "Set password '%s' for restored room %s.", old_pass, room);
return nil;
end, 0);
For each room: /var/lib/prosody/conference%2edomain%2etld/persistent_muc_passwds/name_of_the_room%40conference%2edomain%2etld.dat
return {
["password"] = "shared room password";
};
Current issues:
- Itās still possible to delete the password when entering the room. But that has only temporary effect. @plokta any idea why my configuration of
mod_muc_config_restrictdoesnāt work? Ismuc#roomconfig_roomsecretavailable on secured domains only?
4 Likes
My setup is somewhat different but I can confirm that mod_muc_config_restrict also works without secured domain: The Remove Password button is visible but an error message pops up when the button is clicked.
Did you check the prosody logs to see whether the module was loaded successfully? Also, in my config the focus user is only set as admin in the global section and not in the muc component. And I donāt have the modules muc_meeting_id and muc_domain_mapper enabled but to be honest, I donāt know if this could affect the muc_config_restrict module.
1 Like
@plokta Couldnāt you remove the Remove Password button from the react template?
Thanks for the thread, this has been a super helpful discussion.
To remove the password button or to change some other css, i use this trick:
In the start of file config.js some lines can be added;
</script>
<style type="text/css">
.remove-password {
display: none;
}
</style>
<script>
Joachim
2 Likes
Hello,
I have followed the working version of @fyl2xp1 but with the secure domain enabled.
- modify: /etc/prosody/conf.d/domain.tld.cfg.lua
- create: /usr/lib/prosody/modules/mod_persist_muc_passwords.lua
I have an error that @fyl2xp1 already solved, maybe Iāve missing something, when I try to open/create a conference, Jitsi asks the login/password for the host, but after the credentials validation I have the following error:
Oops, Something went wrong and we couldnāt connect to the conference: connection.GET_SESSION_ID_ERROR.
Maybe I have miss to configure something ?
1 Like
I have the same problem.
After allowing access to microphone and camera, the āSomething went wrongā error appears.
Very rarely I am asked for the password first, but then the same error pops up.
It happens only if I call event.room:set_password(ā¦).
Iām running Prosody 0.10.0 on Ubuntu 18.04.4 LTS.
I only added this simple module:
module:hook("muc-room-created", function (event)
local room = event.room;
local pass = "test-pass";
room:set_password(pass);
end);
and enabled it like this:
Component "conference.domainā¦" "muc"
storage = "none";
modules_enabled = {
"muc_meeting_id";
"muc_domain_mapper";
"muc_max_occupants";
"my_muc_passwords"; -- ā
}
admins = { "focus@auth.domainā¦" }
muc_room_locking = false
muc_room_default_public_jids = true
Here are the JavaScript console errors:
2020-04-09T15:51:32.339Z [JitsiMeetJS.js] <getGlobalOnErrorHandler>: UnhandledError: null Script: null Line: null Column: null StackTrace: Error: "Focus error, retry after 1000"
_allocateConferenceFocusError moderator.js:446
allocateConferenceFocus moderator.js:373
s strophe.umd.js:2716
run strophe.umd.js:1875
_dataRecv strophe.umd.js:3157
forEachChild strophe.umd.js:830
_dataRecv strophe.umd.js:3146
_onRequestStateChange strophe.umd.js:5012
Logger.js:154:22
o Logger.js:154
getGlobalOnErrorHandler JitsiMeetJS.js:612
onerror middleware.js:100
callErrorHandler GlobalOnErrorHandler.js:61
_allocateConferenceFocusError moderator.js:446
allocateConferenceFocus moderator.js:373
s strophe.umd.js:2716
run strophe.umd.js:1875
_dataRecv strophe.umd.js:3157
forEachChild strophe.umd.js:830
_dataRecv strophe.umd.js:3146
_onRequestStateChange strophe.umd.js:5012
2020-04-09T15:51:32.341Z [modules/xmpp/moderator.js] <l.prototype._allocateConferenceFocusError>: Focus error, retry after 1000
<iq id="09f539c6-43b7-4b5a-b9bf-b48aaa7bd48f:sendIQ" type="error" to="78aed5e5-92d8-4844-b698-ā¦-455f-a0fd-859b404d375a" from="focus.domainā¦" xmlns="jabber:client">
Logger.js:154:22
o Logger.js:154
_allocateConferenceFocusError moderator.js:447
allocateConferenceFocus moderator.js:373
s strophe.umd.js:2716
run strophe.umd.js:1875
_dataRecv strophe.umd.js:3157
forEachChild strophe.umd.js:830
_dataRecv strophe.umd.js:3146
_onRequestStateChange strophe.umd.js:5012
2020-04-09T15:51:32.359Z [features/overlay] <componentDidMount>: The conference will be reloaded after 26 seconds. Logger.js:154:22
2020-04-09T15:51:32.373Z [conference.js] <_onConferenceFailed>: CONFERENCE FAILED: conference.focusDisconnected focus.domainā¦ 1
Looks like there is still a problem with jicofo to my untrained eye, even though I use the muc-room-created hook instead of muc-room-pre-create.
I would be very grateful for any hints.
IIRC, this approach has only been verified to work with Prosody >= 0.11 so if you use Prosody 0.10 you may need to check the respective Prosody API and adjust the module accordingly, or upgrade your Prosody to version 0.11 (not sure how complicated an upgrade would be).
1 Like
Due to a storage crash I had to start over with jitsi yesterday, so I pulled the latest docker for jitsi. I re-followed the steps I took in my first install - mostly slight changes to the module you proposed. But somehow I now get:
prosody_1 | modulemanager error Unable to load module 'muc_config_restrict': /usr/lib/prosody/modules/mod_muc_config_restrict.lua: No such file or directory
When I check the prosody container it is missing. I am not even sure if that file was present in my last jitsi. Am I misunderstanding something?
edit:
never mind, i obviously just had to pull muc_config_restrict from prosody. Must have done that late night last time.
This is very good.
It would be preferable, although we cant complain too much, if we could have administrative users create rooms within jitsi itself. But we can manage this easily enough (larger organizations will find this not scaling very well)
For other peoples sake Ill put clear notes on the mod_muc_config_restrict/mod_muc_config_restrict.lua module:
You can find the most recent version here. Put that script under /usr/lib/prosody/modules/mod_muc_config_restrict.lua