CODEWITHSUNDEEP
pythonapacheflask
a.costa
a.costa

Reputation: 1059

Apache configuration file for Flask

On Flask's official documentation, at the section Configuring Apache, it says to create a sites-available file as follow:

<VirtualHost *>
ServerName example.com

WSGIDaemonProcess yourapplication user=user1 group=group1 threads=5
WSGIScriptAlias / /var/www/yourapplication/yourapplication.wsgi

<Directory /var/www/yourapplication>
    WSGIProcessGroup yourapplication
    WSGIApplicationGroup %{GLOBAL}
    Order deny,allow
    Allow from all
</Directory>

it does work, but i don't understand what the directory section is used for. In fact, if I remove it from the file, the web application keeps working.

Can someone explain me what each section of this configuration does?

Upvotes: 2

Views: 1166

Answers (2)

Graham Dumpleton
Graham Dumpleton

Reputation: 58523

There are three consequences of removing the Directory section.

  • The first is that by rights your Apache server should refuse to accept requests for the WSGI application. This is because you have removed the Allow from all directive which tells Apache it is allowed to give access to the WSGI script. That it doesn't fail suggests that your Apache server has a lax security configuration which is allowing access to any part of the file system by default, something which is regarded as bad practice as it lessons the security of your whole Apache instance.

  • The second is that your WSGI application will not run in the separate daemon processes created by mod_wsgi and as set up by the WSGIDaemonProcess directive. This is the result of removing WSGIProcessGroup. This is a bad idea as it means your WSGI application runs in embedded mode, which means it runs in the Apache child processes. This is regarded as a bad idea as the default Apache configuration and how it manages processes/threads is targeted at static file hosting and PHP. That configuration is very bad for Python web applications and as a result your web application hosted with mod_wsgi could perform badly depending on what it is doing and how much traffic you get. Daemon mode is the recommended mode as you can better customise it so it works the best for your specific WSGI application.

  • The third is your WSGI application will run in a sub interpreter, rather than the main Python interpreter context of each process. This is result of removing WSGIApplicationGroup %{GLOBAL}. Running in a sub interpreter context can be bad as there are various third party C extension modules for Python that will not run properly in a sub interpreter context. So best practice is to force the use of the main interpreter context, but to do that you need to also have the WSGI application running in its own daemon process group as was setup by WSGIDaemonProcess and WSGIProcessGroup.

Upvotes: 4

Alanbato
Alanbato

Reputation: 1

The configuration file is for the mod_wsgi package that implements a simple to use Apache module which can host any Python web application which supports the Python WSGI specification.

From mod_wgsi archived wiki:

  1. mod_wgsi Configuration Directives

    • WSGIApplicationProcess

      The WSGIProcessGroup directive can be used to specify which process group a WSGI application or set of WSGI applications will be executed in. All WSGI applications within the same process group will execute within the context of the same group of daemon processes.

    • WSGIApplicationGroup

      The WSGIApplicationGroup directive can be used to specify which application group a WSGI application or set of WSGI applications belongs to. All WSGI applications within the same application group will execute within the context of the same Python sub interpreter of the process handling the request.

  2. This explains the Order and Allow part: mod_wgsi Access Control Mechanisms

Upvotes: 0

Related Questions