Hi,
I already found that accessing legacy network transports in Openfire from other servers like Google Talk is not supported currently, but I also found that it might happen. So my question is whether there is some progress on this issue.
If implementing this feature has reasonable complexity, say it can be done over weekend, and someone will show me where and what, I would be interested in implementing it myself.
Thankds, Petr.
Howdy, part of the problem is that to implement that functionality would ruin the end user experience. See my podcast post here:
http://www.igniterealtime.org/community/blogs/pocasts/2007/09/11/external-vs-int ernal-gateways
The plugin uses a lot of internals to get it’s job done so implementing such functionality would be non-trivial. And again, I just don’t know if it’s a good idea seeing as it would be a bad end user experience. =) I just don’t know if I want to support suffering. (hehehehe)
Of course, you -could- go the other way. Use your Openfire account and log into your Google Talk account from it.
Hi, I realize that user experience with XMPP legacy networks transports as currently standardized and implemented is far from perfect and now I see that Openfire IM Gateway does not support external servers and implementing it would take more time than I am able to invest.
My motivation is to use Google Talk client because of its unique features, especially one thing I call “zero network configuration” and ability to run under “User” group account on windows. I can tell to my friends and family, who are really ordinary users and don’t know and don’t need to know what proxy or IP is, just to grab Google Talk client and install it or even take file I sent, drag it on desktop, double click it, enter ID and paswword and it works.
It works seamlessly even in corporate environment, where the only way out is ISA http proxy server requiring NTLM authentication. And this is because, according to my observations and knowledge, Google Talk client is able to:
Autodetect proxy host and port
Authenticate with proxy using NTLM.
Take credentials from windows session using SSPI or what is the correct name for this.
Adjust login server settings since it is necessary to connect to 443
If there exists another Jabber client working like this and Openfire can be configured to accept HTTP CONNECT connections on 443 port through proxy servers, then using my Openfire instance could be a solution, otherwise I will probably use jabberd, I expect C application will be more resource friendly, and PyICQt/PyAIMt.
But I have found no such client so far, I have tried close to dozen of them, but none work that way. In better case client can do NTLM, but have to be configured manually. And navigating normal user by phone or e-mail to find out and use correct configuration is quite a big problem, user would have to remember to change their passwords and if not, they risk locking their accounts.
In worse case clients do not support NTLM, so some other software like Python and NTLM APS or CNTLM must be used (this is case of original ICQ 6 client). This what I call bad user experience. But I was focusing primarily on multiprotocol clients, so pure Jabber client with this functionality still may exist.
The bad user experience I refer to is, in the scenario where you can access the transports form an external server (google talk), the end user gets bombarded with a lot of requests they typically don’t understand. Lets say you have 83 AIM contacts and you subscribe to PyAIMt. You’ll get 83 “this person wants to auth you” requests. Sometimes this crashes the client. Either way it means clicking 83 times. Miss one? (like click the wrong button on one of the requests) Well tough because there’s no way that PyAIMt has any idea that you don’t have the contact on your roster and it just assumes you do and that you accepted the request. This is what frustrated me so when I wrote PyAIMt and PyICQt… there was no good way around it.
As you probably already know, Spark has SSO support, but judging from the documentation I’m reading at the moment it requires just what you said… some setup on the client side. (I’m referring to: http://wiki.igniterealtime.org/display/SPARK/SSO+Usage) I also don’t believe it does anything automatic in terms of proxies. I guess at the moment I really don’t have a good suggestion for you. It you are tied to the Google Talk client and there isn’t a way to get that client to point to another server, you might be better off going the PyICQt and PyAIMt (and friends) route … which don’t really matter much what server you use with them. Of course, since I stopped developing those, they don’t really have much development work going on anymore. They do have a maintainer but he hasn’t had a lot of time to work on them at all.