Added `ALLOWED_FILTERS` setting. Filters now disabled by default.
Unnecessary line break removed
Optional custom payload for methods.post. Addresses #74.

When calling post() from your own code, you can provide an alternative
payload. This can be useful, for example, when you have a callback
function hooked to a certain endpoint, and want to perform additional
post() calls from there.

Please be advised that in order to successfully use this option,
a request context must be available.

See https://github.com/nicolaiarocci/eve/issues/74 for a discussion and
a typical use case.
Projections include automatic fields. Closes #85.

Datasource projections always include automatic fields ID_FIELD,
LAST_UPDATED and DATAE_CREATED, as designed.
More robust event hooks naming system. Closes #80.

To emphasize the fact that they are tied to a method, all
``on_<method>`` hooks now have ``<method>`` in uppercase.

- ``on_getting`` renamed to ``on_fetch``.
- ``on_getting_item`` renamed to ``on_fetch_item``.
- ``on_getting_item_<item_title>`` renamed to
  ``on_fetch_item_<item_title>``.
- ``on_posting`` renamed to ``on_insert``.
'on_fetch' > 'on_fetch_resource'. Addresses #80.

Taking care of the odd case where a resource has been called "item".

- 'on_fetch' > 'on_fetch_resource'
- 'on_fetch_resource' > 'on_fetch_resource_%s' % resource
Custom User Ids for User Restricted Resource Access.

The feature now supports custom User Ids, allowing for more flexibility
and token revocation with token-based authentication.

- 'AUTH_USERNAME_FIELD' renamed to 'AUTH_FIELD'
- 'auth_username_field' renamed to 'auth_field'
- BasicAuth and subclasses now support the user_id property

This change breaks backward compatibility. If you want to preserve the
old 'AUTH_USERNAME_FIELD' behavior, just set 'self.user_id' to
'username'.

Closes #73.
Merge branch 'allowed_filters_setting' of https://github.com/bcattle/eve into bcattle-allowed_filters_setting
PEP8/E501 fixes
Filters enabled by default.

Since I'm not aware of direct attack vectors on mongo 'where' clause,
except for JS operators which are blacklisted by default already,
I prefer leaving filters enabled as it will make API implementation
easier on the API maintainer (not having to explictly whitelist every
single filter, for every resource).

In the documentation I'm going to suggest that if scraping or preventing
DB DoS attacks are a concern, then disabling all filters and then
whitelisting valid ones is the way to go.

NOTE: not really sure on this one, we might fallback to the original "filters
disabled by default" proposed by Bryan Cattle.
Documentation for 'ALLOWED_FILTERS'.
validate_filters()

This utility function reports any filter which is not allowed by
'allowed_filters'. It is placed in eve.utils so it can be used by other
data layers as needed.
Abort 400 if 'where' contains illegal filters.
Test filters blacklisting
Merge branch 'bcattle-allowed_filters_setting' into develop
FILTERS replaced by ALLOWED_FILTERS. Closes #78.
PEP8/E222
Python 3.3 compatibility fix
typo
Werkzeug 0.9.4