Tapestry
  1. Tapestry
  2. TAPESTRY-695

WebRequestServicerFilter lacks support for tapestry.globals.*

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 4.1.2
    • Component/s: Framework, Web
    • Labels:
      None

      Description

      problem description:

      step 1: let there be an "Authenticator" service which uses the current request (for credentials lookup)

      // ----------------------------------------------------------
      <service-point id="Authenticator">
      <invoke-factory model="threaded">
      <construct class="AuthenticatorImpl">
      <set-service property="request" service-id="tapestry.globals.WebRequest" />
      </construct>
      </invoke-factory>
      </service-point>

      // ----------------------------------------------------------
      public class AuthenticatorImpl implements Authenticator
      {
      private WebRequest request; // injected

      // setters + other stuff omitted

      public boolean isAuthenticated()

      { if(request.getSession(false) == null) return false; // more stuff comes here... }

      }
      // ----------------------------------------------------------

      step 2: now inject the authenticator into a request filter

      // ----------------------------------------------------------

      <service-point id="AuthenticationFilter" interface="org.apache.tapestry.services.WebRequestServicerFilter">
      <invoke-factory>
      <construct class="AuthenticationFilter">
      <set-service property="authenticator" service-id="Authenticator" />
      </construct>
      </invoke-factory>
      </service-point>

      <contribution configuration-id="tapestry.request.WebRequestServicerPipeline">
      <filter name="auth" object="service:AuthenticationFilter" />
      </contribution>

      // ----------------------------------------------------------

      public class AuthenticationFilter implements WebRequestServicerFilter
      {
      private Authenticator authenticator; // injected

      // setters + other stuff omitted

      public void service(WebRequest request, WebResponse response, WebRequestServicer servicer) throws IOException
      {
      if(authenticator.isAuthenticated())

      { // ***************************************************** // the above operation "isAuthenticated()" will fail !!! // request == NULL // ***************************************************** }

      }

      }

      // ----------------------------------------------------------

      Property 'webRequest' of <OuterProxy for tapestry.globals.RequestGlobals(org.apache.tapestry.services.RequestGlobals)> is null.

      this should not happen as the request is available at this time (it's a parameter of the service method)
      however, I do not want to handle the request to the authenticator as it's used not only in the filter
      but also in the login page.

      I think this is a general problem with filters being called before tapestry.globals is fully initialized

        Activity

        Hide
        Peter Ertl added a comment -

        old enough to close

        Show
        Peter Ertl added a comment - old enough to close
        Hide
        Jesse Kuhnert added a comment -

        Two people hitting it seems like enough.

        Show
        Jesse Kuhnert added a comment - Two people hitting it seems like enough.
        Hide
        Johan Maasing added a comment -

        I want to retrieve some headers from the HttpRequest put there by a proxy and store them in an ASO, surely this can not be that uncommon?
        I could either use servlet filters but then I can not easily get my ASOs. If I use WebRequestServicerFilter I run into this issue.
        I naively expected these filters to behave like servlet-filters, you can do stuff, you call the next in the chain and then you can do some more stuff. But ApplicationStateManager seems to rely on the globals being set so I can not get my ASO before the servicer.service call and if I try to get it after it is too late.

        Show
        Johan Maasing added a comment - I want to retrieve some headers from the HttpRequest put there by a proxy and store them in an ASO, surely this can not be that uncommon? I could either use servlet filters but then I can not easily get my ASOs. If I use WebRequestServicerFilter I run into this issue. I naively expected these filters to behave like servlet-filters, you can do stuff, you call the next in the chain and then you can do some more stuff. But ApplicationStateManager seems to rely on the globals being set so I can not get my ASO before the servicer.service call and if I try to get it after it is too late.
        Hide
        Ben Tomasini added a comment -

        I am having the same type of issue. I have a need to perform some logic on each and every request. Having an additional pipeline which runs after the globals are set, and before the engine, would be ideal.

        For now I will just use the workaround stated above.

        Show
        Ben Tomasini added a comment - I am having the same type of issue. I have a need to perform some logic on each and every request. Having an additional pipeline which runs after the globals are set, and before the engine, would be ideal. For now I will just use the workaround stated above.
        Hide
        Howard M. Lewis Ship added a comment -

        The reason the behavior is the way it is, is that the intent of the pipelines is that a filter may substitute a different instance of WebRequest or WebResponse. This happens in the ServletRequestServicerPipeline, for example, with multipart form submissions (a new request is provided that includes the query parameters and values from the multipart request). Therefore, the intent is that the request and response are not "final" until the terminator is reached, and it is the pipeline terminator that installs these final objects into the RequestGlobals.

        Perhaps what we need is a third pipeline, between setting the globals, and invoking the engine.

        However, between this rationale (alas, only documented here) and the evident workaround, there is no pressing need to fix this bug.

        Show
        Howard M. Lewis Ship added a comment - The reason the behavior is the way it is, is that the intent of the pipelines is that a filter may substitute a different instance of WebRequest or WebResponse. This happens in the ServletRequestServicerPipeline, for example, with multipart form submissions (a new request is provided that includes the query parameters and values from the multipart request). Therefore, the intent is that the request and response are not "final" until the terminator is reached, and it is the pipeline terminator that installs these final objects into the RequestGlobals. Perhaps what we need is a third pipeline, between setting the globals, and invoking the engine. However, between this rationale (alas, only documented here) and the evident workaround, there is no pressing need to fix this bug.
        Hide
        Howard M. Lewis Ship added a comment -

        A work around for this is to add your own filter that pushes the request and response into the RequestGlobals service. You can use before="*" to make sure it runs first.

        Show
        Howard M. Lewis Ship added a comment - A work around for this is to add your own filter that pushes the request and response into the RequestGlobals service. You can use before="*" to make sure it runs first.
        Hide
        Peter Ertl added a comment -

        why is it a problem to put the request / response in the globals as a default before filter invocation?

        image you want a function isLoggedOn in an Authenticator class (like already described) which has
        to check the request / session for the presence of a principal. as it should behave similar within a
        page or a filter it's undesirable to handle the request to it, like...

        isLoggedOn(WebRequest request) [just the way it was before dependency injection came up :-( ]

        This would mean you had to inject the request into your BasePage (or use cycle.getInfrastructure().getRequest()).
        ognl-based access within the html template is even worse, e.g. to display 'you are logged on' in your page.
        so you would really like to use RequestGlobals in your authenticator to make use of it simple
        (just inject the authenticator where you need and use it - don't worry about requests and where
        they come from).

        once I put a

        requestGlobals.store(request, response);

        into the beginning of service(...) the call of isLoggedOn() works as expected.

        having a filter chain is no problem as you could hand over the last result of RequestGlobals
        to the next filter#service(request, response, servicer)

        I am sure that way life would be simpler

        Show
        Peter Ertl added a comment - why is it a problem to put the request / response in the globals as a default before filter invocation? image you want a function isLoggedOn in an Authenticator class (like already described) which has to check the request / session for the presence of a principal. as it should behave similar within a page or a filter it's undesirable to handle the request to it, like... isLoggedOn(WebRequest request) [just the way it was before dependency injection came up :-( ] This would mean you had to inject the request into your BasePage (or use cycle.getInfrastructure().getRequest()). ognl-based access within the html template is even worse, e.g. to display 'you are logged on' in your page. so you would really like to use RequestGlobals in your authenticator to make use of it simple (just inject the authenticator where you need and use it - don't worry about requests and where they come from). once I put a requestGlobals.store(request, response); into the beginning of service(...) the call of isLoggedOn() works as expected. having a filter chain is no problem as you could hand over the last result of RequestGlobals to the next filter#service(request, response, servicer) I am sure that way life would be simpler
        Hide
        Howard M. Lewis Ship added a comment -

        What you really seem to want is a filter pipeline before the globals are set up, and one after, and then delegate out to the engine for main processing.

        The intent of the filter before the pipeline is to allow the kind of work you want to do, but base it on the parameters, not the globals. In some cases, a filter may want to substitute the HttpServletRequest or WebRequest, and this is its opportunity.

        Another option would be to make setting up the globals a filter (not a terminator) such that other filters could be scheduled before or after it.

        Show
        Howard M. Lewis Ship added a comment - What you really seem to want is a filter pipeline before the globals are set up, and one after, and then delegate out to the engine for main processing. The intent of the filter before the pipeline is to allow the kind of work you want to do, but base it on the parameters, not the globals. In some cases, a filter may want to substitute the HttpServletRequest or WebRequest, and this is its opportunity. Another option would be to make setting up the globals a filter (not a terminator) such that other filters could be scheduled before or after it.

          People

          • Assignee:
            Jesse Kuhnert
            Reporter:
            Peter Ertl
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development