forked from orbit-oss/flask
Fixed some small typos in the documentation.
Signed-off-by: Armin Ronacher <armin.ronacher@active-4.com>
This commit is contained in:
parent
5764f3abd2
commit
da00160db6
5 changed files with 8 additions and 8 deletions
|
|
@ -208,7 +208,7 @@ configuration::
|
|||
class DevelopmentConfig(Config):
|
||||
DEBUG = True
|
||||
|
||||
class TestinConfig(Config):
|
||||
class TestingConfig(Config):
|
||||
TESTING = True
|
||||
|
||||
To enable such a config you just have to call into
|
||||
|
|
|
|||
|
|
@ -105,7 +105,7 @@ above, just make sure to use a lower setting (I would recommend
|
|||
|
||||
if not app.debug:
|
||||
import logging
|
||||
from themodule import TheHandler YouWant
|
||||
from themodule import TheHandlerYouWant
|
||||
file_handler = TheHandlerYouWant(...)
|
||||
file_handler.setLevel(logging.WARNING)
|
||||
app.logger.addHandler(file_handler)
|
||||
|
|
|
|||
|
|
@ -288,12 +288,12 @@ extension to be approved you have to follow these guidelines:
|
|||
|
||||
1. An approved Flask extension must provide exactly one package or module
|
||||
inside the `flaskext` namespace package.
|
||||
2. It must ship a testsuite that can either be invoked with ``make test``
|
||||
or ``python setup.py test``. For testsuites invoked with ``make
|
||||
2. It must ship a testing suite that can either be invoked with ``make test``
|
||||
or ``python setup.py test``. For test suites invoked with ``make
|
||||
test`` the extension has to ensure that all dependencies for the test
|
||||
are installed automatically, in case of ``python setup.py test``
|
||||
dependencies for tests alone can be specified in the `setup.py`
|
||||
file. The testsuite also has to be part of the distribution.
|
||||
file. The test suite also has to be part of the distribution.
|
||||
3. APIs of approved extensions will be checked for the following
|
||||
characteristics:
|
||||
|
||||
|
|
|
|||
|
|
@ -110,7 +110,7 @@ stuff. Unfortunately that protection is only there for
|
|||
generate JSON.
|
||||
|
||||
So what is the issue and how to avoid it? The problem are arrays at
|
||||
toplevel in JSON. Imagine you send the following data out in a JSON
|
||||
top-level in JSON. Imagine you send the following data out in a JSON
|
||||
request. Say that's exporting the names and email addresses of all your
|
||||
friends for a part of the user interface that is written in JavaScript.
|
||||
Not very uncommon:
|
||||
|
|
@ -156,7 +156,7 @@ possible to patch constructors and register callbacks for setters. An
|
|||
attacker can use this (like above) to get all the data you exported in
|
||||
your JSON file. The browser will totally ignore the ``application/json``
|
||||
mimetype if ``text/javascript`` is defined as content type in the script
|
||||
tag and evaluate that as JavaScript. Because toplevel array elements are
|
||||
tag and evaluate that as JavaScript. Because top-level array elements are
|
||||
allowed (albeit useless) and we hooked in our own constructor, after that
|
||||
page loaded the data from the JSON response is in the `captured` array.
|
||||
|
||||
|
|
|
|||
|
|
@ -91,7 +91,7 @@ General whitespace rules:
|
|||
value = my_list[ index ]
|
||||
value = my_dict ['key']
|
||||
|
||||
Yoda statements are a nogo:
|
||||
Yoda statements are a no-go:
|
||||
Never compare constant with variable, always variable with constant:
|
||||
|
||||
Good::
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue