A few questions about Prosocy console

[karma.some...@gmail.com]

Hi,

We're currently testing Prosody because we're looking for an IM platform in order to establish it in our company, and we've made a compilation of questions about the console capabilities and Prosody in general:

1) Is it possible to list all users in a chatroom?

2) Assuming we want to allow free account registration, is it possible to forbid the registration of a certain account (the jupe equivalent on IRC)?

3) Is it possible to deny joining a channel with a certain name on a MUC?

4) Is it possible to avoid users with a certain IP address to connect to the Prosody server (the G-Line equivalent on IRC)?

Any help will be appreciated!

Regards.

[Matthew Wild]

Hi,

On 8 February 2015 at 10:58, <karma.some...@gmail.com> wrote:
> Hi,
>
> We're currently testing Prosody because we're looking for an IM platform in
> order to establish it in our company, and we've made a compilation of
> questions about the console capabilities and Prosody in general:
>
> 1) Is it possible to list all users in a chatroom?

Hmm, from the console? There's not currently an easy way. We'll have to add it!

But for now, you could take this block of code:

function prosody.muc_users(room_jid)
local jid = require "util.jid";
room_jid = jid.prep(room_jid);
local room_name, room_host = jid.split(room_jid);
if not hosts[room_host] or not hosts[room_host].modules.muc then
return nil, "Not a MUC host: "..room_host;
end
if not hosts[room_host].modules.muc.rooms[room_jid] then
return nil, "No such room: "..room_jid;
end
local out = {"\n"};
for k, v in
pairs(hosts[room_host].modules.muc.rooms[room_jid]._occupants) do
out[#out+1] = v.jid.."\t"..select(3, jid.split(k));
end
return table.concat(out, "\n");
end

and put it in a module, or even in your config file. Then in the
telnet console run:

> prosody.muc_users("room@servername")

> 2) Assuming we want to allow free account registration, is it possible to
> forbid the registration of a certain account (the jupe equivalent on IRC)?

See https://code.google.com/p/prosody-modules/wiki/mod_block_registrations

> 3) Is it possible to deny joining a channel with a certain name on a MUC?

You mean you want to prevent users using certain nicknames? I don't
think we currently have anything for this, but it could be done with a
plugin.

If you're coming from IRC and you are talking about bans... in XMPP
they are based on the user's JID, rather than nickname (or IP, but see
below...).

> 4) Is it possible to avoid users with a certain IP address to connect to the
> Prosody server (the G-Line equivalent on IRC)?

Generally XMPP is quite a different architecture to IRC and, since
there is the ability for users to join from remote servers we don't
know, we don't always have the user's IP to ban in this way.
Specifically XMPP makes a distinction between the place you log in to
the network (and authenticate) and the place where rooms are hosted.

However I think you're probably planning a closed system, so this
won't be a problem. If you want to stop IP addresses from accessing
the server (because of abuse), the best way is always to use your
system's firewall - that is it's primary purpose, and it is designed
to be very efficient at it's job.

For IP banning from particular rooms, you can load mod_muc_ban_ip:
https://code.google.com/p/prosody-modules/wiki/mod_muc_ban_ip

Still, if for some reason you really wanted to ban an IP address at
the Prosody level, this could again be done as a plugin.

Hope this helps! Let me know if you still have any questions.

Regards,
Matthew

[karma.some...@gmail.com]

Hi Matthew,

First off, thank you very much for your answers.

Nice. I'll give it a try, but that's basically what I needed.

 

> 2) Assuming we want to allow free account registration, is it possible to
> forbid the registration of a certain account (the jupe equivalent on IRC)?

See https://code.google.com/p/prosody-modules/wiki/mod_block_registrations

I could find it yesterday after sending the message... :-) Thanks.

 

> 3) Is it possible to deny joining a channel with a certain name on a MUC?

You mean you want to prevent users using certain nicknames? I don't
think we currently have anything for this, but it could be done with a
plugin.

If you're coming from IRC and you are talking about bans... in XMPP
they are based on the user's JID, rather than nickname (or IP, but see
below...).

I rather meant forbidding the whole chatroom. We want to avoid some users to join certain chatrooms (for example, child pornography thematics and so on), so we want some rooms to be forbidden to create. I know I could register an account for that and make it 'member only' and put this account as owner, but I was wondering if there's an easier way?

 

> 4) Is it possible to avoid users with a certain IP address to connect to the
> Prosody server (the G-Line equivalent on IRC)?

Generally XMPP is quite a different architecture to IRC and, since
there is the ability for users to join from remote servers we don't
know, we don't always have the user's IP to ban in this way.
Specifically XMPP makes a distinction between the place you log in to
the network (and authenticate) and the place where rooms are hosted.

However I think you're probably planning a closed system, so this
won't be a problem. If you want to stop IP addresses from accessing
the server (because of abuse), the best way is always to use your
system's firewall - that is it's primary purpose, and it is designed
to be very efficient at it's job.

