Announcement Announcement Module
Collapse
No announcement yet.
how to set openid realm Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    Originally posted by blaine View Post
    As I just said, this is the Spring Security openid sample application. Specifically it is the sample application built from tip of master branch about 1 week ago. I can update and rebuild in the unlikely case that there have been recent code changes. Here is the config, exactly as I pulled it from your own repository:
    Perhaps I have a bit of tunnel vision, but I was still trying to focus on the thread topic of how to set an openid realm. It sounded like you were trying to specify the realm but running into problems. I was merely trying to figure out what you were doing and what was happening.

    Cheers,

    Comment


    • #17
      Originally posted by blaine View Post
      Useful feedback. Thanks.

      In my own app, I applied the realm setter on the OpenIDAuthenticationFilter that is retreived by a getBean on the bean factory, and that is not the one that does the actual filtering (this is verified by runtime logs)-- hence lack of effect of my setter. This indicates to me that the non-functioning Filter is registered in the bean factory at least at one point in time. Since my code only retrieves the filter from the bean factory, it is impossible that I could apply my setter to the non-functional bean unless this non-functional bean is registered in the bean factory.

      But since you say that the Filter may be recreated, I hope to avoid the issue altogether by using a more declarative approach to applying the setter. This is what I wanted to do originally, and now with the great tips I've received here recently on other threads, I hope to succeed that way now.
      If you copy the BeanPostProcessor pattern from the FAQ, that should do the trick:

      Code:
          public Object postProcessBeforeInitialization(Object bean, String beanName) throws BeansException {
              if (bean instanceof OpenIDAuthenticationFilter) {
                  // Whatever...
              }
      
              return bean;
          }
      
          public Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException {
              return bean;
          }

      It looks like a separate bean definition is used by the automatic login page generation from the one that is actually stored in the filter chain, but since this is a throwaway copy, it shouldn't really matter in practice.

      Comment


      • #18
        Originally posted by Luke Taylor View Post
        Hmm. I was initially skeptical about this, but it seems there may be a bug where the BeanDefinition is accidentally being reused. However, if you are using a BeanPostProcessor, it should still be applied to both instances. So I'm not sure why this should cause a problem...
        I wasn't using a BeanPostProcessor. Just for my prototyping, I wanted to be able to examine state before and after calling the realm setter, so I drove the setter with a Servlet that I can invoke on demand. It does a getBean directly on the Spring context. If I were confident that it would work, and if I knew how to customize openid declaratively (beyond what the openid namespace allows) at the time, I would have stuck with declarative.

        Comment


        • #19
          Originally posted by blaine View Post
          I am not asking irrelevant questions.
          I'm not trying to insinuate that you are. I was just having a bit of trouble switching contexts. Please realize that I am trying to help, but it is difficult when things are not in front of me.

          Originally posted by blaine View Post
          Here is the config, exactly as I pulled it from your own repository:
          ...
          My openid realm setting is being ignored because the setter is being executed against what is likely a OpenIDAuthenticationFilter instance mistakenly being created by the Spring Security framework. This is the root cause for the problem that is the subject of this thread.
          If you would like me to help please submit your configuration, any custom code you have written (i.e. where you are calling the setter), what you are doing, what you expect to happen, and what actually happens. If any stack traces are produced, then please provide these as well.

          I went ahead and set the realm based off of commit 79e17e22bc (i.e. just prior to the fix for SEC-1705 being pushed). The result of this was that some OPs display the realm when requesting login despite there being two OpenIDAuthenticationFilter's. This is not to say that having two OpenIDAuthenticationFilter's isn't a problem, just that I believe it does not prohibit the realm from being specified. One thing to note is that some OPs only display the host despite what the realm is specified as. A way to test that the realm is being sent would be to change the realm to be http://evil.com/ and seeing that you get an error when you try to request login.

          Regards,

          Comment


          • #20
            Originally posted by rwinch View Post
            ...
            I went ahead and set the realm based off of commit 79e17e22bc (i.e. just prior to the fix for SEC-1705 being pushed). The result of this was that some OPs display the realm when requesting login despite there being two OpenIDAuthenticationFilter's. This is not to say that having two OpenIDAuthenticationFilter's isn't a problem, just that I believe it does not prohibit the realm from being specified.
            You are wrong. I am positive that this is exactly my problem. Besides the obvious fact that applying an instance method setter on Filter instance X is not going to effect instance state of instance Y, I have just now spent another 20 minutes by adding a toggle which proves that the realm is changed when I use the setter on the correct Filter instance, and the realm is not changed when I use the setter on the wrong Filter.

            Originally posted by rwinch View Post
            One thing to note is that some OPs only display the host despite what the realm is specified as. A way to test that the realm is being sent would be to change the realm to be http://evil.com/ and seeing that you get an error when you try to request login.
            Done and confirmed that setting http://evil.com has absolutely no effect in my original program. This exercise was unnecessary since I have logging statements in place and know the exact value of the realMapping instance fields.

            Originally posted by rwinch View Post
            If you would like me to help please submit your configuration, any custom code you have written (i.e. where you are calling the setter), what you are doing, what you expect to happen, and what actually happens. If any stack traces are produced, then please provide these as well.
            I have not sent these details because it appeared that these settings have nothing at all to do with the problem, and I am now certain that I was correct. I didn't want to waste your time analyzing entirely irrelevant details, and I would myself rather be addressing the real problem. It turns out that I have described every relevant detail in this thread, and I simplified problem analysis by proving that the extra-FIlter-instance problem exists with the Spring Security openid sample app. My problem with setting the realm mapping is completely fixed now, and the diagnosis didn't require knowing any detail that I have not presented.
            Originally posted by rwinch View Post
            Regards,

            Comment


            • #21
              While I'm confused why it worked for me and not you, I'm glad you figured it out.

              Comment


              • #22
                Thanks to all the SS gurus for helping me extract this thorn, and giving lots of generally useful tips along the way.

                Comment

                Working...
                X