fix typos and use h2 for incremental auth example

guides/dynamic_strategy_configuration.md

@@ -1,4 +1,4 @@
-# Dynamic Strategy Configuration
+# Dynamic strategy configuration
 
 In most cases, having a single set of configuration options defined per provider strategy is sufficient.
 For more advanced authorization flows, however, you may find the need to customize strategy configuration dynamically on a per-request basis.
@@ -7,9 +7,9 @@ Pow Assent includes a built-in Plug helper function specifically for these more
 
 You can use this as a building block to create your own custom Plugs that modify the strategy configuration for a given provider. Since we have all of the Plug machinery at our disposal, we can alter the configuration on the basis of anything available in the `%Plug.Conn{}` struct. You could customize the strategy configuration for an individual user, or based on query params, or a bit of state stored in the session.
 
-Below we'll walk through a concrete scenario of one possible dynamic configuration strategy, in order to add [Incremental Authorization](https://developers.google.com/identity/protocols/oauth2/web-server#incrementalAuth) support for for the Google provider strategy in your application.
+Below we'll walk through a concrete scenario of one possible dynamic configuration strategy, in order to add [Incremental Authorization](https://developers.google.com/identity/protocols/oauth2/web-server#incrementalAuth) support for the Google provider strategy in your application.
 
-# Supporting Incremental Authorization
+## Incremental authorization
 
 Google (and many other OAuth 2.0 providers that support granular `scope` configuration) strongly recommends authorizing with the minimum required scopes on first signup to make the initial onboarding experience to your application smooth, to minimize wading through multiple consent modals and asking the user for a bunch of permissions that you may not even need up-front.
 
@@ -40,12 +40,12 @@ config :my_app, :pow_assent,
   ]
 ```
 
-But say that once your users have gone through the initial sign-up process, you have opt-in support for a file-sync mechanism that integrates with Google Drive and requires the `https://www.googleapis.com/auth/drive.file` scope. You could include a custom auth link as part of your settings or feature onboarding flow that requests the user to re-authorize with Google with the added scope, taking advantage of `merge_provider_config` via a custom Plug.
+Say that once your users have gone through the initial sign-up process, you want to have opt-in support for a file-sync mechanism that integrates with Google Drive and requires the `drive.file` scope. You could include a custom auth link as part of your settings page or during a feature onboarding flow that requests the user to re-authorize with Google with the added scope, taking advantage of `merge_provider_config` via a custom Plug.
 
 In this case, for brevity, we can add a custom [Function plug](https://hexdocs.pm/phoenix/plug.html#function-plugs) to our router's existing `:browser` pipeline, like so:
 
 ```elixir
-# router.ex
+# lib/my_app/router.ex
 pipeline :browser do
   # ... misc existing plug pipeline bits
   plug(:accepts, ["html"])
@@ -76,9 +76,9 @@ This could just as easily be replaced with something that checks for a query str
 Here's our function plug example, `put_google_drive_auth_scopes`:
 
 ```elixir
-# could be inlined in router.ex or extended into a Module plug if you
+# could be inlined in router.ex or extended into a standalone module plug if you
 # also want to accept custom arguments, or do more elaborate pattern matching
-# or conn transformations
+# and conn transformations
 def put_google_drive_auth_scopes(conn, _opts) do
   current_user = conn.assigns[:current_user]
   if is_nil(current_user) || !Users.should_request_google_drive_auth_scope?(current_user) do