forked from orbit-oss/flask
Merge branch 'master' into blueprints
This commit is contained in:
commit
4e47ea9105
8 changed files with 15 additions and 15 deletions
|
|
@ -156,8 +156,8 @@ If you have the :attr:`Flask.secret_key` set you can use sessions in Flask
|
||||||
applications. A session basically makes it possible to remember
|
applications. A session basically makes it possible to remember
|
||||||
information from one request to another. The way Flask does this is by
|
information from one request to another. The way Flask does this is by
|
||||||
using a signed cookie. So the user can look at the session contents, but
|
using a signed cookie. So the user can look at the session contents, but
|
||||||
not modify it unless he knows the secret key, so make sure to set that to
|
not modify it unless he or she knows the secret key, so make sure to set that
|
||||||
something complex and unguessable.
|
to something complex and unguessable.
|
||||||
|
|
||||||
To access the current session you can use the :class:`session` object:
|
To access the current session you can use the :class:`session` object:
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -24,7 +24,7 @@ even if the application behaves correctly:
|
||||||
*403 Forbidden*
|
*403 Forbidden*
|
||||||
If you have some kind of access control on your website, you will have
|
If you have some kind of access control on your website, you will have
|
||||||
to send a 403 code for disallowed resources. So make sure the user
|
to send a 403 code for disallowed resources. So make sure the user
|
||||||
is not lost when he tries to access a resource he cannot access.
|
is not lost when he or she tries to access a forbidden resource.
|
||||||
|
|
||||||
*410 Gone*
|
*410 Gone*
|
||||||
Did you know that there the "404 Not Found" has a brother named "410
|
Did you know that there the "404 Not Found" has a brother named "410
|
||||||
|
|
@ -32,7 +32,7 @@ even if the application behaves correctly:
|
||||||
resources that previously existed and got deleted answer with 410
|
resources that previously existed and got deleted answer with 410
|
||||||
instead of 404. If you are not deleting documents permanently from
|
instead of 404. If you are not deleting documents permanently from
|
||||||
the database but just mark them as deleted, do the user a favour and
|
the database but just mark them as deleted, do the user a favour and
|
||||||
use the 410 code instead and display a message that what he was
|
use the 410 code instead and display a message that what he or she was
|
||||||
looking for was deleted for all eternity.
|
looking for was deleted for all eternity.
|
||||||
|
|
||||||
*500 Internal Server Error*
|
*500 Internal Server Error*
|
||||||
|
|
|
||||||
|
|
@ -89,7 +89,7 @@ before storing it directly on the filesystem.
|
||||||
|
|
||||||
Assuming the number of ``../`` is correct and you would join this with
|
Assuming the number of ``../`` is correct and you would join this with
|
||||||
the `UPLOAD_FOLDER` the user might have the ability to modify a file on
|
the `UPLOAD_FOLDER` the user might have the ability to modify a file on
|
||||||
the server's filesystem he should not modify. This does require some
|
the server's filesystem he or she should not modify. This does require some
|
||||||
knowledge about how the application looks like, but trust me, hackers
|
knowledge about how the application looks like, but trust me, hackers
|
||||||
are patient :)
|
are patient :)
|
||||||
|
|
||||||
|
|
@ -155,8 +155,8 @@ Upload Progress Bars
|
||||||
A while ago many developers had the idea to read the incoming file in
|
A while ago many developers had the idea to read the incoming file in
|
||||||
small chunks and store the upload progress in the database to be able to
|
small chunks and store the upload progress in the database to be able to
|
||||||
poll the progress with JavaScript from the client. Long story short: the
|
poll the progress with JavaScript from the client. Long story short: the
|
||||||
client asks the server every 5 seconds how much he has transmitted
|
client asks the server every 5 seconds how much it has transmitted
|
||||||
already. Do you realize the irony? The client is asking for something he
|
already. Do you realize the irony? The client is asking for something it
|
||||||
should already know.
|
should already know.
|
||||||
|
|
||||||
Now there are better solutions to that work faster and more reliable. The
|
Now there are better solutions to that work faster and more reliable. The
|
||||||
|
|
|
||||||
|
|
@ -4,7 +4,7 @@ Message Flashing
|
||||||
================
|
================
|
||||||
|
|
||||||
Good applications and user interfaces are all about feedback. If the user
|
Good applications and user interfaces are all about feedback. If the user
|
||||||
does not get enough feedback he will probably end up hating the
|
does not get enough feedback he or she will probably end up hating the
|
||||||
application. Flask provides a really simple way to give feedback to a
|
application. Flask provides a really simple way to give feedback to a
|
||||||
user with the flashing system. The flashing system basically makes it
|
user with the flashing system. The flashing system basically makes it
|
||||||
possible to record a message at the end of a request and access it next
|
possible to record a message at the end of a request and access it next
|
||||||
|
|
|
||||||
|
|
@ -8,7 +8,7 @@ functionality to one or more functions. The :meth:`~flask.Flask.route`
|
||||||
decorator is the one you probably used already. But there are use cases
|
decorator is the one you probably used already. But there are use cases
|
||||||
for implementing your own decorator. For instance, imagine you have a
|
for implementing your own decorator. For instance, imagine you have a
|
||||||
view that should only be used by people that are logged in to. If a user
|
view that should only be used by people that are logged in to. If a user
|
||||||
goes to the site and is not logged in, he should be redirected to the
|
goes to the site and is not logged in, he or she should be redirected to the
|
||||||
login page. This is a good example of a use case where a decorator is an
|
login page. This is a good example of a use case where a decorator is an
|
||||||
excellent solution.
|
excellent solution.
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -126,7 +126,7 @@ Modern web applications have beautiful URLs. This helps people remember
|
||||||
the URLs which is especially handy for applications that are used from
|
the URLs which is especially handy for applications that are used from
|
||||||
mobile devices with slower network connections. If the user can directly
|
mobile devices with slower network connections. If the user can directly
|
||||||
go to the desired page without having to hit the index page it is more
|
go to the desired page without having to hit the index page it is more
|
||||||
likely he will like the page and come back next time.
|
likely he or she will like the page and come back next time.
|
||||||
|
|
||||||
As you have seen above, the :meth:`~flask.Flask.route` decorator is used
|
As you have seen above, the :meth:`~flask.Flask.route` decorator is used
|
||||||
to bind a function to a URL. Here are some basic examples::
|
to bind a function to a URL. Here are some basic examples::
|
||||||
|
|
@ -614,7 +614,7 @@ code use the :func:`~flask.abort` function. Here an example how this works::
|
||||||
this_is_never_executed()
|
this_is_never_executed()
|
||||||
|
|
||||||
This is a rather pointless example because a user will be redirected from
|
This is a rather pointless example because a user will be redirected from
|
||||||
the index to a page he cannot access (401 means access denied) but it
|
the index to a page he or she cannot access (401 means access denied) but it
|
||||||
shows how that works.
|
shows how that works.
|
||||||
|
|
||||||
By default a black and white error page is shown for each error code. If
|
By default a black and white error page is shown for each error code. If
|
||||||
|
|
@ -641,7 +641,7 @@ Besides the request object there is also a second object called
|
||||||
user from one request to the next. This is implemented on top of cookies
|
user from one request to the next. This is implemented on top of cookies
|
||||||
for you and signs the cookies cryptographically. What this means is that
|
for you and signs the cookies cryptographically. What this means is that
|
||||||
the user could look at the contents of your cookie but not modify it,
|
the user could look at the contents of your cookie but not modify it,
|
||||||
unless he knows the secret key used for signing.
|
unless he or she knows the secret key used for signing.
|
||||||
|
|
||||||
In order to use sessions you have to set a secret key. Here is how
|
In order to use sessions you have to set a secret key. Here is how
|
||||||
sessions work::
|
sessions work::
|
||||||
|
|
@ -697,7 +697,7 @@ Message Flashing
|
||||||
----------------
|
----------------
|
||||||
|
|
||||||
Good applications and user interfaces are all about feedback. If the user
|
Good applications and user interfaces are all about feedback. If the user
|
||||||
does not get enough feedback he will probably end up hating the
|
does not get enough feedback he or she will probably end up hating the
|
||||||
application. Flask provides a really simple way to give feedback to a
|
application. Flask provides a really simple way to give feedback to a
|
||||||
user with the flashing system. The flashing system basically makes it
|
user with the flashing system. The flashing system basically makes it
|
||||||
possible to record a message at the end of a request and access it next
|
possible to record a message at the end of a request and access it next
|
||||||
|
|
|
||||||
|
|
@ -73,7 +73,7 @@ them knowing.
|
||||||
Say you have a specific URL that, when you sent `POST` requests to will
|
Say you have a specific URL that, when you sent `POST` requests to will
|
||||||
delete a user's profile (say `http://example.com/user/delete`). If an
|
delete a user's profile (say `http://example.com/user/delete`). If an
|
||||||
attacker now creates a page that sends a post request to that page with
|
attacker now creates a page that sends a post request to that page with
|
||||||
some JavaScript he just has to trick some users to load that page and
|
some JavaScript he or she just has to trick some users to load that page and
|
||||||
their profiles will end up being deleted.
|
their profiles will end up being deleted.
|
||||||
|
|
||||||
Imagine you were to run Facebook with millions of concurrent users and
|
Imagine you were to run Facebook with millions of concurrent users and
|
||||||
|
|
|
||||||
|
|
@ -29,7 +29,7 @@ The view function will pass the entries as dicts to the
|
||||||
Add New Entry
|
Add New Entry
|
||||||
-------------
|
-------------
|
||||||
|
|
||||||
This view lets the user add new entries if he's logged in. This only
|
This view lets the user add new entries if he or she is logged in. This only
|
||||||
responds to `POST` requests, the actual form is shown on the
|
responds to `POST` requests, the actual form is shown on the
|
||||||
`show_entries` page. If everything worked out well we will
|
`show_entries` page. If everything worked out well we will
|
||||||
:func:`~flask.flash` an information message to the next request and
|
:func:`~flask.flash` an information message to the next request and
|
||||||
|
|
|
||||||
Loading…
Add table
Add a link
Reference in a new issue