librelist archives

RFC: Upcoming Flask 0.6 Release

From:

Armin Ronacher

Date:

2010-07-17 @ 14:00

Hi everybody,

I want to release Flask 0.6 next week so I would love to get some 
feedback.  There is a lot that changed with 0.6, mostly detail 
improvements but also tons of new stuff to support extensions more.

Here the major changes in 0.6:

  * after request functions are now called in reverse order of
    registration.
  * OPTIONS is now automatically implemented by Flask unless the
    application explictly adds ‘OPTIONS’ as method to the URL rule. In
    this case no automatic OPTIONS handling kicks in.
  * static rules are now even in place if there is no static folder for
    the module. This was implemented to aid GAE which will remove the
    static folder if it’s part of a mapping in the .yml file.
  * the config is now available in the templates as config.
  * context processors will no longer override values passed directly to
    the render function.
  * added the ability to limit the incoming request data with the new
    MAX_CONTENT_LENGTH configuration value.
  * the endpoint for the flask.Module.add_url_rule() method is now
    optional to be consistent with the function of the same name on the
    application object.
  * added a flask.make_response() function that simplifies creating
    response object instances in views.
  * added signalling support based on blinker. This feature is currently
    optional and supposed to be used by extensions and applications. If
    you want to use it, make sure to have blinker installed.

The signalling stuff is especially cool because it allows Flask-Testing 
for example to provide better tests.  Flask-Testing for instance could 
provide methods to check if the correct values are passed to the 
template context, if the correct templates are rendered etc.

So far there are 4 signals that Flask emits:

  - template_rendered
  - request_started
  - request_finished
  - got_request_exception

I can't think of anything else that Flask does where signals would be 
useful, but maybe you have a pony request there.


Regards,
Armin

On 17 July 2010 15:00, Armin Ronacher <armin.ronacher@active-4.com> wrote:

>  * added signalling support based on blinker. This feature is currently
>    optional and supposed to be used by extensions and applications. If
>    you want to use it, make sure to have blinker installed.
>
> The signalling stuff is especially cool because it allows Flask-Testing
> for example to provide better tests.  Flask-Testing for instance could
> provide methods to check if the correct values are passed to the
> template context, if the correct templates are rendered etc.
>
> So far there are 4 signals that Flask emits:
>
>  - template_rendered
>  - request_started
>  - request_finished
>  - got_request_exception
>
> I can't think of anything else that Flask does where signals would be
> useful, but maybe you have a pony request there.

This is really great, I have some code that does the same thing. Is
there API for allowing extensions to define and emit their own
signals?

Hi,

On 7/17/10 7:52 PM, Ali Afshar wrote:
> This is really great, I have some code that does the same thing. Is
> there API for allowing extensions to define and emit their own
> signals?
Yes.  flask.signals.Namespace is declared public API for extensions.


Regards,
Armin

Regarding Flask-Testing: would it be useful to have additional helper
methods for checking template content ?

On 17 July 2010 15:00, Armin Ronacher <armin.ronacher@active-4.com> wrote:
> Hi everybody,
>
> I want to release Flask 0.6 next week so I would love to get some
> feedback.  There is a lot that changed with 0.6, mostly detail
> improvements but also tons of new stuff to support extensions more.
>
> Here the major changes in 0.6:
>
>  * after request functions are now called in reverse order of
>    registration.
>  * OPTIONS is now automatically implemented by Flask unless the
>    application explictly adds ‘OPTIONS’ as method to the URL rule. In
>    this case no automatic OPTIONS handling kicks in.
>  * static rules are now even in place if there is no static folder for
>    the module. This was implemented to aid GAE which will remove the
>    static folder if it’s part of a mapping in the .yml file.
>  * the config is now available in the templates as config.
>  * context processors will no longer override values passed directly to
>    the render function.
>  * added the ability to limit the incoming request data with the new
>    MAX_CONTENT_LENGTH configuration value.
>  * the endpoint for the flask.Module.add_url_rule() method is now
>    optional to be consistent with the function of the same name on the
>    application object.
>  * added a flask.make_response() function that simplifies creating
>    response object instances in views.
>  * added signalling support based on blinker. This feature is currently
>    optional and supposed to be used by extensions and applications. If
>    you want to use it, make sure to have blinker installed.
>
> The signalling stuff is especially cool because it allows Flask-Testing
> for example to provide better tests.  Flask-Testing for instance could
> provide methods to check if the correct values are passed to the
> template context, if the correct templates are rendered etc.
>
> So far there are 4 signals that Flask emits:
>
>  - template_rendered
>  - request_started
>  - request_finished
>  - got_request_exception
>
> I can't think of anything else that Flask does where signals would be
> useful, but maybe you have a pony request there.
>
>
> Regards,
> Armin
>

