The transactionLoader middleware constructs the req.oauth2 object on which oauth2orize operates during processing of an authorization request. It does so by appealing to a transaction storage callback, which can be used to dynamically load the state to be placed into the req.oauth2 object.
Although this is generally quite robust, it has an issue in that only a single transaction loader callback may be configured. Particularly for some of the extensions onto the OAuth 2.0 specification (such as the device code flow), transaction loading may be sufficiently different that it is tricky for the restricted callback to properly handle all cases. Although some changes could be made to allow e.g., multiple callback handlers or more extensive function definitions, these changes would introduce complexity and not completely alleviate the issue. Therefore, this PR allows the user to overwrite the entire transactionLoader with one of their own design, to either enhance the callback function definition, or provide multiple methods of loading the transaction within the same server. This way we don't change the API for users who want the most simple of implementations, but allow complete power to changes the transaction loading model if necessary or desired.
Coverage increased (+0.0007%) to 99.789% when pulling ee97017679a6d9c579aa93a6971046bb76aba9c6 on sjudson:set-txn-loader into b707600db2019c436c94b27dac64fcbc531412a8 on jaredhanson:master.
The
transactionLoader
middleware constructs thereq.oauth2
object on whichoauth2orize
operates during processing of an authorization request. It does so by appealing to a transaction storage callback, which can be used to dynamically load the state to be placed into thereq.oauth2
object.Although this is generally quite robust, it has an issue in that only a single transaction loader callback may be configured. Particularly for some of the extensions onto the OAuth 2.0 specification (such as the device code flow), transaction loading may be sufficiently different that it is tricky for the restricted callback to properly handle all cases. Although some changes could be made to allow e.g., multiple callback handlers or more extensive function definitions, these changes would introduce complexity and not completely alleviate the issue. Therefore, this PR allows the user to overwrite the entire
transactionLoader
with one of their own design, to either enhance the callback function definition, or provide multiple methods of loading the transaction within the same server. This way we don't change the API for users who want the most simple of implementations, but allow complete power to changes the transaction loading model if necessary or desired.