On May 4, 2010, at 4:39 PM, Oleg Kalnichevski wrote:

Thanks for the help; see my responses inline below.

On Mon, 2010-05-03 at 17:37 -0400, Eric Rizzo wrote:
I'm writing a "bridge" web app that needs to accept login from
credentials from users and use HttpClient to authenticate them to
another site/service. I also need to remember the session (track it in
my app's session) so that my app can continue interactions with the
other site/service.
After reading the docs and tutorials (well, what seem like the
relevant parts), my thought is to use a single HttpClient instance and
store individual HttpContext instances with each of my user sessions.
Does that make sense, or would it be better to just use a separate
HttpClient instance per user? Or some other strategy?

Single HttpClient instance and a separate local HttpContext per user /
thread is the way to go

As for the custom authentication, I'm struggling on how to plug in
there. I don't think I can just write a CredentialsProvider, because
the credentials should not be shared in the HttpClient (which is
shared for the whole app),

You can always set a different CredentialsProvider in the local context
which will override the one set at the client level

That sounds perfect, but I can't find how to set a CredentialsProvider on HttpContext. Is there a special attribute I need to set? Looking through the online docs and various *PNames interfaces didn't reveal anything obvious to me.

Ah-hah, just found it. The HttpContext attribute I want to set is ClientContext.CREDS_PROVIDER I found this only after diving into the code of DefaultRequestDispatcher. Is there someplace that this is documented that users should find more easily?




plus I have to get the credentials from my
own app's authentication process (using aSpring
AuthenticationProvider, if anyone cares) and the CrednetialsProvider
interface does not seem to provide enough contect for me to get the
credentials at login time.


Why is that?


So, are there any example of this kind of thing or ideas for how best
to architect this? I've been unable to find any examples that seem to
apply, but am willing to do more reading or experimentation if pointed
in the right directions.


I still do see a good reason why you could not implement a custom
credentials provider and create a different instance of it on a per
user / thread basis.



Only because I don't know how to set a custom creds provider; I could make a simplistic one at login time if I can find how to set it on the context (which I know how to do, now).



---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to