Announcement Announcement Module
Collapse
No announcement yet.
Overriding OAuth2AuthorizationFilter Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Overriding OAuth2AuthorizationFilter

    Hi,

    I'm trying to override the behaviour of OAuth2AuthorizationFilter. There are a couple of posts on this subject. One post implies it's not trivial to override. The other I've tried by declaring a bean in applicationContext:

    <beans:bean id="oauth2AuthorizationFilter" class="org.springframework.security.oauth2.provide r.CustomOAuth2AuthorizationFilter">
    </beans:bean>

    but couldn't get this to pick up.

    I'm trying to model different grant types using separate paths:

    /oauth/authorize - for resource owner password grant type
    /oauth/refresh - for exchanging a refresh token for an access token.

    and I still want OAuth2AuthorizationFilter to do the work and want to avoid running two instances of the filter in the chain. If that makes sense.

    Any help would be much appreciated.

    J

  • #2
    I haven't tried it, but the bean override should work if you define that bean *after* the <oauth:provider/>. To me this seems rather brittle anyway, so I have issues with the way <oauth:provider/> is implemented. Maybe it would be better to make all the filter configuration more explicit, so you can easily see where the individual filters are and inject your customizations directly?
    Last edited by Dave Syer; Aug 1st, 2011, 09:19 AM. Reason: formatting

    Comment


    • #3
      Originally posted by Dave Syer View Post
      I haven't tried it, but the bean override should work if you define that bean *after* the <oauth:provider/>.
      Jeremy, did that work?

      Originally posted by Dave Syer View Post
      To me this seems rather brittle anyway,
      Probably true. We could make it less brittle by making that bean name explicit in the config file, but that doesn't address your other concerns...

      Originally posted by Dave Syer View Post
      so I have issues with the way <oauth:provider/> is implemented. Maybe it would be better to make all the filter configuration more explicit, so you can easily see where the individual filters are and inject your customizations directly?
      Seems reasonable to consider. Is there an issue open on this?

      Comment


      • #4
        Is there an issue open on this?
        There is now: https://jira.springsource.org/browse/SECOAUTH-97

        Comment

        Working...
        X