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

  • reconnectfilter and scope

    So, now I have reconnectfilter basically working, I realize that I need to pass scope and store the return url. Without scope, your connect will not work. Any suggestions on how to deal with that?
    Scopes may vary, but I was thinking to define a kind of default scope in the ConnectInterceptor.preConnect. If there's no scope, then use xyz.

  • #2
    Yes, scope was one of those things I've been thinking of a bit lately, not only in this context, but in others.

    First, on the surface, a default scope for ConnectController/ProviderSignInController would be nice...Same for SocialAuthenticationFilter. But scope is a provider-defined value, so maybe a default scope at the provider-level (e.g., when configuring the connection factory) makes more sense. This same default scope could be used across the board, even for ReconnectFilter.

    I also had some additional thoughts on how ReconnectFilter might work to upgrade a connection's scope. That is, if it's determined that a certain operation can't be done without "xyz" scope, then throw an exception to that effect and let ReconnectFilter upgrade the connection to get the higher scope. This could even be declarative around a controller handler method...something like:

    Code:
    @ScopeRequired("xyz")
    @RequestMapping(...)
    public String doSomethingWithXyzScope() {...}
    Then, the call would be intercepted and dealt with by upping the scope before allowing it to proceed.

    But I've shelved some of that work for now, focusing on the reconnect scenario. I hope to revisit it again after 1.1.0 is released. That said, a default scope at the provider level is still reasonable for consideration in the 1.1.0 timeframe.

    Comment


    • #3
      It would be nice to have that kind of scope at the method level, since scope may vary across functions. However, I imagine it would be impossible to know if an existing token has the "required" scope already. But with the reconnectfilter, an authorization exception will lead to discarding the existing token and acquiring a new one, so that should be ok.

      Comment


      • #4
        Originally posted by mschipperheyn View Post
        It would be nice to have that kind of scope at the method level, since scope may vary across functions. However, I imagine it would be impossible to know if an existing token has the "required" scope already. But with the reconnectfilter, an authorization exception will lead to discarding the existing token and acquiring a new one, so that should be ok.
        Yeah. It'd be nice if there was a way to know what the scope is (actually, for some providers that's possible, but not practical to maintain) and throw the exception early. So, the next best thing is to let the code do its thing and if, in the course of making a call to FB an exception indicates that more scope is needed, and if that exception isn't otherwise handled, then attempt to upgrade the scope and then try again. It's not ideal, but it's better than nothing.

        Comment


        • #5
          So, in the end, if we can't know the existing scope, wouldn't this be effectively the same as reinitializing the connection. I'm asking because of off-line access. What if off-line access encounters a @Scope annotation, discards the existing connection and obviously can't continue because there's no user to accept the new connection?

          Comment


          • #6
            Yes, it is essentially the same as reinitializing the connection. But the difference is that if you discover the need for a higher scope while doing something offline, then you won't be operating within the bounds of a web request and therefore, there won't be a ReconnectFilter (or similar) in play to discard the existing connection. In short, the exception will just get thrown and unless something else is there to catch it and deal with it, the operation fails.

            This is a problem with Facebook and LinkedIn, especially since they don't officially support offline access or the ability to refresh an access token with a refresh token. As long as the access token is good, you can use it offline. But if the token expires and you try to use it in an offline scenario, there's really nothing you can do. Without a browser to redirect, you're stuck with an old token and no choice but to fail.

            I believe there needs to be a non-web equivalent for ReconnectFilter that uses the refresh token to update a connection. But WRT Facebook and LinkedIn, that won't matter...because there is no refresh token. For those providers (and any other that follow suit), the connection can *only* be refreshed at the web level by redirecting the browser.

            Comment


            • #7
              So, then it would be useful to have a way to capture off-line NonAuthorizedExceptions as well. Presumably, you could just discard the connection in that case.

              Comment


              • #8
                Also, I'm struggling a bit with the post connect url. I normally pass a parameter when the user clicks the connect button, since the destination depends on where in the application is clicked. So, I guess it would be nice to be able to pass a kind of context parameter to a method that may trigger a reconnect. @PostConnectContext("connections")

                Comment

                Working...
                X