mulesoft / facebook-connector

Facebook Cloud Connector
Other
4 stars 9 forks source link

facebook:authorize should stop further processing #14

Closed ddossot closed 12 years ago

ddossot commented 12 years ago

Currently a typical usage of facebook:authorize is to create a flow that does basically nothing but checking the current auth status and issuing a 302 if needed:

<flow name="oauth2Dance">
    <http:inbound-endpoint host="localhost" port="${http.port}"
        path="api/connect" />
    <facebook:authorize />
</flow>

It's also possible to use facebook:authorize as a security filter in flows that do more stuff but then using control logic (choice/filter...) after it is necessary to prevent going any further if a 302 has been issued:

<flow name="selfProfile">
    <http:inbound-endpoint host="localhost" port="${http.port}"
        path="api/me" exchange-pattern="request-response" />
    <facebook:authorize />
    <choice>
        <when evaluator="header" expression="http.status=302">
            <logger />
        </when>
        <otherwise>
            <facebook:logged-user-details />
                            ...
        </otherwise>
    </choice>
</flow>

This is not only cumbersome at config level, it couples the downstream routing logic to the particulars of facebook:authorize (ie returns 302 -> stop here).

It would be nice if facebook:authorize could simply stop further processing of the flow, leading to an early return of the 302 and removing the need for control logic after it.

marianogonzalez commented 12 years ago

David,

Although it is possible to use the authorize method in the way you suggest, it is not how it is intended to work and how it should actually we used.

The only purpose of the authorize method is to execute the OAuth dance. Nothing more, nothing less. It is not for checking the state of the authentication and it is not for acting as a security filter, specially after the changes introduced in devkit 3.3.1.

You don't need to perform any of these filters or checks since the connector will automatically store the user's token in an object store which you can query to verify if the user is authenticated or not.

Also, if your application requires post authentication processing you can config the authorize operation to be synchronic, meaning that after the OAuth dance is completed the invoking flow recovers control and you can flag the user as authenticated.

But in general, calling authorize on every single operation is not only unnecessary but potentially a bad practice depending on the service provider. For example, in Google's case, that will cause you to loose your refresh token.

Please let me know if you have further questions.

Best regards,