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]