[join] Can join password-protected room with incorrect passwords

[joudinet]

I'm not 100% sure it's a bug of the join plugin and not of my ejabberd configuration, but I'm able to join a password-protected room without the correct password.
I attach the log of the following session:

• anonymous user alice logs in to ap XMPP server (and autojoin the greencom room)
• alice types /join room1 passw0rd (which shows her in a new room called room1)
• bob logs in to the same server (ap), also as an anonymous user
• bob types /join room1 wrongpassword and, surprisingly, gets connected to room1!

Alice's Javascript console: http://pastebin.com/cYmvdDXk

Bob's Javascript console: http://pastebin.com/ChpZf03z

[mweibel]

Ah, yes it's somewhat a problem of your ejabberd config:
The room doesn't exist on the server until Alice joins, therefore it gets created no matter what password you submitted. The password itself is ignored by the server and the temporary room is made public.

Therefore, when Bob joins, the temp room is still public & the password you send with has no effect.

If you want to have password protected rooms, you need to create them on the server & assign a password to it. AFAIK there's a module called mod_muc_admin which should help in creating persistent & password protected rooms.

[joudinet]

On Thu, Jan 23, 2014 at 4:26 PM, Michael Weibel
[email protected] wrote:

Ah, yes it's somewhat a problem of your ejabberd config:
The room doesn't exist on the server until Alice joins, therefore it gets created no matter what password you submitted. The password itself is ignored by the server and the temporary room is made public.

Therefore, when Bob joins, the temp room is still public & the password you send with has no effect.

If you want to have password protected rooms, you need to create them on the server & assign a password to it. AFAIK there's a module called mod_muc_admin which should help in creating persistent & password protected rooms.

I see, but I would like an anonymous user to be able to create private
rooms. Something similar to what you could do on IRC (I'm quite new to
XMPP environment). Do you know if this is possible with ejabberd?

Thanks.

Johan

[mweibel]

Ah, ok I understand.

Well yes this is possible with ejabberd (or better: with every XMPP server, as it's in the standard). You'd need to change the join plugin in order to change the temporary room configuration in case the server informs you that the room is not yet existed. In the XEP there's a big section on how you could achieve this. But of course this is nontrivial for a starter in XMPP (although certainly a good way to get to know the protocol better).

I don't know if @maennchen is willing to do this or if you'd like to do it. I currently have only limited time for Candy and I rather work not on the plugins currently.

[maennchen]

@mweibel I can make this change, but my Problem is that i have no understanding of XMPP at all. Someone would've to help me how to achieve this.

[joudinet]

Great. I don't have time this week but I can definitively help next week.
I don't know very well XMPP nor JavaScript, but from mweibel's link, the documentation seems pretty well self-explanatory, and it doesn't sound too complicated to me.
I let you know as soon as I start working on it.

[maennchen]

Great

[joudinet]

I'm back on business. Sorry for the delay, I had to work on something else, which I did finish Today ;-)
@maennchen : have you started on this issue yet? I can work on it this week.

[maennchen]

Nope, i've done nothing until now.Tommorrow i dont't habe time, but the rest of the week.

[joudinet]

After reading the XEP section shared by @mweibel, and browsing a bit Candy.Core and Strophe.js source code, I think there is two ways of implementing private room creation:

1. (proper way but may require changes to candy.core): Add an handler after sending the presence request in Candy.Core.Action.Jabber.Room. This handler waits for the server response, which in case of a status code 201, can configure the room by sending a configuration form request.
2. (uglier but should be doable without modification to candy.core): Let the user join the unprotected room, then at the corresponding candy:core.presence.room event, modify the room configuration as described in Section 10.2 (Subsequent Room Configuration).

The issue with 2 is that anyone can join the room before the owner has modify its configuration to make it private.
Still, I vote for the second solution as it is more modular and could also be used to modify the room configuration afterward. What do you think?

[mweibel]

Hi,

Point#1: I guess that would be a good option. I could add a default handler + emit an event in this case.
Point#2: As you said, this is uglier and I think the other option is better.

I'll take a look, maybe I can implement something like this in the refactoring branch.

Subsequent room configuration should also work with solution#1, as it works anyway. Question is how you'd like to do it because you might need to parse the form configuration and make a dynamic form within a modal in it (should be possible, it's just some work to do)

[joudinet]

Hi,
You convince me. Actually, the subsequent room configuration is independent of the join and, therefore, should be another plugin.
About Point#1: The current version of Core.Action.Jabber.Room includes an element qualified by the 'http://jabber.org/protocol/muc' namespace in the presence stanza, which means the server will lock the room until the room creator either accept an instant room or configure a reserved room. However, Candy doesn't seem to handle this scenario. IMO, this is a bug in the MUC support of Candy. So, we could also implement the full scenario in the default handler and there may be no need to emit another event afterward.

[joudinet]

I saw a reference to Strophe.muc.js plugin once, and after looking at how they handle the join (https://github.com/strophe/strophejs-plugins/blob/master/muc/strophe.muc.coffee), I'm wondering why candy doesn't use this plugin, instead of re-implementing its own MUC support?

[mweibel]

we currently don't use it a lot because it's buggy and Pull requests don't get merged in. I'm considering, as part of the refactoring branch, to fork it and use our version of the muc plugin.

[benlangfeld]

You might want to look into reserved rooms to resolve the race in configuring.