Add db-plan-enabled recommendation (#588)

* fix broken links

docs/auth.rst

@@ -98,7 +98,7 @@ For PostgreSQL server version >= 14
 .. code:: sql
 
   current_setting('request.jwt.claims', true)::json->>'email';
-  
+
 
 For PostgreSQL server version < 14
 
@@ -292,7 +292,7 @@ JWT security
 
 There are at least three types of common critiques against using JWT: 1) against the standard itself, 2) against using libraries with known security vulnerabilities, and 3) against using JWT for web sessions. We'll briefly explain each critique, how PostgREST deals with it, and give recommendations for appropriate user action.
 
-The critique against the `JWT standard <https://datatracker.ietf.org/doc/html/rfc7519>`_ is voiced in detail `elsewhere on the web <https://paragonie.com/blog/2017/03/jwt-json-web-tokens-is-bad-standard-that-everyone-should-avoid>`_. The most relevant part for PostgREST is the so-called :code:`alg=none` issue. Some servers implementing JWT allow clients to choose the algorithm used to sign the JWT. In this case, an attacker could set the algorithm to :code:`none`, remove the need for any signature at all and gain unauthorized access. The current implementation of PostgREST, however, does not allow clients to set the signature algorithm in the HTTP request, making this attack irrelevant. The critique against the standard is that it requires the implementation of the :code:`alg=none` at all.
+The critique against the `JWT standard <https://datatracker.ietf.org/doc/html/rfc7519>`_ is voiced in detail `elsewhere on the web <https://web.archive.org/web/20230123041631/https://paragonie.com/blog/2017/03/jwt-json-web-tokens-is-bad-standard-that-everyone-should-avoid>`_. The most relevant part for PostgREST is the so-called :code:`alg=none` issue. Some servers implementing JWT allow clients to choose the algorithm used to sign the JWT. In this case, an attacker could set the algorithm to :code:`none`, remove the need for any signature at all and gain unauthorized access. The current implementation of PostgREST, however, does not allow clients to set the signature algorithm in the HTTP request, making this attack irrelevant. The critique against the standard is that it requires the implementation of the :code:`alg=none` at all.
 
 Critiques against JWT libraries are only relevant to PostgREST via the library it uses. As mentioned above, not allowing clients to choose the signature algorithm in HTTP requests removes the greatest risk. Another more subtle attack is possible where servers use asymmetric algorithms like RSA for signatures. Once again this is not relevant to PostgREST since it is not supported. Curious readers can find more information in `this article <https://auth0.com/blog/critical-vulnerabilities-in-json-web-token-libraries/>`_. Recommendations about high quality libraries for usage in API clients can be found on `jwt.io <https://jwt.io/>`_.
 

docs/configuration.rst

@@ -160,7 +160,7 @@ db-pool-timeout          Int     3600
 db-pre-request           String                    Y
 db-prepared-statements   Boolean True              Y
 db-schemas               String  public            Y
-db-tx-end                String  commit            
+db-tx-end                String  commit
 db-uri                   String  postgresql://
 db-use-legacy-gucs       Boolean True              Y
 jwt-aud                  String                    Y
@@ -296,6 +296,30 @@ db-plan-enabled
 
   When this is set to :code:`true`, the execution plan of a request can be retrieved by using the :code:`Accept: application/vnd.pgrst.plan` header. See :ref:`explain_plan`.
 
+  It's recommended to use this in testing environments only since it reveals internal database details.
+  However, if you choose to use it in production you can add a :ref:`db-pre-request` to filter the requests that can use this feature.
+
+  For example, to only allow requests from an IP address to get the execution plans:
+
+  .. code-block:: postgresql
+
+   -- Assuming a proxy(Nginx, Cloudflare, etc) passes an "X-Forwarded-For" header(https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Forwarded-For)
+   create or replace function filter_plan_requests()
+   returns void as $$
+   declare
+     headers   json := current_setting('request.headers', true)::json;
+     client_ip text := coalesce(headers->>'x-forwarded-for', '');
+     accept    text := coalesce(headers->>'accept', '');
+   begin
+     if accept like 'application/vnd.pgrst.plan%' and client_ip != '144.96.121.73' then
+       raise insufficient_privilege using
+         message = 'Not allowed to use application/vnd.pgrst.plan';
+     end if;
+   end; $$ language plpgsql;
+
+   -- set this function on your postgrest.conf
+   -- db-pre-request = filter_plan_requests
+
 .. _db-pool:
 
 db-pool

docs/ecosystem.rst

@@ -89,7 +89,6 @@ Extensions
 * `aiodata <https://github.com/Exahilosys/aiodata>`_ - Python, event-based proxy and caching client.
 * `pg-safeupdate <https://github.com/eradman/pg-safeupdate>`_ - prevent full-table updates or deletes
 * `postgrest-auth (criles25) <https://github.com/criles25/postgrest-auth>`_ - email based auth/signup
-* `postgrest-auth (svmotn) <https://github.com/svmnotn/postgrest-auth>`_ - OAuth2-inspired external auth server
 * `postgrest-node <https://github.com/seveibar/postgrest-node>`_ - Run a PostgREST server in Node.js via npm module
 * `postgrest-oauth <https://github.com/nblumoe/postgrest-oauth>`_ - OAuth2 WAI middleware
 * `postgrest-oauth/api <https://github.com/postgrest-oauth/api>`_ - OAuth2 server