Announcement Announcement Module
Collapse
No announcement yet.
OAuth2 Samples do not work in 1.0.0.M6 Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • OAuth2 Samples do not work in 1.0.0.M6

    I cloned the spring-security-oauth Git repo and checked out the 1.0.0.M6 tag. I then followed the instructions for building and running the oauth2 samples. When I through the simple workflow of trying to access Sparklr pics from Tonr in the Google Chrome browser everything works except the requests for the images return a 406 error code.

    This issue was previously reported as a bug and marked Resolved, https://jira.springsource.org/browse/SECOAUTH-173.

    I am attaching the Tomcat server logs and .har files (HTTP traces) exported from Chrome Developer Tools for all 3 steps in the workflow.

    Just to clarify the steps I took:
    step1 - click on Sparklr Pics, this will redirect to Sparklr login page
    step2 - submit default username/password, this will redirect to Sparklr authorize/deny page
    step3 - click Authorize, this will redirect back to Tonr page that is supposeed to display the Sparklr pics...the page loads with 3 results but the images themselves are not downloaded due to the 406 error

    If you would like me to file a bug report I can do that but I decided to try the forum first because the other bug documenting this issue was closed and it was requested to raise it on the forum.

  • #2
    It still works for me. If you are seeing the same 406 as the JIRA poster, I think you are both unlucky. There are a couple of SPR-* issues that look relevant (https://jira.springsource.org/browse/SPR-7983, https://jira.springsource.org/browse/SPR-9138) and if you can find out any more detail about why you are seeing this problem and I am not that would be grand, but I tend to think it's not a problem with SECOAUTH per se.

    Comment


    • #3
      Originally posted by Dave Syer View Post
      It still works for me. If you are seeing the same 406 as the JIRA poster, I think you are both unlucky. There are a couple of SPR-* issues that look relevant (https://jira.springsource.org/browse/SPR-7983, https://jira.springsource.org/browse/SPR-9138) and if you can find out any more detail about why you are seeing this problem and I am not that would be grand, but I tend to think it's not a problem with SECOAUTH per se.
      I also can't get the samples to work properly. I downloaded M6 source built the whole thing from scratch and launched the samples/oauth2/tonr app via mvn tomcat:run. Went to http://localhost:8080/tonr2. Went to "Facebook Friends" @ URL http://localhost:8080/tonr2/facebook/info and was redirected to Facebook where I logged in and accepted. Facebook redirects back and the app does another redirect to http://localhost:8080/tonr2/facebook/index.jsp which doesn't exist(after scouring through all the code I'm not sure why it would redirect to /facebook/index.jsp) . So I modify your code to try and create a mapping rule for index.jsp to show the friends and the app just goes into an endless redirect loop.

      Any ideas what's going on here?

      Comment


      • #4
        That's an entirely unrelated problem. I must admit I don't try the facebook demo very often and it does seem to be broken at the moment - I think it is Facebook sending that index.jsp link, and it used to work, so that probably changed on their side. I'll have a look when I get a minute (raise a JIRA if you want to know the outcome). The Sparklr pictures link works though so for a demo that should be fine.

        Update: Facebook is (completely unaccountably) sending the token in the wrong format (form encoded instead of JSON,https://jira.springsource.org/browse/SECOAUTH-209), so the problem is actually an access denied error that isn't being handled very nicely in tonr2 (https://jira.springsource.org/browse/SECOAUTH-208).
        Last edited by Dave Syer; Feb 27th, 2012, 02:53 AM.

        Comment


        • #5
          I was about to open a JIRA but I see from your update that you have taken care of it. Thanks for your efforts on this. I noticed in the JIRA that you said " I don't really know what to make of that, and it's not clear that we should support that kind of thing in Spring Security OAuth (Spring Social seems like a better place)." Doesn't Spring Social use Spring OAuth to authenticate against facebook? I'm trying to figure out what the relationship is between the two projects. I'm under the impression that Spring Social doesn't integrate with Spring Security. So if you wanted Facebook integration with spring security how would Spring Social help?

          Comment


          • #6
            I am seeing the same problem as the OP, as described in excruciating detail with accompanying log files in this thread. That said, however, the Facebook integration is working just fine. This leads me to believe that the problem with the integration between tonr2 and sparklr2 is in the sparklr2 configuration, not the tonr2 configuration.

            Comment


            • #7
              And I was completely wrong. The problem is (sort of) with the tonr2 configuration. Or more correctly the problem is with one of the classes referenced by the tonr2 configuration. This is a known issue in the Spring Framework when the accepted media types are set to all, i.e. */*. When this happens, the configured BufferedImageHttpMessageConverter has a method called isWritable() that returns false, apparently since it doesn't recognize that particular type (really the fault comes at the level of the ImageIO.getImageWritersByMIMEType() call, which returns an empty list of image writers for that media type, but that makes sense because it can't return a specific writer for that MIME type). This problem is described in a fairly detailed and now fairly old bug report on the Spring Framework JIRA.

              Now this gets to the root of the problem, which is the HTTP Accept header. This hadn't even occurred to me, but the REAL issue here is the interaction of this relatively minor bug and the Chrome browser. Here's the Accept header for Chrome:

              Code:
              Accept:*/*
              Here's the Accept header for Opera, which works just fine:

              Code:
              Accept: text/html, application/xml;q=0.9, application/xhtml+xml, image/png, image/webp, image/jpeg, image/gif, image/x-xbitmap, */*;q=0.1
              For a workable fix, see the EnhancedBufferedImageHttpMessageConverter implementation suggested by Shawn Clark. That's working for me right now. It'd be nice to see this addressed in the core framework, however.

              Comment

              Working...
              X