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.

CommentFileSizeAuthor
#10 xmmpframework-6x-2.1-xmpp_api.internal.inc_.patch3.92 KBfizk

Comments

fizk’s picture

fizk commented
Component: Code » XMPP-API
darren.ferguson’s picture

darren.ferguson commented

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

fizk’s picture

fizk commented

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()

  $payload = $conn->processUntil('initial_room_enter', XMPP_API_PROCESS_TIMEOUT);

  if ($payload[0][1] != 'result') {

to


  $payload = $conn->processUntil('initial_room_enter', XMPP_API_PROCESS_TIMEOUT);

  if ($payload[0][1] != 'default') {
fizk’s picture

fizk commented

Here's where it gets stuck:

  1. 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>.....................
  2. I create the room manually with Pidgin

  3. 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
     ....
     ....
fizk’s picture

fizk commented

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?

fizk’s picture

fizk commented

It seems the vendor library is speaking GroupChat 1.0, not Basic MUC, because it's sending:

<presence
    from='hag66@shakespeare.lit/pda'
    to='darkcave@chat.shakespeare.lit/thirdwitch'>
</presence>

instead of:

<presence
    from='hag66@shakespeare.lit/pda'
    to='darkcave@chat.shakespeare.lit/thirdwitch'>
  <x xmlns='http://jabber.org/protocol/muc'/>
</presence>
fizk’s picture

fizk commented

FIXED!

1. Call $conn->configureMucRoom($room); twice

2. Change $values['data'] = $options[$key]; to $packet[$key]['data'] = $options[$key];

#1 fixes the response problem. #2 is a separate bug fix.

fizk’s picture

fizk commented
Status: Active » Needs review
darren.ferguson’s picture

darren.ferguson commented

Can you provide a patch for this so it can be verified, i have no idea where these are going to go currently.
Thanks

fizk’s picture

fizk commented
StatusFileSize
new xmmpframework-6x-2.1-xmpp_api.internal.inc_.patch3.92 KB

This has four bug fixes.

fizk’s picture

fizk commented

Btw, I've seen some empty $Id tags, is that how it comes out for non-dev releases?

I'm using $Id$ (two $'s)