Proxy Support: Socks/HTTP/whatever

Description

Imported issue was from daniel:
For users behind firewalls that do not want to open ports, we need to add socks support for outgoing connection. Most IM clients support this.

Environment

None

Activity

Show:
daniel vultur
November 20, 2008, 4:13 PM

See attached file as well.

daniel vultur
November 20, 2008, 4:13 PM

See: http://www.igniterealtime.org/community/message/162734

public AbstractFlapConnection(ConnDescriptor cd, OSCARSession mainSession) {
super(cd); // Hand off to ClientFlapConn
super.setSocketFactory(new GatewaySocketFactory()); //added this line
initBaseFlapConnection();
oscarSessionRef = new WeakReference<OSCARSession>(mainSession);
}

daniel vultur
November 20, 2008, 4:12 PM

From cgravier:

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

2) 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: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)

daniel vultur
November 20, 2008, 4:12 PM

lol that wasn't meant to be a response to you, that was a note to myself

daniel vultur
November 20, 2008, 4:12 PM

Assignee

Daniel Henninger

Reporter

Daniel Henninger