Community
Participate
Working Groups
Created attachment 105365 [details] Patch which adds an "Alternative Host Name" field to the XMPP connection dialog, thus enabling GTalk use for users outside of xxxx@gmail.com without voodoo. I wanted to show off with ECF and shared editor sessions to my colleagues. BUT! Since I'm user of Google's mail on a (several) hosted domains, I ran into the problem about setting the host name (talk.google.com) on the XMPP connection, for domains other than gmail.com. The workaround, as specified in bug 196298, is to add ecf.xmpp.google.override=yourdomain.com to your config.ini file, and just add the XMPP user as you@yourdomain.com, which works but is cumbersome. I sought a better solution to the problem of providing the server name, and came up with this patch, which adds a new (optional) field to the XMPP and XMPPS dialogs. I know this is too late for Ganymede, but mabye next time? (ECF rocks!) BTW: The dialog looks funny in Mac OS X.
Changing target milestone to 2.1
Is this going into Galileo? It is really useful for GTalk users...
Hi Jesper...my apologies, I lost track of this. Thanks for the notice. I will try to apply as soon as possible. It might be necessary to ask you for a revised patch...but hopefully not.
Created attachment 126341 [details] I've refreshed the patch for ECF HEAD For your convenience, I've updated the patch for current HEAD.
Applied patch, tested and released to HEAD. Thanks kindly Jesper for the contribution...this is most appreciated...and will be immediately used by me (as well as others). Please forgive my oversight about waiting this long to apply the patch. Resolving as fixed.
Unfortunately, this change breaks logins where usernames are of the form: slewis@eclipsesource.com as the parsing in ECFConnection assumes that the username can contain the target host...rather than the username. This breaks, for example the Eclipse IM, where the bugzilla username/password are used to access xmpp.eclipse.org...i.e. username is: slewis@eclipsesource.com, and host is xmpp.eclipse.org. I'm going to need to think about how to deal with this. One possibility is to encode the hostnameOverride in the *host* rather than the username. Jesper any comments about that as a strategy?
I propose that this be bug be fixed in the following manner: 1) If present, the alternative server be added onto the usernamehost string like this: user@host;alternativehost:port Where user can include an '@' sign...e.g.: slewis@eclipsesource.com@xmpp.eclipse.org;talk.google.com:port/whatever And the above would be parsed by the XMPPID/XMPPSID as: username = slewis@eclipsesource.com host = xmpp.eclipse.org;talk.google.com:port resource = /whatever 2) When a connection is requested, the host (xmpp.eclipse.org;talk.google.com:port) is parsed to determine if an alternative server is specified (in org.eclipse.ecf.internal.provider.xmpp.smack.ECFConnection.connect) and if so, used. 3) The username is used as is and passed to the login/authentication in ECFConnection.
Created attachment 135474 [details] Patch with proposed fix for bug that was cause for reopening This patch proposes a fix for the bug described in comment #6 and comment #7. I changes the handling of alternative servers to putting in hostname rather than username, so as to allow use of usernames of the form 'slewis@eclipsesource.com'. ECF committers...please review and comment and/or approve.
Patch released to HEAD for RC1 build on 5/12/2009. No API or UI changes. Resolving.
Phew, things move fast around here. :-) (In reply to comment #7) > I propose that this be bug be fixed in the following manner: > [...] > slewis@eclipsesource.com@xmpp.eclipse.org;talk.google.com:port/whatever Is this string really meaningful? Isn't it overriding both the user name and the server name - how would 'xmpp.eclipse.org' be used? Note: I'm not familiar with the idea behind Eclipse IM, but as i understand it, it's really an XMPP server using the Bugzilla logins as user names, right? Mine would be jesper@selskabet,org@xmpp.eclipse.org? How is this different from Google Talk used with a user using Google Apps (as in jesper@selskabet,org@talk.google.com). This would be the natural thing to do, IMHO, simply parsing the server:port to be the part to the right of the last '@', and the remainder being the username. If my patch (or the previous workaround) got it "backwards", as in jesper@talk.google.com@selskabet,org then I think this should be reversed in which case it would work for both providers. If this is not acceptable (due to backwards compatibility), yes, then your scheme would work. And I assume it does work, why not just leave it at that? Besides, I can't figure out how to login to xmpp.eclipse.org using my bugzilla account and login. Am I required to activate it first somehow?
(In reply to comment #10) > Phew, things move fast around here. :-) Well, with so little time before Galileo we have to move pretty fast...and faster as May goes on... > > (In reply to comment #7) > > I propose that this be bug be fixed in the following manner: > > [...] > > slewis@eclipsesource.com@xmpp.eclipse.org;talk.google.com:port/whatever > > Is this string really meaningful? Isn't it overriding both the user name and > the server name - how would 'xmpp.eclipse.org' be used? Well, in ECFConnection there is code like this: int semiColonIdx = hostname.lastIndexOf(';'); if (semiColonIdx != -1) { hostnameOverride = hostname.substring(semiColonIdx + 1); hostname = hostname.substring(0, semiColonIdx); } In your scenario above, hostnameOverride="talk.google.com" and hostname="xmpp.eclipse.org" Later in the code the following assignment happens: final String serviceName = hostname; And then still later: connection = new SSLXMPPConnection(hostnameOverride,serverPort, serviceName); So both the hostnameOverride and the serviceName/hostname are used. > > Note: I'm not familiar with the idea behind Eclipse IM, but as i understand it, > it's really an XMPP server using the Bugzilla logins as user names, right? Mine > would be jesper@selskabet,org@xmpp.eclipse.org? Right. > > How is this different from Google Talk used with a user using Google Apps (as > in jesper@selskabet,org@talk.google.com). > > This would be the natural thing to do, IMHO, simply parsing the server:port to > be the part to the right of the last '@', and the remainder being the username. Although I see your point, I don't agree. It seems to me the hostnameOverride is exactly that...an override for the hostname...and not a qualifier for the username. The username jesper@selskabet.org really is the username...i.e. it's what's passed into the smack call: connection.login(username, (String) data, serverResource); > > If my patch (or the previous workaround) got it "backwards", as in > jesper@talk.google.com@selskabet,org then I think this should be reversed in > which case it would work for both providers. If this is not acceptable (due to > backwards compatibility), yes, then your scheme would work. > > And I assume it does work, why not just leave it at that? > > Besides, I can't figure out how to login to xmpp.eclipse.org using my bugzilla > account and login. Am I required to activate it first somehow? > With the fix I've committed to HEAD, I am able to login to my xmpp.eclipse.org account with the following info: User ID: slewis@eclipsesource.com (my bugzilla username) Password: <my password> With the fix applied this works...it doesn't work with the old code (as I found), because the '@' is parsed as the xmpp host (i.e. eclipsesource.com) and the xmpp.eclipse.org as the alternate server, with username = slewis...which doesn't work (because the xmpp.eclipse.org server is expecting an escaped version of slewis@eclipsesource.com for my username, rather than just 'slewis'. I'm also able to login to my google-talk hosted eclipsesource account with: User ID: slewis@eclipsesource.com Alternate Server: talk.google.com Password: <mypass> This also works because the UI creates a String of the form (for creation of an XMPPID): slewis@eclipsesource.com;talk.google.com and it's parsed as username=slewis hostname=eclipsesource.com hostnameOverride=talk.google.com
