Uploaded image for project: 'Spring Web Services'
  1. Spring Web Services
  2. SWS-450

XwsSecurityInterceptor always requires a callback handler

    Details

    • Type: Improvement
    • Status: Closed
    • Priority: Minor
    • Resolution: Won't Fix
    • Affects Version/s: 1.5.5
    • Fix Version/s: 1.5.6
    • Component/s: Security
    • Labels:
      None

      Description

      When using XwsSecurityInterceptor in the client side and using UsernameToken profile it's good to not require any callbackHandlers.

      See:
      http://forum.springframework.org/showthread.php?p=214381

      1. SWS-450.patch
        0.9 kB
        Tareq Abedrabbo

        Activity

        Hide
        tareq Tareq Abedrabbo added a comment -

        Removing the assert statement relegates the validation to XWSS, which results in a nasty NPE if a callback handler is required but not assigned. Unfortunately, there doesn't seem to be a better solution.

        Show
        tareq Tareq Abedrabbo added a comment - Removing the assert statement relegates the validation to XWSS, which results in a nasty NPE if a callback handler is required but not assigned. Unfortunately, there doesn't seem to be a better solution.
        Hide
        michelz Michel Zanini added a comment -

        Another option is create a boolean property to set if the interceptor will be used in the client with token profile. But I think it isn't a good solution. Maybe we have to close the issue and keep as it is.

        Show
        michelz Michel Zanini added a comment - Another option is create a boolean property to set if the interceptor will be used in the client with token profile. But I think it isn't a good solution. Maybe we have to close the issue and keep as it is.
        Hide
        tareq Tareq Abedrabbo added a comment -

        What I meant is that we can't do better than removing the assertion. Ideally, XWSS would validate its configuration and would throw sensible exceptions in case of error, which doesn't seem to be the case. There doesn't seem to be a simple way to interrogate XWSS about the loaded configuration either.

        Show
        tareq Tareq Abedrabbo added a comment - What I meant is that we can't do better than removing the assertion. Ideally, XWSS would validate its configuration and would throw sensible exceptions in case of error, which doesn't seem to be the case. There doesn't seem to be a simple way to interrogate XWSS about the loaded configuration either.
        Hide
        arjen.poutsma Arjen Poutsma added a comment -

        I think it's a best practice to configure xwss in Spring config as much as possible. For instance, you can use the SimpleUsernamePasswordCallbackHandler as opposed to supplying the credentials inline.

        Secondly, XWSS does not do a proper configuration check before initializing. So if we'd drop the callbackHandler check, most people will end up with nasty NPEs, which are harder to debug then assertion failures. Even though these failures are not 100% correct, as you pointed out.

        Show
        arjen.poutsma Arjen Poutsma added a comment - I think it's a best practice to configure xwss in Spring config as much as possible. For instance, you can use the SimpleUsernamePasswordCallbackHandler as opposed to supplying the credentials inline. Secondly, XWSS does not do a proper configuration check before initializing. So if we'd drop the callbackHandler check, most people will end up with nasty NPEs, which are harder to debug then assertion failures. Even though these failures are not 100% correct, as you pointed out.
        Hide
        arjen.poutsma Arjen Poutsma added a comment -

        Closing old issues

        Show
        arjen.poutsma Arjen Poutsma added a comment - Closing old issues

          People

          • Assignee:
            tareq Tareq Abedrabbo
            Reporter:
            michelz Michel Zanini
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: