Openfire behind proxy

Openfire Plugins Kraken - IM Gateway
61

Thanks for this note actually, I had a minor report that this might be occuring from someone else and hadn’t had time to confirm it yet. =)

62

Here are some clues :

  1. Update of openfire:

I send you in a previous mail some clues about Java 1.5 API for proxy auth.

http://java.sun.com/j2se/1.5.0/docs/guide/net/proxies.html

But it does not include authentication issues, because I don’t think the API itself provides required methods to auth against a proxy easily.

I have found another reference that seems to explain some possiblities:

http://www.developer.com/java/other/article.php/1551421

There are others alternatives, but they all imply, as this one, to have plain text user/password stor’ed somewhere (brrrrrrr).

E.g of others alternatives with Java API only: http://www.javaworld.com/javaworld/javatips/jw-javatip42.html

(still plain text usr/pass required :/)

This is also due to the fact that proxies offers several ways to authenticate, and if you want the plugin to be usable by most of the people, it should complain to all the differents ways. Apache proposed a solution that handle for you all the manner to auth, but I read it requires higher skills in software development, but you should have I think.

see: http://jakarta.apache.org/httpcomponents/httpclient-3.x/authentication.html

Note that I don’t really know how to use the Apache stuff though.

Maybe a clean solution whould be to ask to openfire developpers to embed “behind proxies mechanism” within openfire, as your porblem will concern most of the plugin (Better to give the proxy once for all in openfire global settings rather than in each plugin actually).

  1. dirty workaround

When you set HTTP_PROXY env variable like:

http://mywebcache.mydomain.com:port

you should be able to use the auth with:

http://user:pass@mywebcache.mydomain.com:portpass@mywebcache.mydomain.com:port

which would imply to store in the environment of the user executing openfire a user/pass for the proxy (… !!!) and there’s a problem behind it:

If you create, let’s say user: openfire, pass:mypass in your proxy users, then all http(s) connection will be using that user after setting the env variable. What’s the point then in using a dummy user/pass if you won’t be able then to know who is really connecting ? (proxy log would just say “openfire” for all httpconnections)

HTH

cgravier

63

Hey thanks for the info. Couple of things.

  1. Would you mind posting comments to GATE-130 as you come across more useful info? I’m trying to collect useful links and info there for when I can dive into this.

  2. For proxy settings, I was thinking of adding some sort of “global transport settings” section to the settings page to house it and perhaps some other things. Can anyone think of any reason why they would want/need to give individual transports different proxy settings?

  3. I’d hit up the httpclient jakarta stuff before and as far as I can tell it only really works with HTTP requests. I need to work out something that’ll work across the board. Some protocol library implements should be trivial to implement it for. martyr/IRC for example will let me pass a Socket to it for it’s connections so I could prep the socket and hand it off. JML/MSN is a little more complex but doable (I have full control over the source code for that one). Some of the others … just depends on what they’re doing. Each one will have to individually be looked at to see how proxy support fits into their implementations.

I’m thinking about throwing together a proof of concept with IRC to have folk try it out at some point, maybe MSN as well, and then work on the others.

64

  1. I will do it when I come accross related stuffs.

  2. there’s NO reason not to use a global settings (and I add the best would be to set it in openfire, not in the plugin itself, but it is of course no as easy as it sounds for you as you may not have privileges rights over openfire sources.).

  3. you should also think about dealing with HTTP proxies. Socket connections are not the only method used nowaday for relying traffic through a proxy.

HTH !

And you’re welcomed if need me to test some jars

65

Hi Daniel,

I think you did answer the question in 2. within 3.:

  1. Can anyone think of any reason why they would want/need to give individual transports different proxy settings?
  1. Each one will have to individually be looked at to see how proxy support fits into their implementations.

So I guess that you want to start with a unique proxy support for every transport.

I assume that SOCKS or a simple TCP proxy support will be quite easy to implement while HTTP CONNECT will be much harder.

LG

66

Hi All.

I have the same scenario, A Firewall with Auth-Proxy and my server with OpenFire.

All Workstations MSN work informing Proxy and user, but how can i do this to Openfire?

I´m using Openfire in version 3.6.0 and i wnat know how can i put Java-proxy in my bin files?

this is the /etc/init.d/openfire run_cmd

OPENFIRE_RUN_CMD="${JAVACMD} -server -Dhttp.proxyHost=USER:PASS@SERVER -Dhttp.proxyPort=3128 ${OPENFIRE_OPTS} -classpath “${LOCALCLASSPATH}” -jar “${OPENFIRE_LIB}/startup.jar”"

Is this Right?

Please, Help me.