Though templating systems such as Template::Toolkit and web frameworks such as Dancer and content management systems such as WebGUI http://www.webgui.org/ are out of scope for this document,
when you build your own application,
you should definitely consider using them.

For simplicity sake,
in this recipe we'll be storing important information directly in the code.
This is a terrible practice.
Instead use a config file system like Config::JSON to store your settings.

If we only wanted basic permissions we can leave the extend_permissions call out. But for this app let's say we want access to the user's email address and we want to be able to interact with the user's account even when they aren't online.

We map the subroutine we created to /facebook because we'll likely have other things we want to display at /. If we wanted to display something else at /facebook we could have mapped this function to /facebook/authorize. It really doesn't matter what URL we use here, all that matters is that when we want our users to authenticate against Facebook, this is the URL that we're going to send them to in our application.

Our connect/authorization page will redirect the user to Facebook to authorize our app. Now we need to create the page that the user will be redirected back to from Facebook. This is the postback that we created in step 6.

It's really stupid of us to pass our access token along the URL especially since we requested offline_access. We're only doing it here to demonstrate the usage of it. If you're requesting offline access, you should keep the access token locked away in a secure database. If you want to pass it along the URL, or store it in a cookie, you should not request offline_access.

You should never design an application using all the poor stuff we've done here, like using a shared Facebook::Graph object, not using a Framework/CMS or at least Plack::Builder, not using a templating system, passing the offline access token through the URL, etc. We've made comments about these things as we did them to warn you. These choices were made here only because this is example code who's primary purpose is to show you how to use Facebook::Graph, and not best practices for web development.