Geronimo
  1. Geronimo
  2. GERONIMO-4119

request.isUserInRole("some-role") always return false after @EJB injection

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Blocker Blocker
    • Resolution: Fixed
    • Affects Version/s: 2.0, 2.0.1, 2.0.2, 2.1, 2.1.1
    • Fix Version/s: 2.0.3, 2.1.2, 2.2
    • Component/s: OpenEJB, Tomcat, web
    • Security Level: public (Regular issues)
    • Labels:
      None
    • Environment:

      Geronimo 2.0.2 running on Debian Etch with Java 1.5.0_14

      Description

      Se mailing list discussion: http://www.nabble.com/request.isUserInRole%28%22some-role%22%29-always-return-false-after-%40EJB-injection-td17862975s134.html

      To recreate the malfunction you need to do the following:

      1.Create an EAR with a local session bean and a war

      2. Use the default console security realm (geronimo-admin) for protecting the

      {context-path}/protected/* area
      Create a new group named "partnergroup" and add the "system" user to it. Map the "partnergroup" to the partners role in deployment descriptor (geronimo-web.xml)

      3. Create a simple but form protected(j_security_check) jsp page ex: {context-path}

      /protected/test.jsp.

      /protected/test.jsp
      <%@page contentType="text/html" pageEncoding="UTF-8"%>
      <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
         "http://www.w3.org/TR/html4/loose.dtd">
      
      <html>
          <head>
              <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
              <title>JSP Test</title>
          </head>
          <body>
              <h2>Role test</h2>
              <%if(request.isUserInRole("partners")){%>
                  user is partner :)
              <%}else{%>
                  user is NOT partner :(
              <%}%>
          </body>
      </html>
      
      

      4. Create s simple Session Bean (EJB) with a simple local method:

      TimeUtilsBean.java
      @Stateless
      public class TimeUtilsBean implements TimeUtilsLocal {
      
          public String getString() {
              return "Hello from Stateless EJB!";
          }
       
      }
      
      

      5. Create a simple but form protected(j_security_check) Servlet that uses the local EJB (ex:

      {context-path}/protected/info)
      /protected/Info.java
      import java.io.*;
      import java.net.*;
      
      import javax.ejb.EJB;
      import javax.servlet.*;
      import javax.servlet.http.*;
      import javax.naming.*;
      import javax.annotation.security.*;
      
      import no.nimra.geronimo.test.TimeUtilsLocal;
      import no.nimra.nis.admin.ejb.*;
      
      @DeclareRoles({"administrators", "partners", "users"})
      public class Info extends HttpServlet {
          @EJB
          private TimeUtilsLocal timeUtilsBean;
      
          
          
          protected void processRequest(HttpServletRequest request, HttpServletResponse response)
                  throws ServletException, IOException {
              response.setContentType("text/html;charset=UTF-8");
              PrintWriter out = response.getWriter();
      
              out.println("SessionID: " + request.getRequestedSessionId());
              System.out.println("Principal: " + request.getUserPrincipal().getName());
      
              if (request.isUserInRole("partners")) {
                  System.out.println("User has partners-role...");
                  out.println("User has partners-role...");
              } else {
                  System.out.println("User has NOT partners-role...");
                  out.println("User has NOT partners-role...");
              }
      
              try {
                  out.println("<html>");
                  out.println("<head>");
                  out.println("<title>Servlet Info</title>");
                  out.println("</head>");
                  out.println("<body>");
                  out.println("<h1> " + request.getContextPath() + "</h1>");
                  if (request.getUserPrincipal() != null) {
                      out.println("Principal: " + request.getUserPrincipal().getName());
                  }
                  out.println(timeUtilsBean.getString());
                  out.println("</body>");
                  out.println("</html>");
      
      
              } finally {
                  out.close();
              }
          }
      
          protected void doGet(HttpServletRequest request, HttpServletResponse response)
                  throws ServletException, IOException {
              processRequest(request, response);
          }
      
          protected void doPost(HttpServletRequest request, HttpServletResponse response)
                  throws ServletException, IOException {
              processRequest(request, response);
          }
      
      }
      



      Description:

      Access http://{context-path}

      /protected/test.jsp. After successfull login you will se that your login has "partners" role. As expected.
      If you access the servlet at http://

      {context-path}

      /protected/info you will notice that you do not have the "partners" role.
      If you remove the @EJB injection it behaves as expected.

        Activity

        Hide
        Stig Even Larsen added a comment -

        In the 2.0.3 SNAPSHOT of 20080616 the malfunction is partially fixed.
        After first login (first login after
        deployment) the request.isUserInRole(xxx) returns false. If a reload the
        page (eg. calling the servlet again) it returns true. If I then
        invalidate the session and login in again it returns true (it behaves
        normally).

        Show
        Stig Even Larsen added a comment - In the 2.0.3 SNAPSHOT of 20080616 the malfunction is partially fixed. After first login (first login after deployment) the request.isUserInRole(xxx) returns false. If a reload the page (eg. calling the servlet again) it returns true. If I then invalidate the session and login in again it returns true (it behaves normally).
        Hide
        Stig Even Larsen added a comment -

        After more testing the 2.0.2 release also behaves as 2.0.3 SNAPSHOT of 20080616 with regards to the above comment (return correct after reload of servlet, but not the initial calling)

        Show
        Stig Even Larsen added a comment - After more testing the 2.0.2 release also behaves as 2.0.3 SNAPSHOT of 20080616 with regards to the above comment (return correct after reload of servlet, but not the initial calling)
        Hide
        David Jencks added a comment -

        This is caused by the geronimo-openejb ThreadContextListener not tracking the ContextID from the caller nor resetting it on exit. what's going on is:

        1. request to servlet starts, has resource/data permissions checked.
        2. initial request then creates servlet. This results in evaluating injections and looking up the injected ejb
        3. entering openejb code to create the ejb sets the contextID to the ejb apps ContextID
        4. ejb stuff initialized
        5 (missing) web app ContextID should be reset on exit
        6. Now that servlet is created, the service methods are called
        7. The web role ref permission is checked against the current ContextID which is for the ejb app – so it fails.

        After the first request, the servlet has already been created so the role-ref is checked against the correct contextID. However if you checked the role-ref AFTER calling the ejb you'd run into the same problem.

        Show
        David Jencks added a comment - This is caused by the geronimo-openejb ThreadContextListener not tracking the ContextID from the caller nor resetting it on exit. what's going on is: 1. request to servlet starts, has resource/data permissions checked. 2. initial request then creates servlet. This results in evaluating injections and looking up the injected ejb 3. entering openejb code to create the ejb sets the contextID to the ejb apps ContextID 4. ejb stuff initialized 5 (missing) web app ContextID should be reset on exit 6. Now that servlet is created, the service methods are called 7. The web role ref permission is checked against the current ContextID which is for the ejb app – so it fails. After the first request, the servlet has already been created so the role-ref is checked against the correct contextID. However if you checked the role-ref AFTER calling the ejb you'd run into the same problem.
        Hide
        David Jencks added a comment -

        Problem in all 2.x geronimo versions.

        Show
        David Jencks added a comment - Problem in all 2.x geronimo versions.
        Hide
        David Jencks added a comment -

        Fixed in trunk in rev 668765. I'll port to other branches after I see about a test case.

        BTW this specific problem of the injection causing the wrong ContextID is not likely to be a problem on jetty since there we create all the servlets up front before any requests are encountered. However checking a role-ref after calling an ejb would still see the problem.

        Show
        David Jencks added a comment - Fixed in trunk in rev 668765. I'll port to other branches after I see about a test case. BTW this specific problem of the injection causing the wrong ContextID is not likely to be a problem on jetty since there we create all the servlets up front before any requests are encountered. However checking a role-ref after calling an ejb would still see the problem.
        Hide
        David Jencks added a comment -

        Fix ported to branches/2.0 in rev 668812.

        Show
        David Jencks added a comment - Fix ported to branches/2.0 in rev 668812.
        Hide
        David Jencks added a comment -

        tests trunk rev 668856
        fix branches/2.1 rev 668858
        testsuite has changed a lot, didn't backport tests to 2.1

        Show
        David Jencks added a comment - tests trunk rev 668856 fix branches/2.1 rev 668858 testsuite has changed a lot, didn't backport tests to 2.1
        Hide
        Joe Bohn added a comment -

        added fix version of 2.0.3 in addition to others

        Show
        Joe Bohn added a comment - added fix version of 2.0.3 in addition to others

          People

          • Assignee:
            David Jencks
            Reporter:
            Stig Even Larsen
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development