Most of these look pretty cool. The main thing I'm concerned about is 
the configuration being available in templates. I think that whether to 
expose configuration values in templates should be an app-by-app 
decision, because a third-party theme like in Flask-Themes might be able 
to, say, hide the secret key in a comment so the theme's author could 
come back and hijack sessions. I know that's not plausible if you have a 
smart sysadmin, but it does show the amount of risks involved.

I think you should split off showing the themes into a separate context 
processor, and just put instructions on how to add it in the docs.

Just for reference, what I did for Ryshcate was have a site_config 
template global. Calling 'site_config("title", "Ryshcate")', for 
example, would get the SITE_TITLE configuration variable or "Ryshcate" 
if it didn't exist. The SITE_ configuration values (SITE_TITLE, 
SITE_COPYRIGHT, SITE_EXTRA_LINKS, SITE_MOTD) were all for customizing 
the look and feel of the site.

On 07/17/2010 10:00 AM, Armin Ronacher wrote:
> Hi everybody,
>
> I want to release Flask 0.6 next week so I would love to get some
> feedback.  There is a lot that changed with 0.6, mostly detail
> improvements but also tons of new stuff to support extensions more.
>
> Here the major changes in 0.6:
>
>    * after request functions are now called in reverse order of
>      registration.
>    * OPTIONS is now automatically implemented by Flask unless the
>      application explictly adds ‘OPTIONS’ as method to the URL rule. In
>      this case no automatic OPTIONS handling kicks in.
>    * static rules are now even in place if there is no static folder for
>      the module. This was implemented to aid GAE which will remove the
>      static folder if it’s part of a mapping in the .yml file.
>    * the config is now available in the templates as config.
>    * context processors will no longer override values passed directly to
>      the render function.
>    * added the ability to limit the incoming request data with the new
>      MAX_CONTENT_LENGTH configuration value.
>    * the endpoint for the flask.Module.add_url_rule() method is now
>      optional to be consistent with the function of the same name on the
>      application object.
>    * added a flask.make_response() function that simplifies creating
>      response object instances in views.
>    * added signalling support based on blinker. This feature is currently
>      optional and supposed to be used by extensions and applications. If
>      you want to use it, make sure to have blinker installed.
>
> Regards,
> Armin


-- 
Regards, Matthew "LeafStorm" Frazier
http://leafstorm.us/

Hi,

