Expose app_id and secret directly on req.facebook #20
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Remove unused "util" require Add semicolons after function assignments/returns
This was referenced Feb 26, 2013
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This change changes FaceplateSession to take the config object from a Faceplate construtor and put the app_id and secret values directly on the FaceplateSession (which the Faceplate middleware exposes as req.facebook).
This fix alters the only case where one of these values was being used (app_id was read from the plate object for getting the info for
app(): #19 goes further and removes the use of that value altogether.Exposing the app_id is still useful for other situations where these values are needed, such as the broken parts of in heroku/facebook-template-nodejs#11. This can currently be fixed with a solution like heroku/facebook-template-nodejs#12, but reading these values from the
platesobject is... well, a bad dependence on internal behavior.