Spring Security
  1. Spring Security
  2. SEC-1705

Namespace creates spurious OpenIDAuthenticationFilter bean

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 3.0.5, 3.1.0.RC1
    • Fix Version/s: 3.1.0.RC2, 3.0.6
    • Component/s: Namespace
    • Labels:
      None

      Activity

      Hide
      Luke Taylor added a comment -

      It looks like a separate bean copy is used by the DefaultLoginPageGeneratingFilter, while the one in the filter is registered as an inner bean. In practice we should probably just use a single reference.

      Show
      Luke Taylor added a comment - It looks like a separate bean copy is used by the DefaultLoginPageGeneratingFilter, while the one in the filter is registered as an inner bean. In practice we should probably just use a single reference.
      Hide
      Blaine Simpson added a comment -

      I'm calling the DefaultLoginPageGeneratingFIlter instance of OpenIDAuthenticationFilter the "PGF Openid Filter instance" for brevity below. I'm calling the main OpenIDAuthenticationFilter the "primary" one.

      I will check with the Spring Security openid sample web app if you want me to, but with my own app I know that the bean factory reveals only the PGF Openid Filter instance by the the bean factory getter methods. It is very likely that this is the case with any app using the openid* elements. Not having the primary OpenIDAuthenticationFilter available through the context/bean-factory is a serious inconvience as explained below.

      One can work with the primary OpenIDAuthenticationFilter instance with a bean post-processor, but that does not satisfy the use case where one wants to declaratively configure OpenID beyond the very limited settings allowed by the openid* configuration elements. getBean() operators are not ready for usage by bean post-processors. It would be very easy to wire with the primary OpenIDAuthenticationFilter instance if it were registered at top level in the context. My cruddy work-around is, in a bean post-processor, save off a reference to the primary OpenIDAuthenticationFilter, then in my ApplicationListener, use getBean() calls to wire declaratively-configured beans with the primary OpenIDAuthenticationFilter.

      Show
      Blaine Simpson added a comment - I'm calling the DefaultLoginPageGeneratingFIlter instance of OpenIDAuthenticationFilter the "PGF Openid Filter instance" for brevity below. I'm calling the main OpenIDAuthenticationFilter the "primary" one. I will check with the Spring Security openid sample web app if you want me to, but with my own app I know that the bean factory reveals only the PGF Openid Filter instance by the the bean factory getter methods. It is very likely that this is the case with any app using the openid* elements. Not having the primary OpenIDAuthenticationFilter available through the context/bean-factory is a serious inconvience as explained below. One can work with the primary OpenIDAuthenticationFilter instance with a bean post-processor, but that does not satisfy the use case where one wants to declaratively configure OpenID beyond the very limited settings allowed by the openid* configuration elements. getBean() operators are not ready for usage by bean post-processors. It would be very easy to wire with the primary OpenIDAuthenticationFilter instance if it were registered at top level in the context. My cruddy work-around is, in a bean post-processor, save off a reference to the primary OpenIDAuthenticationFilter, then in my ApplicationListener, use getBean() calls to wire declaratively-configured beans with the primary OpenIDAuthenticationFilter.
      Hide
      Luke Taylor added a comment -

      You shouldn't need to use gerBean(). Just get Spring to inject whatever you need into your BeanPostProcessor and then inject them into the OpenIDAuthenticationFilter in the postProcessBeforeInitialization method.

      Show
      Luke Taylor added a comment - You shouldn't need to use gerBean(). Just get Spring to inject whatever you need into your BeanPostProcessor and then inject them into the OpenIDAuthenticationFilter in the postProcessBeforeInitialization method.

        People

        • Assignee:
          Luke Taylor
          Reporter:
          Luke Taylor
        • Votes:
          0 Vote for this issue
          Watchers:
          0 Start watching this issue

          Dates

          • Created:
            Updated:
            Resolved: