CallerIdentityLoginModule: where get credentials?

[yuriyg]

Login module works. But it's not the case when we create stateful or stateless (I tried both) on one Struts page and then try to call something at different page. What's we get here is null credentials in the second call.

(
org.jboss.resource.JBossResourceException: Could not create connection; - nested throwable: (java.sql.SQLException: Null user or password not supported in THIN driver)
)

But don't say you should keep connection: WrappedConnection in Jboss is not serializable itself. So, seems it couldn't be healed?

[starksm64]

The credentials come from the calling components security context. Describe the call sequence in detail if you want help in drilling down into what is going on. You can create a bug report on sourceforge if you have an example you think that should be working:

http://sourceforge.net/tracker/?group_id=22866&atid=376685

[yuriyg]

I created a bug report.

https://sourceforge.net/tracker/index.php?func=detail&aid=1028029&group_id=22866&atid=376685

I don't think there's more details. Just the same method works from the first web page and don't work from the second one. Nothing specific at these pages. Just calls.

[yuriyg]

Hmm... So, if I understood you correctly (and actually I tried it and it works) I should set LoginContext at each web page? Then question is why? It's not quite obvious, you know, a ejbean used login context the first time and then I use the same bean but context could be different? It's a great overhead flexibility or there is a reason behind that?

[starksm64]

Why should an arbitrary LoginContext done in one thread of a web application subsequently affect all other pages in the web app? If that is what you want, use the container's declarative security model to establish the security context that will be used for the servlet and any secured resources access as part of the servlet implementation. Ues of the the LoginContext to do this is a fine grained, request specific mechanism.