Announcement Announcement Module
Collapse
No announcement yet.
App url in ConnectControllerConfig Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • App url in ConnectControllerConfig

    Earlier i could specify app url, now i cannot do that. The problem is that i have an extra element in my url so after connecting to facebook or twitter i am returned to the wrong url resulting 404 error (I do end up connecting but i get an error page). Here is how my base url looks: http://ec2.instance.com:8080/appname/appname.

    Is there something i could do about this?

    Let me know thanks

    Pratap

  • #2
    There is an applicationUrl property on ConnectController and ProviderSignInController. See the JavaDocs for the setter of that property as well as the reference manual for more information.

    Comment


    • #3
      Well, even after setting the applicationUrl , i am getting redirected to the wrong url. This is what i found in the connectcontroller in git:

      private RedirectView connectionStatusRedirect(String providerId) {
      return new RedirectView(getControllerPath() + "/" + providerId, true);
      }

      private String getControllerPath() {
      return "/connect";
      }

      I think, the getControllerPath() should include the applicationUrl if it is set. (This thing was working fine a few days back)

      Also thanks a ton for the quick reply.

      Comment


      • #4
        Good catch. This is a known issue: https://jira.springsource.org/browse/SOCIAL-195. Unfortunately, /connect is currently hardcoded. This was done to fix a bug with relative redirects--specifically the DELETE /{providerId}/{providerUserId} operation was failing when attempting to remove a connection. We'll look into this promptly and look to get a nightly build out with SOCIAL-195 resolved.

        Keith

        Comment


        • #5
          Just to clarify: are you talking about the OAuth callbackUrl or the connection status URLs? The application.url property is only used, if set, when generating an oauth callback URL. This is the URL passed to Facebook/Twitter that they redirect the user back to post authorization. In general, setting the application.url property shouldn't be required for such a oauth callbackUrl (or redirectUri) to be generated correctly (I would only expect issues in proxied environments where the proxy isn't configured correctly).

          OTOH, the connection status redirects are performed internally after completing a connection when processing a callback or disconnecting when processing a delete form submission. This is where /connect is currently hard-coded and what SOCIAL-195 is all about. I just want to make sure this is the cause of your problem (it sounds like it is).

          Keith

          Comment


          • #6
            I am talking about: OAuth callbackUrl. I guess i was looking at something else.
            Last edited by ppnyc; Jun 24th, 2011, 02:53 PM.

            Comment


            • #7
              Below is the code for getting the callbackUrl in ConnectSupport. My root url looks something like : http://ec2.instance.com:8080/appname/appname . Looking at the below code it looks like you will ignore /appname/appname part of the url. At present after connecting to twitter i am getting redirected to: http://ec2.instance.com:8080/appname...auth=somestuff

              private String callbackUrl(NativeWebRequest request) {
              HttpServletRequest nativeRequest = request.getNativeRequest(HttpServletRequest.class) ;
              if (applicationUrl != null) {
              return applicationUrl.getProtocol() + "://" + applicationUrl.getHost() + portPart() + nativeRequest.getRequestURI();
              } else {
              return nativeRequest.getRequestURL().toString();
              }
              }

              Comment


              • #8
                You're right, I can see how that would be a problem. I've created https://jira.springsource.org/browse/SOCIAL-200 to track this and will start looking into it right away.

                Comment


                • #9
                  I've just pushed a new snapshot build which contains what I believe will fix your problem. Could you try it out and let me know if it works for you?

                  I'm also still curious what causes the extra path element in your application's base URL? Is this a matter of running Tomcat behind Apache Web Server or some such thing? Also wondering what the callback URL looks like if you don't set the application URL.

                  Comment


                  • #10
                    Hey Guys, the above problem seems to be have come back again. Could you please look into this and fix it? (I am using the

                    Again the problem is something like this:

                    When i connect fb/twitter account i am taken to the authorization page but when it return, it returns to http://www.xyz.com/connect/twitter instead of http://www.xyz.com/appname/

                    In my web.xml i have this:

                    <servlet-mapping>
                    <servlet-name>spring</servlet-name>
                    <url-pattern>/appname/*</url-pattern>
                    </servlet-mapping>

                    BTW i use the daily build (also the same problem exists in rc2). The problem is only after the oauth happens and it tries to redirect to the /connect/providerid page.

                    This is the suspect code (/connect/)

                    protected RedirectView connectionStatusRedirect(String providerId) {
                    return new RedirectView("/connect/" + providerId, true);
                    }



                    Thanks
                    Last edited by ppnyc; Aug 23rd, 2011, 05:06 AM.

                    Comment


                    • #11
                      I have solved the problem by subclassing connectcontroller

                      Comment


                      • #12
                        Good to hear that you've found a solution. I was going to suggest that you subclass to fix it. What did you override?

                        But I am wondering if the problem was ever fixed for you? The last thing I see on this is from the end of June. I pushed a change at that time, but never got confirmation that it worked for you. I suspect it didn't because that same bit of code hasn't changed since then.

                        Comment

                        Working...
                        X