On 7/17/10 4:18 PM, LeafStorm wrote:
> Most of these look pretty cool. The main thing I'm concerned about is
> the configuration being available in templates. I think that whether to
> expose configuration values in templates should be an app-by-app
> decision, because a third-party theme like in Flask-Themes might be able
> to, say, hide the secret key in a comment so the theme's author could
> come back and hijack sessions. I know that's not plausible if you have a
> smart sysadmin, but it does show the amount of risks involved.
False security:

 >>> app.config['SECRET_KEY'] = 'really secret'
 >>> render_template_string('''{{
... request.__class__.json.func.func_globals
... ._request_ctx_stack.top.app.config.SECRET_KEY }}')
u'really secret'

If you want security, you need a sandboxed environment, and that can be 
tricky to combine with the one from the application.  But config there 
or not, the person that wants to do harm, can already do that.


Regards,
Armin

Point. Though I am a bit surprised that 'request' is in the template 
context. (And yes, I know even if it wasn't there, they could still find 
another exploit.) Looking at the API docs for 'update_template_context', 
I can see it now, but it's kind of buried. You may want to document all 
the things available to the template (including functions like url_for) 
on a page somewhere.

On 07/17/2010 10:43 AM, Armin Ronacher wrote:
> Hi,
>
> False security:
>
>   >>>  app.config['SECRET_KEY'] = 'really secret'
>   >>>  render_template_string('''{{
> ... request.__class__.json.func.func_globals
> ... ._request_ctx_stack.top.app.config.SECRET_KEY }}')
> u'really secret'
>
> If you want security, you need a sandboxed environment, and that can be
> tricky to combine with the one from the application.  But config there
> or not, the person that wants to do harm, can already do that.
>
>
> Regards,
> Armin
-- 
Regards, Matthew "LeafStorm" Frazier
http://leafstorm.us/

Would it be possible to have some kind of sandboxing in Flask-Themes ?
Most developers want to have access to the Flask API in the templates,
which is fine for most cases. However if you want to allow end users
to be able to add their own templates, perhaps you could have a
"sandbox" setting to remove all or some variables.

On 17 July 2010 15:51, LeafStorm <leafstormrush@gmail.com> wrote:
> Point. Though I am a bit surprised that 'request' is in the template
> context. (And yes, I know even if it wasn't there, they could still find
> another exploit.) Looking at the API docs for 'update_template_context',
> I can see it now, but it's kind of buried. You may want to document all
> the things available to the template (including functions like url_for)
> on a page somewhere.
>
> On 07/17/2010 10:43 AM, Armin Ronacher wrote:
>> Hi,
>>
>> False security:
>>
>>   >>>  app.config['SECRET_KEY'] = 'really secret'
>>   >>>  render_template_string('''{{
>> ... request.__class__.json.func.func_globals
>> ... ._request_ctx_stack.top.app.config.SECRET_KEY }}')
>> u'really secret'
>>
>> If you want security, you need a sandboxed environment, and that can be
>> tricky to combine with the one from the application.  But config there
>> or not, the person that wants to do harm, can already do that.
>>
>>
>> Regards,
>> Armin
> --
> Regards, Matthew "LeafStorm" Frazier
> http://leafstorm.us/
>

It would be handy if config was also available as a local proxy in the
same way, or at least as a get_config() function: current_app.config
can get a bit verbose.

On 17 July 2010 15:00, Armin Ronacher <armin.ronacher@active-4.com> wrote:
> Hi everybody,
>
> I want to release Flask 0.6 next week so I would love to get some
> feedback.  There is a lot that changed with 0.6, mostly detail
> improvements but also tons of new stuff to support extensions more.
>
> Here the major changes in 0.6:
>
>  * after request functions are now called in reverse order of
>    registration.
>  * OPTIONS is now automatically implemented by Flask unless the
>    application explictly adds ‘OPTIONS’ as method to the URL rule. In
>    this case no automatic OPTIONS handling kicks in.
>  * static rules are now even in place if there is no static folder for
>    the module. This was implemented to aid GAE which will remove the
>    static folder if it’s part of a mapping in the .yml file.
>  * the config is now available in the templates as config.
>  * context processors will no longer override values passed directly to
>    the render function.
>  * added the ability to limit the incoming request data with the new
>    MAX_CONTENT_LENGTH configuration value.
>  * the endpoint for the flask.Module.add_url_rule() method is now
>    optional to be consistent with the function of the same name on the
>    application object.
>  * added a flask.make_response() function that simplifies creating
>    response object instances in views.
>  * added signalling support based on blinker. This feature is currently
>    optional and supposed to be used by extensions and applications. If
>    you want to use it, make sure to have blinker installed.
>
> The signalling stuff is especially cool because it allows Flask-Testing
> for example to provide better tests.  Flask-Testing for instance could
> provide methods to check if the correct values are passed to the
> template context, if the correct templates are rendered etc.
>
> So far there are 4 signals that Flask emits:
>
>  - template_rendered
>  - request_started
>  - request_finished
>  - got_request_exception
>
> I can't think of anything else that Flask does where signals would be
> useful, but maybe you have a pony request there.
>
>
> Regards,
> Armin
>