Announcement Announcement Module
Collapse
No announcement yet.
Problem with "multi-threaded" security context Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Problem with "multi-threaded" security context

    We have a Web Services project which utilises services exposed by separately deployed application.

    The services are accessed via httpinvoker, and it works a treat.

    Authentication is achieved with

    final Authentication authentication =
    new UsernamePasswordAuthenticationToken(username, password);
    SecurityContextHolder.getContext().setAuthenticati on(authentication);


    This works with no problems.

    However within our Web Services project we have a jsp page that is used to verify that the project has deployed correctly, i.e. this is primarily for internal use though it could be used to check a deployment on a client's box.

    This verify.jsp sits in the WEB-INF root.

    verify.jsp currently attempts to access some utility services in the other application, also via httpinvoker.

    To get this working I have a simple test:

    <%
    WebApplicationContext ctx = WebApplicationContextUtils.getWebApplicationContex t(application);
    IConfigurationHelper helper = (IConfigurationHelper)ctx.getBean("configurationHe lper");
    java.lang.String something = helper.getSomething();
    %>


    "configuationHelper" is a bean declared within the Web Services application, and this also has the same authenticaton code:

    final Authentication authentication =
    new UsernamePasswordAuthenticationToken(username, password);
    SecurityContextHolder.getContext().setAuthenticati on(authentication);


    However it falls over in a heap with complaining that "authentication" is null.

    As a quick test, I used the line:

    SecurityContextHolder.setStrategyName(SecurityCont extHolder.MODE_GLOBAL);

    So this implies that there is some form of multi-threading going on. But we cannot do the above for obvious reasons - this configuation helper sits on the middle tier, i.e. it is not a client-side class and therefore the SecurityContextHolder has to be LOCAL.

    Can anyone suggest anything? Why is the same bean accessed from the JSP seemingly using a different Security Context?

    Thanks

  • #2
    I have a number of servlets defined in web.xml with different url patterns. Could it be that as the JSP path does not fit one of these patterns it is provided with a different context thread?

    Comment

    Working...
    X