muc rooms not being created
fizk - November 15, 2009 - 14:25
| Project: | XMPP Framework |
| Version: | 6.x-2.x-dev |
| Component: | XMPP-API |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs review |
Description
The relavant code is:
// sending the initial presence to the room so we can create it
$conn->sendInitialRoomPresence($room);
$payload = $conn->processUntil('initial_room_enter', XMPP_API_PROCESS_TIMEOUT);
if ($payload[0][1] != 'result') {
_xmpp_api_disconnect($conn);
watchdog('xmpp_api', '@name does not have privileges to create muc rooms', array('@name' => XMPP_API_ADMINJID), WATCHDOG_ERROR);
return FALSE;
}In my ejabberd log, it shows that it created the room, and I can see the room being created, so the test for insufficient privileges isn't right.
When I remove that if statement, a room is created, but the browser stays in "loading" state until I join the room (using Pidgin for eg.) Then the browser reports successful room creation, which is correct.
However, the room has the temporary name, so I might have to change the code to just use the right name the first time.
#1
#2
MM not sure exactly why that would happen, however i normally utilize the xmlrpc interface to create the rooms, so i will have to dig into this issue with ejabberd and the xmpp_api
#3
This helps a little bit, the only problem now is that I have to join the room manually (with Pidigin) for the process to complete.
xmppframework/contrib/xmpp_api/xmpp_api.internal.inc::xmpp_api_create_muc()<?php
$payload = $conn->processUntil('initial_room_enter', XMPP_API_PROCESS_TIMEOUT);
if ($payload[0][1] != 'result') {
?>
to
<?php
$payload = $conn->processUntil('initial_room_enter', XMPP_API_PROCESS_TIMEOUT);
if ($payload[0][1] != 'default') {
?>
#4
Here's where it gets stuck:
00:51:41 SENT: <iq xmlns='jabber:client' type='set' id='2'><session xmlns='urn:ietf:params:xml:ns:xmpp-session' /></iq>Start receiving response:
00:51:41 RECV: <iq from='muc_556_182@conference.localhost' to='admin@...............00:51:41 RECV: ssword protected' var='muc#roomconfig_passwordprotectedroom'><value>.....................
Continue receiving the previous response..... ??? bizzar. As though the buffer needs to be flushed.
00:51:50 [VERBOSE]: RECV: muc#roomconfig_moderatedroom'><va....................</x></query></iq>00:51:50 [DEBUG]: EVENT: muc_created
....
....
#5
So why are we waiting for "initial_room_enter"? Maybe we should be waiting for another event. Is this event documented in ejabberd or XMPP standard?
#6
It seems the vendor library is speaking GroupChat 1.0, not Basic MUC, because it's sending:
<presencefrom='hag66@shakespeare.lit/pda'
to='darkcave@chat.shakespeare.lit/thirdwitch'>
</presence>
instead of:
<presencefrom='hag66@shakespeare.lit/pda'
to='darkcave@chat.shakespeare.lit/thirdwitch'>
<x xmlns='http://jabber.org/protocol/muc'/>
</presence>
#7
FIXED!
1. Call $conn->configureMucRoom($room); twice
2. Change
<?php$values['data'] = $options[$key];
?>
<?php$packet[$key]['data'] = $options[$key];
?>
#1 fixes the response problem. #2 is a separate bug fix.
#8
#9
Can you provide a patch for this so it can be verified, i have no idea where these are going to go currently.
Thanks
#10
This has four bug fixes.
#11
Btw, I've seen some empty
$Idtags, is that how it comes out for non-dev releases?I'm using
$Id$(two $'s)