Spell check, WIP Circle CI for sphinx
This commit is contained in:
@@ -92,7 +92,7 @@ However it's very easy to delete the **entire table** by omitting the query para
|
||||
|
||||
This can happen accidentally such as by switching a request from a GET to a DELETE. To protect against accidental operations use the `pg-safeupdate <https://bitbucket.org/eradman/pg-safeupdate/>`_ PostgreSQL extension. It raises an error if UPDATE or DELETE are executed without specifying conditions.
|
||||
|
||||
This does not protect against malicious actions, since someone can add a url parameter that does not affect the resultset. To prevent this you must turn to database permissions, forbidding the wrong people from deleting rows, and using `row-level security <https://www.postgresql.org/docs/current/static/ddl-rowsecurity.html>`_ if finer access control is required.
|
||||
This does not protect against malicious actions, since someone can add a url parameter that does not affect the result set. To prevent this you must turn to database permissions, forbidding the wrong people from deleting rows, and using `row-level security <https://www.postgresql.org/docs/current/static/ddl-rowsecurity.html>`_ if finer access control is required.
|
||||
|
||||
Count-Header DoS
|
||||
----------------
|
||||
@@ -138,7 +138,7 @@ Foo
|
||||
Debugging
|
||||
=========
|
||||
|
||||
The PostgREST server logs basic request information to stdout, including the requester's IP address and user agent, the URL requested, and HTTP response status. However this provides limited information for debugging server errors. It's helpful to get full information about both client requests and the corresponding SQL commands executed against the underlying database.
|
||||
The PostgREST server logs basic request information to stdout, including the requesting IP address and user agent, the URL requested, and HTTP response status. However this provides limited information for debugging server errors. It's helpful to get full information about both client requests and the corresponding SQL commands executed against the underlying database.
|
||||
|
||||
A great way to inspect incoming HTTP requests including headers and query params is to sniff the network traffic on the port where PostgREST is running. For instance on a development server bound to port 3000 on localhost, run this:
|
||||
|
||||
|
||||
@@ -146,7 +146,7 @@ Note that the server may respond with fewer if unable to meet your request:
|
||||
|
||||
You may also request open-ended ranges for an offset with no limit, e.g. :code:`Range: 10-`.
|
||||
|
||||
The other way to request a limit or offset is with query pamameters. For example
|
||||
The other way to request a limit or offset is with query parameters. For example
|
||||
|
||||
.. code-block:: http
|
||||
|
||||
|
||||
@@ -61,7 +61,7 @@ You can use row-level security to flexibly restrict visibility and access for th
|
||||
message_body TEXT
|
||||
);
|
||||
|
||||
We want to enforce a policy that ensures a user can see only those messages sent by him or intended for him. Also we want to prevent a user from forging the message_from column with anyone else's name.
|
||||
We want to enforce a policy that ensures a user can see only those messages sent by him or intended for him. Also we want to prevent a user from forging the message_from column with another person's name.
|
||||
|
||||
PostgreSQL (9.5 and later) allows us to set this policy with row-level security:
|
||||
|
||||
@@ -310,7 +310,7 @@ In the previous section we created an internal table to store user information.
|
||||
Logins
|
||||
~~~~~~
|
||||
|
||||
As described in `JWT from SQL`_, we'll create a JWT inside our login function. Note that you'll need to adjust the secret key which is hardcoded in this example to a secure secret of your choosing.
|
||||
As described in `JWT from SQL`_, we'll create a JWT inside our login function. Note that you'll need to adjust the secret key which is hard-coded in this example to a secure secret of your choosing.
|
||||
|
||||
.. code:: plpgsql
|
||||
|
||||
|
||||
@@ -0,0 +1,8 @@
|
||||
dependencies:
|
||||
pre:
|
||||
- sudo apt-get install aspell
|
||||
|
||||
test:
|
||||
override:
|
||||
- cat *.rst | grep -v '^\(\.\.\| \)' | sed 's/`.*`//g' |aspell -d en_US -p ./postgrest.dict list | tee misspellings
|
||||
- test ! -s misspellings
|
||||
+1
-1
@@ -21,7 +21,7 @@ Build from Source
|
||||
|
||||
We discourage building and using PostgREST on **Alpine Linux** because of a reported GHC memory leak on that platform.
|
||||
|
||||
When a prebuilt binary does not exist for your system you can build the project from source. You'll also need to do this if you want to help with development. `Stack <https://github.com/commercialhaskell/stack>`_ makes it easy. It will install any necessary Haskell dependencies on your system.
|
||||
When a pre-built binary does not exist for your system you can build the project from source. You'll also need to do this if you want to help with development. `Stack <https://github.com/commercialhaskell/stack>`_ makes it easy. It will install any necessary Haskell dependencies on your system.
|
||||
|
||||
* `Install Stack <http://docs.haskellstack.org/en/stable/README.html#how-to-install>`_ for your platform
|
||||
* Install Library Dependencies
|
||||
|
||||
@@ -10,8 +10,8 @@ Declarative Programming
|
||||
|
||||
It's easier to ask PostgreSQL to join data for you and let its query planner figure out the details than to loop through rows yourself. It's easier to assign permissions to db objects than to add guards in controllers. (This is especially true for cascading permissions in data dependencies.) It's easier set constraints than to litter code with sanity checks.
|
||||
|
||||
Leakproof Abstraction
|
||||
---------------------
|
||||
Leak-proof Abstraction
|
||||
----------------------
|
||||
|
||||
There is no ORM involved. Creating new views happens in SQL with known performance implications. A database administrator can now create an API from scratch with no custom programming.
|
||||
|
||||
@@ -28,7 +28,7 @@ PostgREST has a focused scope. It works well with other tools like Nginx. This f
|
||||
Shared Improvements
|
||||
-------------------
|
||||
|
||||
As with any open source project, we all gain from features and fixes in the tool. It's more beneficial than improvements locked inextricably within custom codebases.
|
||||
As with any open source project, we all gain from features and fixes in the tool. It's more beneficial than improvements locked inextricably within custom code-bases.
|
||||
|
||||
Ecosystem
|
||||
#########
|
||||
|
||||
@@ -0,0 +1,85 @@
|
||||
personal_ws-1.1 en 0 utf-8
|
||||
Auth
|
||||
Codd
|
||||
DoS
|
||||
GUC
|
||||
Github
|
||||
Google
|
||||
GraphQL
|
||||
HMAC
|
||||
HTTPS
|
||||
Haskell
|
||||
Heroku
|
||||
Homebrew
|
||||
ILIKE
|
||||
IP
|
||||
JS
|
||||
JSON
|
||||
JWT
|
||||
Logins
|
||||
MVCC
|
||||
Mithril
|
||||
NGINX
|
||||
Nginx
|
||||
OAuth
|
||||
ORM
|
||||
OpenAPI
|
||||
PaaS
|
||||
PostGIS
|
||||
PostgREST
|
||||
PostgREST's
|
||||
PostgreSQL
|
||||
PostgreSQL's
|
||||
RDS
|
||||
RESTful
|
||||
RLS
|
||||
RestSharp
|
||||
SHA
|
||||
SIGHUP
|
||||
SQL
|
||||
SSL
|
||||
Sencha
|
||||
SuperAgent
|
||||
UI
|
||||
Vondra
|
||||
WAI
|
||||
api
|
||||
auth
|
||||
authenticator
|
||||
balancer
|
||||
centric
|
||||
config
|
||||
cryptographically
|
||||
eq
|
||||
gte
|
||||
http
|
||||
ilike
|
||||
jwt
|
||||
localhost
|
||||
login
|
||||
logins
|
||||
lt
|
||||
lte
|
||||
middleware
|
||||
namespaced
|
||||
neq
|
||||
ngrep
|
||||
nullsfirst
|
||||
nullslast
|
||||
param
|
||||
params
|
||||
passphrase
|
||||
pgcrypto
|
||||
pgjwt
|
||||
pre
|
||||
refactor
|
||||
signup
|
||||
sqitch
|
||||
startup
|
||||
stdout
|
||||
tsquery
|
||||
uri
|
||||
url
|
||||
verifier
|
||||
versioning
|
||||
webuser
|
||||
Reference in New Issue
Block a user