XMLRPC, GroovyWS with cookies and auth

[Steve Tekell]

How do you add cookies or request headers to clients being used for XMLRPC and GroovyWS?
I am currently trying to delegate an existing cookie for a JOSSO secured webapp.

For XMLRPC, I see how I might hack my own version of XMLRPCServerProxy, but it'd be nice if there was some sort of hooks for doing this.  If either I could pass in my own HttpClient (apache) or set of cookies or have a hook to do stuff with the connection before the request is sent, then I could avoid replacing the entire invokeMethod and more.  

Any chance future versions of GroovyXMLRPC would use something like the apache HttpClient instead of URLConnection, so state like cookies could be maintained over a series of requests?

With GroovyWS, I am not sure how to even hack support.  Is there some client somewhere I can get ahold of and add cookies to?

What will these Groovy modules support in the future for authentication?
I hope to get away from JOSSO, but I'll be needed to delegate credentials, like a kerberos ticket.
What methods for credential authentication and non username/password based authentication will be supported?

BTW you should allow username and password to be set per client rather than using system properties as it is in WSClient.    Like that, every service has to use the same account.

thx,

Steve

[tugwilson]

Steve Tekell wrote:

How do you add cookies or request headers to clients being used for XMLRPC and GroovyWS?
I am currently trying to delegate an existing cookie for a JOSSO secured webapp.

For XMLRPC, I see how I might hack my own version of XMLRPCServerProxy, but it'd be nice if there was some sort of hooks for doing this.  If either I could pass in my own HttpClient (apache) or set of cookies or have a hook to do stuff with the connection before the request is sent, then I could avoid replacing the entire invokeMethod and more.  

Any chance future versions of GroovyXMLRPC would use something like the apache HttpClient instead of URLConnection, so state like cookies could be maintained over a series of requests?

With GroovyWS, I am not sure how to even hack support.  Is there some client somewhere I can get ahold of and add cookies to?

What will these Groovy modules support in the future for authentication?
I hope to get away from JOSSO, but I'll be needed to delegate credentials, like a kerberos ticket.
What methods for credential authentication and non username/password based authentication will be supported?

BTW you should allow username and password to be set per client rather than using system properties as it is in WSClient.    Like that, every service has to use the same account.

Hi Steve!

I can only speak for XML-RPC.

The XML-RPC spec is for a very simple protocol. Arguably it explicitly precludes cookie support (I have been the moderator of the XML-RPC mailing list for many years and this discussion comes up now and again - this seems to be the consensus).

My position is that XML-RPC should be as simple as possible so I have no plans to support cookies ever. If  you would like to subclass XMLRPCServerProxy or take some other route to produce an implementation which does support cookies I'd be happy to give you advice and change XMLRPCServerProxy to make life easier for you (actually, replacing XMLRPCServerProxy would probably be your best bet - the message processing [which is the tricky bit] is packaged up as as separate class).

John Wilson

[Steve Tekell]

tugwilson wrote:

be happy to give you advice and change XMLRPCServerProxy to make life easier for you

The only thing I need to do is add this:
connection.setRequestProperty("Cookie", "JOSSO_SESSIONID=" + jossoSessionId);

The problem is I don't know of a good way to do this since the connection is buried in invokeMethod.  So I end up with an alternative version XMLRPCServerProxy that will require maintenance with every upgrade.  Which I did and it works, but,....

Any small change you'd be willing to make to XMLRPCServerProxy to make some cleaner way to do this would be appreciated.  Maybe if (connection was property and) there was a getConnection method that just returned this.serverURL.openConnection, then I could override just that.  Or maybe it'd be more Groovy to accept a closure in a constructor { connection -> doSomethingWithConnectionBeforeRequest }.  Any hook you provide to execute something like connection.setRequestProperty would allow those of us who need cookies to implement it in a better way.

thx,

Steve

[tugwilson]

Steve Tekell wrote:

tugwilson wrote:

be happy to give you advice and change XMLRPCServerProxy to make life easier for you

The only thing I need to do is add this:
connection.setRequestProperty("Cookie", "JOSSO_SESSIONID=" + jossoSessionId);

The problem is I don't know of a good way to do this since the connection is buried in invokeMethod.  So I end up with an alternative version XMLRPCServerProxy that will require maintenance with every upgrade.  Which I did and it works, but,....

Any small change you'd be willing to make to XMLRPCServerProxy to make some cleaner way to do this would be appreciated.  Maybe if (connection was property and) there was a getConnection method that just returned this.serverURL.openConnection, then I could override just that.  Or maybe it'd be more Groovy to accept a closure in a constructor { connection -> doSomethingWithConnectionBeforeRequest }.  Any hook you provide to execute something like connection.setRequestProperty would allow those of us who need cookies to implement it in a better way.

Ok, I'll take a look and see what can be done.

  John Wilson

[tugwilson]

How about this http://rifers.org/paste/show/6985

You subclass and override doRpcCall()


If this is OK can you please raise a JIRA request for this change so we can keep track of why we made the change

John Wilson

[Steve Tekell]

tugwilson wrote:

How about this http://rifers.org/paste/show/6985

You subclass and override doRpcCall()

Looks Great!
here's the JIRA issue
http://jira.codehaus.org/browse/GROOVY-2707

At first I thought it was sort of more than I needed, but now I think may replace the URLConnection with the common's HttpClient in doRpcCall(), rather than just add in my cookie.  If I passed one in a constructor, I could use the same initialized httpClient for several different XmlRpc proxys that I was already using for non XmlRpc GETs in the same action.  That's makes it even better.

That could also be the basis for the solution the http://jira.codehaus.org/browse/GROOVY-1426.  HttpClient supports basic and some other types of authentication.

Now if only I could pass a HttpClient in like that to a WSClient.

thx,

Steve

[tugwilson]

Ok,

that's done now.

Please try it out and close the issue if everything is OK.

John Wilson