For IP banning from particular rooms, you can load mod_muc_ban_ip:
https://code.google.com/p/prosody-modules/wiki/mod_muc_ban_ip

Still, if for some reason you really wanted to ban an IP address at
the Prosody level, this could again be done as a plugin.

Hope this helps! Let me know if you still have any questions.

Thanks so much for your help, indeed I just "arrived" from the IRC architecture and these explainations help me understanding the XMPP architecture a bit more.

Regards!

 

Regards,
Matthew

[Matthew Wild]

Ah, ok. We have the ability to restrict creation of rooms to only
admins, but I don't think we have anything just to block certain room
names.

It seems a strange solution, as people could just make up different
names to work around the ones you ban?

Anyway, if you have only a few, there is a hacky way to do what you
want... create an empty plugin file (mod_null.lua?) and put in your
config:

Component "badr...@conference.example.com" "null"
Component "badr...@conference.example.com" "null"
etc.

This should work fine I think, but a much cleaner way would be to make
a plugin that reads a list of names (or patterns?) from a file and
informs the user about why they can't create the room.

Regards,
Matthew

[karma.some...@gmail.com]

Nice, that worked fine :-) I will try making the plugin, however, although I'm quite new to Lua. I've been reading the documentation about Module development, and I found this: "Stanza events are composed of the name and the destination JID type. For example "message/bare". Names may be one of "message", "presence", "iq" - JID type may be "bare", "full", "host", or "self".". Which event would correspond to a user joining a room?

Thanks for your kind help!

Regards.

 

Regards,
Matthew

[Matthew Wild]

Hi,

Sorry for the delay replying...

On 9 February 2015 at 21:24, <karma.some...@gmail.com> wrote:
> Nice, that worked fine :-) I will try making the plugin, however, although
> I'm quite new to Lua. I've been reading the documentation about Module
> development, and I found this: "Stanza events are composed of the name and
> the destination JID type. For example "message/bare". Names may be one of
> "message", "presence", "iq" - JID type may be "bare", "full", "host", or
> "self".". Which event would correspond to a user joining a room?

I didn't mean that you specifically would have to write it, it should
be fairly straightforward though and if you're up for it, great! Happy
to help.

The event you want to hook is "presence/full", because XEP-0045 (the
MUC specification) says that to join a room the user sends presence to
a full JID.

Note that the module will have to be explicitly loaded on the MUC
host, so your config should look something like:

Component "conference.example.com" "muc"
modules_enabled = { "muc_restricted_rooms" }

This would load mod_muc_restricted_rooms.lua onto the MUC host, and
"presence/full" will catch presence from users. You can exit early
from your handler if the room already exists.

https://prosody.im/doc/installing_modules is an overview of how
Prosody looks for module files. And mod_muc_limits in the
prosody-modules project may be a useful example (e.g. it shows you how
to get the table of rooms from mod_muc, right at the top):
https://code.google.com/p/prosody-modules/source/browse/mod_muc_limits/mod_muc_limits.lua

Hope this helps!

Regards,
Matthew

[karma.some...@gmail.com]

El viernes, 13 de febrero de 2015, 14:09:54 (UTC), Matthew Wild escribió:

Hi,

Sorry for the delay replying...

On 9 February 2015 at 21:24,  <karma.some...@gmail.com> wrote:
> Nice, that worked fine :-) I will try making the plugin, however, although
> I'm quite new to Lua. I've been reading the documentation about Module
> development, and I found this: "Stanza events are composed of the name and
> the destination JID type. For example "message/bare". Names may be one of
> "message", "presence", "iq" - JID type may be "bare", "full", "host", or
> "self".". Which event would correspond to a user joining a room?

I didn't mean that you specifically would have to write it, it should
be fairly straightforward though and if you're up for it, great! Happy
to help.

Yes, I want to have a try because I love challenges. If I finally manage to implement it and you think it might be useful, I will be happy to submit it to the modules page :-) In this context, I missed a bit deeper explaination of the events in the modules development page and which events should be used for any actions, or some link with a bigger detail explaination. As it is now I was a bit lost and didn't find some further detail until now that you answered :-)

 

The event you want to hook is "presence/full", because XEP-0045 (the
MUC specification) says that to join a room the user sends presence to
a full JID.

Note that the module will have to be explicitly loaded on the MUC
host, so your config should look something like:

Component "conference.example.com" "muc"
   modules_enabled = { "muc_restricted_rooms" }

This would load mod_muc_restricted_rooms.lua onto the MUC host, and
"presence/full" will catch presence from users. You can exit early
from your handler if the room already exists.

https://prosody.im/doc/installing_modules is an overview of how
Prosody looks for module files. And mod_muc_limits in the
prosody-modules project may be a useful example (e.g. it shows you how
to get the table of rooms from mod_muc, right at the top):
https://code.google.com/p/prosody-modules/source/browse/mod_muc_limits/mod_muc_limits.lua

