Migrated from SEC-1705
Luke Taylor said:
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.
Blaine Simpson said:
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.
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.