Categories
General

Openfire/Smack bug? Unable to ask Multi-User Chat who the admins are

I encountered two interesting points when working with the Openfire XMPP server and the Smack API, both from IgniteRealtime.

  1. After joining a Multi-User Chat (MUC) independently, without invite, I was forbidden (e.g. error 403) from finding out who the administrators or owners of the room were. I could not find anything about this in the documentation.
    The workaround was not too bad: apparently the method getOccupant() allows you to get an Occupant object which does hold affiliation and can report admin rights.
  2. In some situations – not sure when yet – the owner of an MUC was able to grant another user admin status by just using his/her nickname, without using the full JID. That is
    grantAdmin("nickname") worked just as well as grantAdmin("nickname@conference.server"). Nonetheless, when trying to use the method getOccupant() as mentioned above, the full JID form worked while the nickname-only one failed.

I am using Smack 3.0.4 and Openfire 3.5.2. Weird.

Share
Categories
General

Setting up JSJaC with Openfire 3.5.2

I am using Openfire, an XMPP (Jabber) server, to facilitate instant messaging in a closed system I am building. Part of my design had users rely on browsers as instant messaging (IM) clients. As Meebo showed, it can be done quite well and an open source JavaScript library, JSJaC, apparently provides this ability. JSJaC is the backbone of a full-blown browser-based IM client called JWChat, but for me, the plumbing was what was necessary.

Only thing is that JSJaC is not the easiest to set up with Openfire.

JSJaC uses HTTP-binding, which according to Wikipedia allows for long-lasting HTTP requests instead of polling, which just periodically checks the server to see if there is a message waiting. To do that, JSJaC needs to connect to the server and that is done by accessing a somewhat tricky port, 7070 is the default in version 3.5.2. What’s tricky about it? Browsers do not like to let JavaScript access services using XMLHttpRequest, the lifeblood of AJAX, on URLs and ports unlike the one which the current URL relies on. This is normally solved using a proxy or a URL rewrite, which forward requests to the desired ports and pass back responses, all as if you used the ‘appropriate’ ports. Luckily, Apache’s HTTPd has great modules that do just that. The instructions in JSJaC’s readme file recommended using a rewrite. That caused repeated 503 errors from Apache. Using its proxy did work for me. As usual, you spend time, read here and read there, and finally, you normally find a way to make it work. This how I did it.

  1. After downloading JSJaC, open jsjac.js. Change the line
    var JSJACHBC_USE_BOSH_VER=false;

    to

    var JSJACHBC_USE_BOSH_VER=true;
  2. To allow Apache HTTPd’s proxy to work, enable proxy_module and proxy_http_module in Apache HTTPd’s httpd.conf file
  3. Add a virtual host that will map a certain URL to the proxy, and set up the proxy to point at the Openfire http-binding port:
    <virtualhost 127.0.0.1:80>
    	DocumentRoot "C:/www/root"  <!-- This is the document root for your server -->
    	AddDefaultCharset UTF-8
    	ProxyRequests On
    	ProxyPass /http-bind/ http://127.0.0.1:7070/http-bind/ <!-- This is where your Openfire server can be accessed -->
    </virtualhost>
  4. To test this configuration, use JSJaC’s simpleclient.html, its sample client, to try and connect to the server. Make sure you add the following line
    oArgs.authtype = 'nonsasl';

    above

    con.connect(oArgs);
  5. Start Apache HTTPd and open simpleclient.js
  6. simpleclient asks for 4 fields:

    • The server’s base URL: This is the proxied URL, for example, http://127.0.0.1/http-bind/ (note the trailing slash) in my case.
    • Server name/domain: The domain Openfire was set up to use. In XMPP, if the server’s name is myserver, users will be known on it with IDs like joe@myserver
    • User name of existing user
    • The password for that user
  7. Connect!

I highly recommend using Firebug to ensure the request is sent properly and is being received properly from Openfire. Odd Firefox object initialization errors are due to the fact that an attempt is made to access a port JavaScript is not allowed to access.

Share
Categories
Computing General Web Development

Internet Explorer 8: Stay away, don’t believe the hype, aaaaaaaaaaargh!

I was stupid enough to believe all the offhand mentions like on the Wall Street Journal that said that Internet Explorer 8’s beta actually worked nice. So much so that having not been burnt by installing Chrome, I felt bandwagonesque enough to also install IE 8.

First, IE 8 *overwrites* and *replaces* IE 7. That is as uncool and unacceptable as it gets. You (Microsoft) are replacing a WORKING, STABLE program with a BETA in an all-or-nothing move without too much warning. That’s a load of crap. Suppose you have so much faith in it that you are fine with that.

Next, Security so high it is outrageously stupid. File again, under ‘unacceptable’: on my Windows XP machine, IE 8’s default setting disable JavaScript *ENTIRELY*. I repeat, no f-n JavaScript. Never mind Flash, but you know, it 2008. JavaScript is an unproven, new tool, yup yup. Fail fail fail. Anyway, they tell you that your add-ons are disabled. You click the link to the add-on manager and lo-and-behold, ALL OF THEM APPEAR ENABLED. WTF?

add-ons

So how do you solve this? According to Microsoft’s support, it is as simple as changing an f-n REGISTRY KEY?! As user friendly as entering a class id to the registry. ARE THEY NUTS? DO THEY EVEN CARE?! Is it possible to goof off even more?! A beta means ‘on the verge of release’. This is plain dreadful, Microsoft. Look in the f-n mirror and like, think again. I am so selling my miserable 10 stocks of yours. You suck beyond belief. Really. Done. Indefensible.

Share
Share