Hope this helps!

Nice, I'll give it a try, thanks so much for your kind help!

Regards.

 

Regards,
Matthew

[karma.some...@gmail.com]

Hi again,

Seems that I *almost* have it, but I'm having some issues with the event itself. Basically I check whether the room is allowed and if not, within the hook function I set:

event.allowed = false;

event.origin.send(st.error_reply(event.stanza, "cancel", "not-allowed", "This room is forbidden"));

My aim is to show a message to the user explaining the reason why they can't join that room (this will be defined in config). However, although the user indeed can't join the room, the second line doesn't seem to make the message show up. Is there anything I'm missing or handling incorrectly?

Thanks!

[Matthew Wild]

On 18 February 2015 at 21:06, <karma.some...@gmail.com> wrote:
> Hi again,
>
> Seems that I *almost* have it, but I'm having some issues with the event
> itself. Basically I check whether the room is allowed and if not, within the
> hook function I set:
>
> event.allowed = false;
> event.origin.send(st.error_reply(event.stanza, "cancel", "not-allowed",
> "This room is forbidden"));
>
>
> My aim is to show a message to the user explaining the reason why they can't
> join that room (this will be defined in config). However, although the user
> indeed can't join the room, the second line doesn't seem to make the message
> show up. Is there anything I'm missing or handling incorrectly?

What client are you testing with? Perhaps try another, as not all of
them are great at error handling unfortunately.

Also confirm in the client's XML console that you are receiving a
<presence type='error'> from the room with the message you set in the
module.

Regards,
Matthew

[karma.some...@gmail.com]

El miércoles, 18 de febrero de 2015, 21:09:35 (UTC), Matthew Wild escribió:

On 18 February 2015 at 21:06,  <karma.some...@gmail.com> wrote:

[...] 

What client are you testing with? Perhaps try another, as not all of
them are great at error handling unfortunately.

Also confirm in the client's XML console that you are receiving a
<presence type='error'> from the room with the message you set in the
module.

Regards,
Matthew

Thanks Matthew,

Indeed, it seems to be a client problem. I'm running Psi 0.15 (for Win), once activating the XML console I see this:

<presence from="forb...@conference.mynet.es/username" type="unavailable" to="user...@192.168.1.207/username-PC">

<status>Kicked: forbidden: This room is forbidden</status>

<x xmlns="http://jabber.org/protocol/muc#user">

<item affiliation="owner" role="none"/>

<status code="110"/>

</x>

</presence>

So I guess this is the problem. I will check with other clients as well, just to confirm.

Thank you! 

[Matthew Wild]

On 18 February 2015 at 22:22, <karma.some...@gmail.com> wrote:
> Indeed, it seems to be a client problem. I'm running Psi 0.15 (for Win),
> once activating the XML console I see this:
>
> <presence from="forb...@conference.mynet.es/username" type="unavailable"
> to="user...@192.168.1.207/username-PC">
> <status>Kicked: forbidden: This room is forbidden</status>
> <x xmlns="http://jabber.org/protocol/muc#user">
> <item affiliation="owner" role="none"/>
> <status code="110"/>
> </x>
> </presence>
>
>
> So I guess this is the problem. I will check with other clients as well,
> just to confirm.

Right, this doesn't look like the result of st.error_reply(), e.g. it
has type='unavailable' instead of type='error'. It should be
generating something that looks more like example 152 at
http://xmpp.org/extensions/xep-0045.html#createroom

Regards,
Matthew

[karma.some...@gmail.com]

El miércoles, 18 de febrero de 2015, 22:48:38 (UTC), Matthew Wild escribió:

On 18 February 2015 at 22:22,  <karma.some...@gmail.com> wrote:
> Indeed, it seems to be a client problem. I'm running Psi 0.15 (for Win),
> once activating the XML console I see this:
>

> <presence from="forbidden@conference.mynet.es/username" type="unavailable"

> to="user...@192.168.1.207/username-PC">
> <status>Kicked: forbidden: This room is forbidden</status>
> <x xmlns="http://jabber.org/protocol/muc#user">
> <item affiliation="owner" role="none"/>
> <status code="110"/>
> </x>
> </presence>
>
>
> So I guess this is the problem. I will check with other clients as well,
> just to confirm.

Right, this doesn't look like the result of st.error_reply(), e.g. it
has type='unavailable' instead of type='error'. It should be
generating something that looks more like example 152 at
http://xmpp.org/extensions/xep-0045.html#createroom

Regards,
Matthew

You're right, I found out the mistake, I was just calling the event.origin.send() function instead of returning it in the hook handler. Basically, replacing:

event.origin.send(st.error_reply(event.stanza, "cancel", "not-allowed", "This room is forbidden"));

return true;

With:

return event.origin.send(st.error_reply(event.stanza, "cancel", "not-allowed", "This room is forbidden"));

It worked like a charm :-) Thanks for your help!