Diffbook easy? diffbook

This book includes the following chapters, besides this introduction:
- [[Chapter 2 ../02]] is a minimalist introduction to Python. It assumes knowledge of both procedural and object-oriented programming concepts such as loops, conditions, function calls and classes, and covers basic Python syntax. It also covers examples of Python modules that are used throughout the book. If you already know Python, you may skip Chapter 2.
- [[Chapter 3 ../03]] shows how to start web2py, discusses the administrative interface, and guides the reader through various examples of increasing complexity: an application that returns a string, a counter application, an image blog, and a full blown wiki application that allows image uploads and comments, provides authentication, authorization, web services and an RSS feed. While reading this chapter, you may need to refer to Chapter 2 for general Python syntax and to the following chapters for a more detailed reference about the functions that are used.
- [[Chapter 4 ../04]] covers more systematically the core structure and libraries: URL mapping, request, response, sessions, caching, scheduler, cron, internationalization and general workflow.
- [[Chapter 5 ../05]] is a reference for the template language used to build views. It shows how to embed Python code into HTML, and demonstrates the use of helpers (objects that can generate HTML).
- [[Chapter 6 ../06]] covers the Database Abstraction Layer, or DAL. The syntax of the DAL is presented through a series of examples.
- [[Chapter 7 ../07]] covers forms, form validation and form processing. FORM is the low level helper for form building. SQLFORM is the high level form builder. In Chapter 7 we also discuss Create/Read/Update/Delete (CRUD) API.
- [[Chapter 8 ../08]] covers communication features as retrieving and sending emails and SMSes.
- [[Chapter 9 ../09]] covers authentication, authorization and the extensible Role-Based Access Control mechanism available in web2py. Mail configuration and CAPTCHA are also discussed here, since they are used for authentication. In the third edition of the book we have added extensive coverage of integration with third-party authentication mechanisms such as OpenID, OAuth, Google, Facebook, LinkedIn, etc.
- [[Chapter 10 ../10]] is about creating web services in web2py. We provide examples of integration with the Google Web Toolkit via Pyjamas, and with Adobe Flash via PyAMF.
- [[Chapter 11 ../11]] is about web2py and jQuery recipes. web2py is designed mainly for server-side programming, but it includes jQuery, since we have found it to be the best open-source JavaScript library available for effects and Ajax. In this chapter, we discuss how to effectively use jQuery with web2py.
- [[Chapter 12 ../12]] discusses web2py components and plugins as a way to build modular applications. We provide an example of a plugin that implements many commonly used functionality, such as charting, comments, and tagging.
- [[Chapter 13 ../13]] is about production deployment of web2py applications. We specifically discuss the deployment on a LAMP web server (which we consider the main deployment alternative). We discuss alternative web servers, and configuration of the PostgreSQL database. We discuss running as a service on a Microsoft Windows environment, and deployment on some specific platforms including Google Applications Engine, Heroku, and PythonAnywhere. In this chapter, we also discuss security and scalability issues.
- [[Chapter 14 ../14]] contains a variety of other recipes to solve specific tasks, including upgrades, geocoding, pagination, the Twitter API, and more.
- [[Chapter 15 ../15]] has information and helping and contributing to the project, with topics such as making bug reports and contributing changes to the code.
This book includes the following chapters, besides this introduction:
- [[Chapter 2 ../02]] is a minimalist introduction to Python. It assumes knowledge of both procedural and object-oriented programming concepts such as loops, conditions, function calls and classes, and covers basic Python syntax. It also covers examples of Python modules that are used throughout the book. If you already know Python, you may skip Chapter 2.
- [[Chapter 3 ../03]] shows how to start web2py, discusses the administrative interface, and guides the reader through various examples of increasing complexity: an application that returns a string, a counter application, an image blog, and a full blown wiki application that allows image uploads and comments, provides authentication, authorization, web services and an RSS feed. While reading this chapter, you may need to refer to Chapter 2 for general Python syntax and to the following chapters for a more detailed reference about the functions that are used.
- [[Chapter 4 ../04]] covers more systematically the core structure and libraries: URL mapping, request, response, sessions, caching, scheduler, cron, internationalization and general workflow.
- [[Chapter 5 ../05]] is a reference for the template language used to build views. It shows how to embed Python code into HTML, and demonstrates the use of helpers (objects that can generate HTML).
- [[Chapter 6 ../06]] covers the Database Abstraction Layer, or DAL. The syntax of the DAL is presented through a series of examples.
- [[Chapter 7 ../07]] covers forms, form validation and form processing. FORM is the low level helper for form building. SQLFORM is the high level form builder. In Chapter 7 we also discuss Create/Read/Update/Delete (CRUD) API.
- [[Chapter 8 ../08]] covers communication features as retrieving and sending emails and SMSes.
- [[Chapter 9 ../09]] covers authentication, authorization and the extensible Role-Based Access Control mechanism available in web2py. Mail configuration and CAPTCHA are also discussed here, since they are used for authentication. In the third edition of the book we have added extensive coverage of integration with third-party authentication mechanisms such as OpenID, OAuth, Google, Facebook, LinkedIn, etc.
- [[Chapter 10 ../10]] is about creating web services in web2py. We provide examples of integration with the Google Web Toolkit via Pyjamas, and with Adobe Flash via PyAMF.
- [[Chapter 11 ../11]] is about web2py and jQuery recipes. web2py is designed mainly for server-side programming, but it includes jQuery, since we have found it to be the best open-source JavaScript library available for effects and Ajax. In this chapter, we discuss how to effectively use jQuery with web2py.
- [[Chapter 12 ../12]] discusses web2py components and plugins as a way to build modular applications. We provide an example of a plugin that implements many commonly used functionality, such as charting, comments, and tagging.
- [[Chapter 13 ../13]] is about production deployment of web2py applications. We specifically discuss the deployment on a LAMP web server (which we consider the main deployment alternative). We discuss alterantive web servers, and configuration of the PostgreSQL database. We discuss running as a service on a Microsoft Windows environment, and deployment on some specific platforms including Google Applications Engine, Heroku, and PythonAnywhere. In this chapter, we also discuss security and scalability issues.
- [[Chapter 14 ../14]] contains a variety of other recipes to solve specific tasks, including upgrades, geocoding, pagination, the Twitter API, and more.
- [[Chapter 15 ../15]] has information and helping and contributing to the project, with topics such as making bug reports and contributing changes to the code.
You can find additional topics discussed on the usergroup``usergroup``:cite. There is also AlterEgo``alterego``:cite, the old web2py blog and FAQ.
``MARKMIN``:inxx
This book has been written using the MARKMIN syntax [[See Chapter 5 ../05#markmin_syntax]] and automatically converted to HTML, LaTeX and PDF.
You can find additional topics discussed on the usergroup``usergroup``:cite. There is also AlterEgo``alterego``:cite, the old web2py blog and FAQ.
``MARKMIN``:inxx
This book has been written using the [[markmin syntax ../05#markmin_syntax]] and automatically converted to HTML, LaTeX and PDF.
This 6th edition of the book describes ``web2py`` 2.4.1 and later versions.
### Principles
Python programming typically follows these basic principles:
- Don't repeat yourself (DRY).
- There should be only one way of doing things.
- Explicit is better than implicit.
web2py fully embraces the first two principles by forcing the developer to use sound software
engineering practices that discourage repetition of code. web2py guides the developer through almost
all the tasks common in web application development (creating and processing forms, managing
sessions, cookies, errors, etc.).
``request``:inxx
web2py differs from other frameworks with regard to the third principle, which sometimes conflicts
with the other two. In particular, web2py does not import user applications, but executes them in a predefined context. This context exposes the Python keywords, as well as the web2py keywords.
To some this may appear as magic, but it should not.
Simply, in practice, some modules are already imported without you doing so.
web2py is trying to avoid the annoying characteristic of
web2py is composed of the following components:
web2py is distributed in source code, and in binary form for Microsoft Windows and for Mac OS X.
The source code distribution can be used in any platform where Python runs and includes the above-mentioned components.
To run the source code, you need Python 2.5, 2.6 or 2.7 pre-installed on the system. You also need one of the supported database engines installed.
For testing and light-demand applications, you can use the SQLite database, included with Python 2.7.
The binary versions of web2py (for Windows and Mac OS X) include a Python 2.7 interpreter and
the SQLite database. Technically, these two are not components of web2py. Including them in the binary distributions
enables you to run web2py out of the box.
The following image depicts the overall web2py structure:
[[image @///image/en300.png center 480px]]
At the bottom we find the interpreter. Moving up we find the web server (rocket), the libraries, and the applications. Each application consists for its own MVC design (models, controllers, views, modules, languages, databases, and static files). Each application includes it own database administration code (appadmin). Every web2py instance ships with three applications: welcome (the scaffolding app), admin (the web based IDE), and examples (copy of website and examples).
### About this book
This book includes the following chapters, besides this introduction:
+- [[Chapter 2 ../02]] is a minimalist introduction to Python. It assumes knowledge of both procedural and object-oriented programming concepts such as loops, conditions, function calls and classes, and covers basic Python syntax. It also covers examples of Python modules that are used throughout the book. If you already know Python, you may skip Chapter 2.
+- [[Chapter 3 ../03]] shows how to start web2py, discusses the administrative interface, and guides the reader through various examples of increasing complexity: an application that returns a string, a counter application, an image blog, and a full blown wiki application that allows image uploads and comments, provides authentication, authorization, web services and an RSS feed. While reading this chapter, you may need to refer to Chapter 2 for general Python syntax and to the following chapters for a more detailed reference about the functions that are used.
+- [[Chapter 4 ../04]] covers more systematically the core structure and libraries: URL mapping, request, response, sessions, caching, scheduler, cron, internationalization and general workflow.
+- [[Chapter 5 ../05]] is a reference for the template language used to build views. It shows how to embed Python code into HTML, and demonstrates the use of helpers (objects that can generate HTML).
+- [[Chapter 6 ../06]] covers the Database Abstraction Layer, or DAL. The syntax of the DAL is presented through a series of examples.
+- [[Chapter 7 ../07]] covers forms, form validation and form processing. FORM is the low level helper for form building. SQLFORM is the high level form builder. In Chapter 7 we also discuss Create/Read/Update/Delete (CRUD) API.
+- [[Chapter 8 ../08]] covers communication features as retrieving and sending emails and SMSes.
+- [[Chapter 9 ../09]] covers authentication, authorization and the extensible Role-Based Access Control mechanism available in web2py. Mail configuration and CAPTCHA are also discussed here, since they are used for authentication. In the third edition of the book we have added extensive coverage of integration with third-party authentication mechanisms such as OpenID, OAuth, Google, Facebook, LinkedIn, etc.
+- [[Chapter 10 ../10]] is about creating web services in web2py. We provide examples of integration with the Google Web Toolkit via Pyjamas, and with Adobe Flash via PyAMF.
+- [[Chapter 11 ../11]] is about web2py and jQuery recipes. web2py is designed mainly for server-side programming, but it includes jQuery, since we have found it to be the best open-source JavaScript library available for effects and Ajax. In this chapter, we discuss how to effectively use jQuery with web2py.
+- [[Chapter 12 ../12]] discusses web2py components and plugins as a way to build modular applications. We provide an example of a plugin that implements many commonly used functionality, such as charting, comments, and tagging.
+- [[Chapter 13 ../13]] is about production deployment of web2py applications. We specifically discuss the deployment on a LAMP web server (which we consider the main deployment alternative). We discuss alterantive web servers, and configuration of the PostgreSQL database. We discuss running as a service on a Microsoft Windows environment, and deployment on some specific platforms including Google Applications Engine, Heroku, and PythonAnywhere. In this chapter, we also discuss security and scalability issues.
+- [[Chapter 14 ../14]] contains a variety of other recipes to solve specific tasks, including upgrades, geocoding, pagination, the Twitter API, and more.
+- [[Chapter 15 ../15]] has information and helping and contributing to the project, with topics such as making bug reports and contributing changes to the code.
This book only covers basic web2py functionalities and the API that ships with web2py.
This book does not cover web2py appliances (i.e. ready made applications).
You can download web2py appliances from the corresponding web site ``appliances``:cite.
You can find additional topics discussed on the usergroup``usergroup``:cite. There is also AlterEgo``alterego``:cite, the old web2py blog and FAQ.
``MARKMIN``:inxx
This book has been written using the [[markmin syntax ../05#markmin_syntax]] and automatically converted to HTML, LaTeX and PDF.
### Support
The main support channel is the usergroup``usergroup``:cite, with dozens of posts every day. Even if you're a newbie, don't hesitate to ask - we'll be pleased to help you.
There is also a formal issue tracker system on http://code.google.com/p/web2py/issues . Last but not least, you can have professional support (see the web site for details).
### Contribute
Any help is really appreciated. You can help other users on the user group, or by directly submitting patches on the program (at the GitHub site https://github.com/web2py/web2py).
Even if you find a typo on this book, or have an improvement on it, the best way to help is by patching the book itself (which is under the source folder of the repository
at https://github.com/mdipierro/web2py-book).
+For more information on contributing, please see [[Chapter 15 ..\15]]
+[[web2py_style]]
### Elements of style
This 5th edition of the book describes ``web2py`` 2.4.1 and later versions.
### Principles
Python programming typically follows these basic principles:
- Don't repeat yourself (DRY).
- There should be only one way of doing things.
- Explicit is better than implicit.
web2py fully embraces the first two principles by forcing the developer to use sound software
engineering practices that discourage repetition of code. web2py guides the developer through almost
all the tasks common in web application development (creating and processing forms, managing
sessions, cookies, errors, etc.).
``request``:inxx
web2py differs from other frameworks with regard to the third principle, which sometimes conflicts
with the other two. In particular, web2py does not import user applications, but executes them in a predefined context. This context exposes the Python keywords, as well as the web2py keywords.
To some this may appear as magic, but it should not.
Simply, in practice, some modules are already imported without you doing so.
web2py is trying to avoid the annoying characteristic of
web2py is composed of the following components:
web2py is distributed in source code, and in binary form for Microsoft Windows and for Mac OS X.
The source code distribution can be used in any platform where Python runs and includes the above-mentioned components.
To run the source code, you need Python 2.5, 2.6 or 2.7 pre-installed on the system. You also need one of the supported database engines installed.
For testing and light-demand applications, you can use the SQLite database, included with Python 2.7.
The binary versions of web2py (for Windows and Mac OS X) include a Python 2.7 interpreter and
the SQLite database. Technically, these two are not components of web2py. Including them in the binary distributions
enables you to run web2py out of the box.
The following image depicts the overall web2py structure:
[[image @///image/en300.png center 480px]]
At the bottom we find the interpreter. Moving up we find the web server (rocket), the libraries, and the applications. Each application consists for its own MVC design (models, controllers, views, modules, languages, databases, and static files). Each application includes it own database administration code (appadmin). Every web2py instance ships with three applications: welcome (the scaffolding app), admin (the web based IDE), and examples (copy of website and examples).
### About this book
This book includes the following chapters, besides this introduction:
-- Chapter 2 is a minimalist introduction to Python. It assumes knowledge of both procedural and object-oriented programming concepts such as loops, conditions, function calls and classes, and covers basic Python syntax. It also covers examples of Python modules that are used throughout the book. If you already know Python, you may skip Chapter 2.
-- Chapter 3 shows how to start web2py, discusses the administrative interface, and guides the reader through various examples of increasing complexity: an application that returns a string, a counter application, an image blog, and a full blown wiki application that allows image uploads and comments, provides authentication, authorization, web services and an RSS feed. While reading this chapter, you may need to refer to Chapter 2 for general Python syntax and to the following chapters for a more detailed reference about the functions that are used.
-- Chapter 4 covers more systematically the core structure and libraries: URL mapping, request, response, sessions, caching, scheduler, cron, internationalization and general workflow.
-- Chapter 5 is a reference for the template language used to build views. It shows how to embed Python code into HTML, and demonstrates the use of helpers (objects that can generate HTML).
-- Chapter 6 covers the Database Abstraction Layer, or DAL. The syntax of the DAL is presented through a series of examples.
-- Chapter 7 covers forms, form validation and form processing. FORM is the low level helper for form building. SQLFORM is the high level form builder. In Chapter 7 we also discuss Create/Read/Update/Delete (CRUD) API.
-- Chapter 8 covers communication features as retrieving and sending emails and SMSes.
-- Chapter 9 covers authentication, authorization and the extensible Role-Based Access Control mechanism available in web2py. Mail configuration and CAPTCHA are also discussed here, since they are used for authentication. In the third edition of the book we have added extensive coverage of integration with third-party authentication mechanisms such as OpenID, OAuth, Google, Facebook, LinkedIn, etc.
-- Chapter 10 is about creating web services in web2py. We provide examples of integration with the Google Web Toolkit via Pyjamas, and with Adobe Flash via PyAMF.
-- Chapter 11 is about web2py and jQuery recipes. web2py is designed mainly for server-side programming, but it includes jQuery, since we have found it to be the best open-source JavaScript library available for effects and Ajax. In this chapter, we discuss how to effectively use jQuery with web2py.
-- Chapter 12 discusses web2py components and plugins as a way to build modular applications. We provide an example of a plugin that implements many commonly used functionality, such as charting, comments, and tagging.
-- Chapter 13 is about production deployment of web2py applications. We specifically discuss the deployment on a LAMP web server (which we consider the main deployment alternative). We discuss alterantive web servers, and configuration of the PostgreSQL database. We discuss running as a service on a Microsoft Windows environment, and deployment on some specific platforms including Google Applications Engine, Heroku, and PythonAnywhere. In this chapter, we also discuss security and scalability issues.
-- Chapter 14 contains a variety of other recipes to solve specific tasks, including upgrades, geocoding, pagination, the Twitter API, and more.
This book only covers basic web2py functionalities and the API that ships with web2py.
This book does not cover web2py appliances (i.e. ready made applications).
You can download web2py appliances from the corresponding web site ``appliances``:cite.
You can find additional topics discussed on the usergroup``usergroup``:cite. There is also AlterEgo``alterego``:cite, the old web2py blog and FAQ.
``MARKMIN``:inxx
This book has been written using the markmin syntax and automatically converted to HTML, LaTeX and PDF.
### Support
The main support channel is the usergroup``usergroup``:cite, with dozens of posts every day. Even if you're a newbie, don't hesitate to ask - we'll be pleased to help you.
There is also a formal issue tracker system on http://code.google.com/p/web2py/issues . Last but not least, you can have professional support (see the web site for details).
### Contribute
Any help is really appreciated. You can help other users on the user group, or by directly submitting patches on the program (at the GitHub site https://github.com/web2py/web2py).
Even if you find a typo on this book, or have an improvement on it, the best way to help is by patching the book itself (which is under the source folder of the repository
at https://github.com/mdipierro/web2py-book).
### Elements of style
In the diagram:
- The Server can be the web2py built-in web server or a third-party server, such as Apache. The Server handles multi-threading.
- "main" is the main WSGI application. It performs all common tasks and wraps user applications. It deals with cookies, sessions, transactions, URL routing and reverse routing, and dispatching.
It can serve and stream static files if the web server is not doing it yet.
- The Models, Views and Controller components make up the user application.
- Multiple applications can be hosted in the same web2py instance.
- The dashed arrows represent communication with the database engine(s). The database queries can be written in raw SQL (discouraged) or by using the web2py Database Abstraction Layer (recommended), so that web2py application code is not dependent on the specific database engine.
- The dispatcher maps the requested URL to a function call in the controller. The output of the function can be a string or a dictionary of symbols (a hash table). The data in the dictionary is rendered by a view. If the visitor requests an HTML page (the default), the dictionary is rendered into an HTML page. If the visitor requests the same page in XML, web2py tries to find a view that can render the dictionary in XML. The developer can create views to render pages in any of the already supported protocols (HTML, XML, JSON, RSS, CSV, and RTF) or in additional custom protocols.
- All calls are wrapped into a transaction, and any uncaught exception causes the transaction to be rolled back. If the request succeeds, the transaction is committed.
- web2py also handles sessions and session cookies automatically, and when a transaction is committed, the session is also stored, unless specified otherwise.
- It is possible to register recurrent tasks (via cron) to run at scheduled times and/or after the completion of certain actions. In this way it is possible to run long and compute-intensive tasks in the background without slowing down navigation.
Here is a minimal and complete MVC application, consisting of three files:
**"db.py" is the model:**
``
db = DAL('sqlite://storage.sqlite')
db.define_table('contact',
Field('name'),
Field('phone'))
``:code
It connects to the database (in this example a SQLite database stored in the ``storage.sqlite`` file) and
and returns the grid to the view.
This view is called automatically by web2py after the associated controller function (action) is executed.
The purpose of this view is to render the variables in the returned dictionary (in our case ``grid``) into HTML.
The view file is written in HTML, but it embeds Python code delimited by the special ``{{`` and ``}}``
delimiters. This is quite different from the PHP code example, because the only code
embedded into the HTML is "presentation layer" code. The "layout.html" file referenced at the top of the
view is provided by web2py and constitutes the basic layout for all web2py applications. The layout file can
easily be modified or replaced.
### Why web2py
web2py is one of many web application frameworks, but it has compelling and unique features.
web2py was originally developed as a teaching tool, with the following primary motivations:
- Easy for users to learn server-side web development without compromising functionality. For this reason, web2py requires no installation and no configuration, has no dependencies (except for the source code distribution, which requires Python 2.5 and its standard library modules), and exposes most of its functionality via a Web interface, including an Integrated Development Environment with Debugger and database interface.
- web2py has been stable from day one because it follows a top-down design; i.e., its API was designed before it was implemented. Even as new functionality has been added, web2py has never broken backwards compatibility, and it will not break compatibility when additional functionality is added in the future.
- web2py proactively addresses the most important security issues which plague many modern web applications, as determined by OWASP``owasp``:cite below.
- web2py is lightweight. Its core libraries, including the Database Abstraction Layer, the template language, and all the helpers amount to 1.4MB. The entire source code including sample applications and images amounts to 10.4MB.
- web2py has a small footprint and is very fast. It uses the Rocket``rocket``:cite WSGI web server developed by Timothy Farrell. It is as fast as Apache with mod_wsgi, and supports SSL and IPv6.
- web2py uses Python syntax for models, controllers, and views, but does not import models and controllers (as all the other Python frameworks do) - instead it executes them. This means that apps can be installed, uninstalled, and modified without having to restart the web server (even in production), and different apps can coexist without their modules interfering with one another.
- web2py uses a Database Abstraction Layer (DAL) instead of an Object Relational Mapper (ORM). From a conceptual point of view, this means that different database tables are mapped into different instances of one ``Table`` class and not into different classes, while records are mapped into instances of one ``Row`` class, not into instances of the corresponding table class. From a practical point of view, it means that SQL syntax maps almost one-to-one into DAL syntax, and there is no complex metaclass programming going on under the hood as in popular ORMs, which would add latency.
WSGI ``wsgi-w``:cite ``wsgi-o``:cite (Web Server Gateway Interface) is an emerging Python standard for communication between a web server and Python applications.
Here is a screenshot of the main web2py **admin** interface:
[[image @///image/en200.png center 480px]]
### Security
``security``:inxx
The Open Web Application Security Project``owasp``:cite (OWASP) is a free and open worldwide community focused
on improving the security of application software.
OWASP has listed the top ten security issues that put web applications at risk.
That list is reproduced here, along with a description of how each issue is addressed by web2py:
- ``cross site scripting``:inxx "Cross Site Scripting (XSS): XSS flaws occur whenever an application takes user supplied data and sends it to a web browser without first validating or encoding that content. XSS allows attackers to execute scripts in the victim's browser which can hijack user sessions, deface web sites, possibly introduce worms, etc." ''web2py, by default, escapes all variables rendered in the view, preventing XSS.''
- ``injection flaws``:inxx "Injection Flaws: Injection flaws, particularly SQL injection, are common in web applications. Injection occurs when user-supplied data is sent to an interpreter as part of a command or query. The attacker's hostile data tricks the interpreter into executing unintended commands or changing data." ''web2py includes a Database Abstraction Layer that makes SQL injection impossible. Normally, SQL statements are not written by the developer. Instead, SQL is generated dynamically by the DAL, ensuring that all inserted data is properly escaped.''
- ``malicious file execution``:inxx "Malicious File Execution: Code vulnerable to remote file inclusion (RFI) allows attackers to include hostile code and data, resulting in devastating attacks, such as total server compromise." ''web2py allows only exposed functions to be executed, preventing malicious file execution. Imported functions are never exposed; only actions are exposed. web2py uses a Web-based administration interface which makes it very easy to keep track of what is exposed and what is not.''
- ``insecure object reference``:inxx "Insecure Direct Object Reference: A direct object reference occurs when a developer exposes a reference to an internal implementation object, such as a file, directory, database record, or key, as a URL or form parameter. Attackers can manipulate those references to access other objects without authorization." ''web2py does not expose any internal objects; moreover, web2py validates all URLs, thus preventing directory traversal attacks. web2py also provides a simple mechanism to create forms that automatically validate all input values.''
- ``CSRF``:inxx "Cross Site Request Forgery (CSRF): A CSRF attack forces a logged-on victim's browser to send a pre-authenticated request to a vulnerable web application, which then forces the victim's browser to perform a hostile action to the benefit of the attacker. CSRF can be as powerful as the web application that it attacks." ''web2py prevents CSRF as well as accidental double submission of forms by assigning a one-time random token to each form. Moreover web2py uses UUID for session cookie.''
- ``information leakage``:inxx ``improper error handling``:inxx "Information Leakage and Improper Error Handling: Applications can unintentionally leak information about their configuration, internal workings, or violate privacy through a variety of application problems. Attackers use this weakness to steal sensitive data, or conduct more serious attacks." ''web2py includes a ticketing system. No error can result in code being exposed to the users. All errors are logged and a ticket is issued to the user that allows error tracking. But errors and source code are accessible only to the administrator.''
- "Broken Authentication and Session Management: Account credentials and session tokens are often not properly protected. Attackers compromise passwords, keys, or authentication tokens to assume other users' identities." ''web2py provides a built-in mechanism for administrator authentication, and it manages sessions independently for each application. The administrative interface also forces the use of secure session cookies when the client is not "localhost". For applications, it includes a powerful Role Based Access Control API.''
Igor Gassko,
Ismael Serratos,
Jan Beilicke,
Jay Kelkar,
Jeff Bauer,
Jesus Matrinez,
Jim Karsten,
Joachim Breitsprecher,
Joakim Eriksson,
Joe Barnhart,
Joel Carrier,
Joel Samuelsson,
John Heenan,
Jon Romero,
Jonas Rundberg,
Jonathan Benn,
Jonathan Lundell,
Jose Jachuf,
Joseph Piron,
Josh Goldfoot,
Josh Jaques,
Jose Vicente de Sousa,
Jurgis Pralgauskis,
Keith Yang,
Kenji Hosoda,
Kenneth Lundstr,
Kirill Spitsin,
Kyle Smith,
Larry Weinberg,
Limodou,
Loren McGinnis,
Louis DaPrato,
Luca De Alfaro,
Luca Zachetti,
Lucas D'Avila,
In the diagram:
- The Server can be the web2py built-in web server or a third-party server, such as Apache. The Server handles multi-threading.
- "main" is the main WSGI application. It performs all common tasks and wraps user applications. It deals with cookies, sessions, transactions, URL routing and reverse routing, and dispatching.
It can serve and stream static files if the web server is not doing it already.
- The Models, Views and Controller components make up the user application.
- Multiple applications can be hosted in the same web2py instance.
- The dashed arrows represent communication with the database engine(s). The database queries can be written in raw SQL (discouraged) or by using the web2py Database Abstraction Layer (recommended), so that web2py application code is not dependent on the specific database engine.
- The dispatcher maps the requested URL to a function call in the controller. The output of the function can be a string or a dictionary of symbols (a hash table). The data in the dictionary is rendered by a view. If the visitor requests an HTML page (the default), the dictionary is rendered into an HTML page. If the visitor requests the same page in XML, web2py tries to find a view that can render the dictionary in XML. The developer can create views to render pages in any of the already supported protocols (HTML, XML, JSON, RSS, CSV, and RTF) or in additional custom protocols.
- All calls are wrapped into a transaction, and any uncaught exception causes the transaction to be rolled back. If the request succeeds, the transaction is committed.
- web2py also handles sessions and session cookies automatically, and when a transaction is committed, the session is also stored, unless specified otherwise.
- It is possible to register recurrent tasks (via cron) to run at scheduled times and/or after the completion of certain actions. In this way it is possible to run long and compute-intensive tasks in the background without slowing down navigation.
Here is a minimal and complete MVC application, consisting of three files:
**"db.py" is the model:**
``
db = DAL('sqlite://storage.sqlite')
db.define_table('contact',
Field('name'),
Field('phone'))
``:code
It connects to the database (in this example a SQLite database stored in the ``storage.sqlite`` file) and
and returns the grid to the view.
This view is called automatically by web2py after the associated controller function (action) is executed.
The purpose of this view is to render the variables in the returned dictionary (in our case ``grid``) into HTML.
The view file is written in HTML, but it embeds Python code delimited by the special ``{{`` and ``}}``
delimiters. This is quite different from the PHP code example, because the only code
embedded into the HTML is "presentation layer" code. The "layout.html" file referenced at the top of the
view is provided by web2py and constitutes the basic layout for all web2py applications. The layout file can
easily be modified or replaced.
### Why web2py
web2py is one of many web application frameworks, but it has compelling and unique features.
web2py was originally developed as a teaching tool, with the following primary motivations:
- Easy for users to learn server-side web development without compromising functionality. For this reason, web2py requires no installation and no configuration, has no dependencies (except for the source code distribution, which requires Python 2.5 and its standard library modules), and exposes most of its functionality via a Web interface, including an Integrated Development Environment with Debugger and database interface.
- web2py has been stable from day one because it follows a top-down design; i.e., its API was designed before it was implemented. Even as new functionality has been added, web2py has never broken backwards compatibility, and it will not break compatibility when additional functionality is added in the future.
- web2py proactively addresses the most important security issues which plague many modern web applications, as determined by OWASP``owasp``:cite below.
- web2py is lightweight. Its core libraries, including the Database Abstraction Layer, the template language, and all the helpers amount to 1.4MB. The entire source code including sample applications and images amounts to 10.4MB.
- web2py has a small footprint and is very fast. It uses the Rocket``rocket``:cite WSGI web server developed by Timothy Farrell. It is as fast as Apache with mod_wsgi, and supports SSL and IPv6.
- web2py uses Python syntax for models, controllers, and views, but does not import models and controllers (as all the other Python frameworks do) - instead it executes them. This means that apps can be installed, uninstalled, and modified without having to restart the web server (even in production), and different apps can coexist without their modules interfering with one another.
- web2py uses a Database Abstraction Layer (DAL) instead of an Object Relational Mapper (ORM). From a conceptual point of view, this means that different database tables are mapped into different instances of one ``Table`` class and not into different classes, while records are mapped into instances of one ``Row`` class, not into instances of the corresponding table class. From a practical point of view, it means that SQL syntax maps almost one-to-one into DAL syntax, and there is no complex metaclass programming going on under the hood as in popular ORMs, which would add latency.
WSGI ``wsgi-w``:cite ``wsgi-o``:cite (Web Server Gateway Interface) is an emerging Python standard for communication between a web server and Python applications).
Here is a screenshot of the main web2py **admin** interface:
[[image @///image/en200.png center 480px]]
### Security
``security``:inxx
The Open Web Application Security Project``owasp``:cite (OWASP) is a free and open worldwide community focused
on improving the security of application software.
OWASP has listed the top ten security issues that put web applications at risk.
That list is reproduced here, along with a description of how each issue is addressed by web2py:
- ``cross site scripting``:inxx "Cross Site Scripting (XSS): XSS flaws occur whenever an application takes user supplied data and sends it to a web browser without first validating or encoding that content. XSS allows attackers to execute scripts in the victim's browser which can hijack user sessions, deface web sites, possibly introduce worms, etc." ''web2py, by default, escapes all variables rendered in the view, preventing XSS.''
- ``injection flaws``:inxx "Injection Flaws: Injection flaws, particularly SQL injection, are common in web applications. Injection occurs when user-supplied data is sent to an interpreter as part of a command or query. The attacker's hostile data tricks the interpreter into executing unintended commands or changing data." ''web2py includes a Database Abstraction Layer that makes SQL injection impossible. Normally, SQL statements are not written by the developer. Instead, SQL is generated dynamically by the DAL, ensuring that all inserted data is properly escaped.''
- ``malicious file execution``:inxx "Malicious File Execution: Code vulnerable to remote file inclusion (RFI) allows attackers to include hostile code and data, resulting in devastating attacks, such as total server compromise." ''web2py allows only exposed functions to be executed, preventing malicious file execution. Imported functions are never exposed; only actions are exposed. web2py uses a Web-based administration interface which makes it very easy to keep track of what is exposed and what is not.''
- ``insecure object reference``:inxx "Insecure Direct Object Reference: A direct object reference occurs when a developer exposes a reference to an internal implementation object, such as a file, directory, database record, or key, as a URL or form parameter. Attackers can manipulate those references to access other objects without authorization." ''web2py does not expose any internal objects; moreover, web2py validates all URLs, thus preventing directory traversal attacks. web2py also provides a simple mechanism to create forms that automatically validate all input values.''
- ``CSRF``:inxx "Cross Site Request Forgery (CSRF): A CSRF attack forces a logged-on victim's browser to send a pre-authenticated request to a vulnerable web application, which then forces the victim's browser to perform a hostile action to the benefit of the attacker. CSRF can be as powerful as the web application that it attacks." ''web2py prevents CSRF as well as accidental double submission of forms by assigning a one-time random token to each form. Moreover web2py uses UUID for session cookie.''
- ``information leakage``:inxx ``improper error handling``:inxx "Information Leakage and Improper Error Handling: Applications can unintentionally leak information about their configuration, internal workings, or violate privacy through a variety of application problems. Attackers use this weakness to steal sensitive data, or conduct more serious attacks." ''web2py includes a ticketing system. No error can result in code being exposed to the users. All errors are logged and a ticket is issued to the user that allows error tracking. But errors and source code are accessible only to the administrator.''
- "Broken Authentication and Session Management: Account credentials and session tokens are often not properly protected. Attackers compromise passwords, keys, or authentication tokens to assume other users' identities." ''web2py provides a built-in mechanism for administrator authentication, and it manages sessions independently for each application. The administrative interface also forces the use of secure session cookies when the client is not "localhost". For applications, it includes a powerful Role Based Access Control API.''
Igor Gassko,
Ismael Serratos,
Jan Beilicke,
Jay Kelkar,
Jeff Bauer,
Jesus Matrinez,
Jim Karsten,
Joachim Breitsprecher,
Joakim Eriksson,
Joe Barnhart,
Joel Carrier,
Joel Samuelsson,
John Heenan,
Jon Romero,
Jonas Rundberg,
Jonathan Benn,
Jonathan Lundell,
Jose Jachuf,
Joseph Piron,
Josh Goldfoot,
Josh Jaques,
José Vicente de Sousa,
Jurgis Pralgauskis,
Keith Yang,
Kenji Hosoda,
Kenneth Lundstr,
Kirill Spitsin,
Kyle Smith,
Larry Weinberg,
Limodou,
Loren McGinnis,
Louis DaPrato,
Luca De Alfaro,
Luca Zachetti,
Lucas D'Ávila,
This book includes the following chapters, besides this introduction:
- Chapter 2 is a minimalist introduction to Python. It assumes knowledge of both procedural and object-oriented programming concepts such as loops, conditions, function calls and classes, and covers basic Python syntax. It also covers examples of Python modules that are used throughout the book. If you already know Python, you may skip Chapter 2.
- Chapter 3 shows how to start web2py, discusses the administrative interface, and guides the reader through various examples of increasing complexity: an application that returns a string, a counter application, an image blog, and a full blown wiki application that allows image uploads and comments, provides authentication, authorization, web services and an RSS feed. While reading this chapter, you may need to refer to Chapter 2 for general Python syntax and to the following chapters for a more detailed reference about the functions that are used.
- Chapter 4 covers more systematically the core structure and libraries: URL mapping, request, response, sessions, caching, scheduler, cron, internationalization and general workflow.
- Chapter 5 is a reference for the template language used to build views. It shows how to embed Python code into HTML, and demonstrates the use of helpers (objects that can generate HTML).
- Chapter 6 covers the Database Abstraction Layer, or DAL. The syntax of the DAL is presented through a series of examples.
- Chapter 7 covers forms, form validation and form processing. FORM is the low level helper for form building. SQLFORM is the high level form builder. In Chapter 7 we also discuss Create/Read/Update/Delete (CRUD) API.
- Chapter 8 covers communication features as retrieving and sending emails and SMSes.
- Chapter 9 covers authentication, authorization and the extensible Role-Based Access Control mechanism available in web2py. Mail configuration and CAPTCHA are also discussed here, since they are used for authentication. In the third edition of the book we have added extensive coverage of integration with third-party authentication mechanisms such as OpenID, OAuth, Google, Facebook, LinkedIn, etc.
- Chapter 10 is about creating web services in web2py. We provide examples of integration with the Google Web Toolkit via Pyjamas, and with Adobe Flash via PyAMF.
- Chapter 11 is about web2py and jQuery recipes. web2py is designed mainly for server-side programming, but it includes jQuery, since we have found it to be the best open-source JavaScript library available for effects and Ajax. In this chapter, we discuss how to effectively use jQuery with web2py.
- Chapter 12 discusses web2py components and plugins as a way to build modular applications. We provide an example of a plugin that implements many commonly used functionality, such as charting, comments, and tagging.
- Chapter 13 is about production deployment of web2py applications. We specifically discuss the deployment on a LAMP web server (which we consider the main deployment alternative). We discuss alterantive web servers, and configuration of the PostgreSQL database. We discuss running as a service on a Microsoft Windows environment, and deployment on some specific platforms including Google Applications Engine, Heroku, and PythonAnywhere. In this chapter, we also discuss security and scalability issues.
- Chapter 14 contains a variety of other recipes to solve specific tasks, including upgrades, geocoding, pagination, the Twitter API, and more.
This book includes the following chapters, besides this introduction:
- Chapter 2 is a minimalist introduction to Python. It assumes knowledge of both procedural and object-oriented programming concepts such as loops, conditions, function calls and classes, and covers basic Python syntax. It also covers examples of Python modules that are used throughout the book. If you already know Python, you may skip Chapter 2.
- Chapter 3 shows how to start web2py, discusses the administrative interface, and guides the reader through various examples of increasing complexity: an application that returns a string, a counter application, an image blog, and a full blown wiki application that allows image uploads and comments, provides authentication, authorization, web services and an RSS feed. While reading this chapter, you may need to refer to Chapter 2 for general Python syntax and to the following chapters for a more detailed reference about the functions that are used.
- Chapter 4 covers more systematically the core structure and libraries: URL mapping, request, response, sessions, caching, schedulre, cron, internationalization and general workflow.
- Chapter 5 is a reference for the template language used to build views. It shows how to embed Python code into HTML, and demonstrates the use of helpers (objects that can generate HTML).
- Chapter 6 covers the Database Abstraction Layer, or DAL. The syntax of the DAL is presented through a series of examples.
- Chapter 7 covers forms, form validation and form processing. FORM is the low level helper for form building. SQLFORM is the high level form builder. In Chapter 7 we also discuss Create/Read/Update/Delete (CRUD) API.
- Chapter 8 covers communication features as retrieving and sending emails and SMSes.
- Chapter 9 covers authentication, authorization and the extensible Role-Based Access Control mechanism available in web2py. Mail configuration and CAPTCHA are also discussed here, since they are used for authentication. In the third edition of the book we have added extensive coverage of integration with third-party authentication mechanisms such as OpenID, OAuth, Google, Facebook, LinkedIn, etc.
- Chapter 10 is about creating web services in web2py. We provide examples of integration with the Google Web Toolkit via Pyjamas, and with Adobe Flash via PyAMF.
- Chapter 11 is about web2py and jQuery recipes. web2py is designed mainly for server-side programming, but it includes jQuery, since we have found it to be the best open-source JavaScript library available for effects and Ajax. In this chapter, we discuss how to effectively use jQuery with web2py.
- Chapter 12 discusses web2py components and plugins as a way to build modular applications. We provide an example of a plugin that implements many commonly used functionality, such as charting, comments, and tagging.
- Chapter 13 is about production deployment of web2py applications. We specifically discuss the deployment on a LAMP web server (which we consider the main deployment alternative). We discuss alterantive web servers, and configuration of the PostgreSQL database. We discuss running as a service on a Microsoft Windows environment, and deployment on some specific platforms including Google Applications Engine, Heorku, and PythonAnywhere. In this chapter, we also discuss security and scalability issues.
- Chapter 14 contains a variety of other recipes to solve specific tasks, including upgrades, geocoding, pagination, the Twitter API, and more.
web2py includes a Database Abstraction Layer (DAL) that writes SQL``sql-w``:cite dynamically so that you, the developer, don't have to. The DAL knows how to generate SQL transparently for
SQLite``sqlite``:cite, MySQL``mysql``:cite, PostgreSQL``postgres``:cite, MSSQL``mssql``:cite,
+FireBird``firebird``:cite, Oracle``oracle``:cite, IBM DB2``db2``:cite, Informix``informix``:cite and Ingres``ingresdb``:cite.
+
The DAL can also generate function calls for the Google Datastore
when running on the Google App Engine (GAE)``gae``:cite.
Experimentally we support more databases and new ones are constantly added.
Please check on the web2py web site and mailing list for more recent adapters.
Once one or more database tables are defined, web2py automatically generates a fully functional web-based database
administration interface to access the database and the tables.
web2py includes a Database Abstraction Layer (DAL) that writes SQL``sql-w``:cite dynamically so that you, the developer, don't have to. The DAL knows how to generate SQL transparently for
SQLite``sqlite``:cite, MySQL``mysql``:cite, PostgreSQL``postgres``:cite, MSSQL``mssql``:cite,
-FireBird``firebird``:cite, Oracle``oracle``:cite, IBM DB2``db2``:cite, Informix``informix``:cite,
-Ingres``ingresdb``:cite, and MongoDB``mongodb``:cite.
The DAL can also generate function calls for the Google Datastore
when running on the Google App Engine (GAE)``gae``:cite.
Experimentally we support more databases and new ones are constantly added.
Please check on the web2py web site and mailing list for more recent adapters.
Once one or more database tables are defined, web2py automatically generates a fully functional web-based database
administration interface to access the database and the tables.
The source code distribution can be used in any platform where Python runs and includes the above-mentioned components.
To run the source code, you need Python 2.5, 2.6 or 2.7 pre-installed on the system. You also need one of the supported database engines installed.
For testing and light-demand applications, you can use the SQLite database, included with Python 2.7.
The binary versions of web2py (for Windows and Mac OS X) include a Python 2.7 interpreter and
the SQLite database. Technically, these two are not components of web2py. Including them in the binary distributions
enables you to run web2py out of the box.
The following image depicts the overall web2py structure:
[[image @///image/en300.png center 480px]]
At the bottom we find the interpreter. Moving up we find the web server (rocket), the libraries, and the applications. Each application consists for its own MVC design (models, controllers, views, modules, languages, databases, and static files). Each application includes it own database administration code (appadmin). Every web2py instance ships with three applications: welcome (the scaffolding app), admin (the web based IDE), and examples (copy of website and examples).
### About this book
This book includes the following chapters, besides this introduction:
- Chapter 2 is a minimalist introduction to Python. It assumes knowledge of both procedural and object-oriented programming concepts such as loops, conditions, function calls and classes, and covers basic Python syntax. It also covers examples of Python modules that are used throughout the book. If you already know Python, you may skip Chapter 2.
- Chapter 3 shows how to start web2py, discusses the administrative interface, and guides the reader through various examples of increasing complexity: an application that returns a string, a counter application, an image blog, and a full blown wiki application that allows image uploads and comments, provides authentication, authorization, web services and an RSS feed. While reading this chapter, you may need to refer to Chapter 2 for general Python syntax and to the following chapters for a more detailed reference about the functions that are used.
- Chapter 4 covers more systematically the core structure and libraries: URL mapping, request, response, sessions, caching, schedulre, cron, internationalization and general workflow.
- Chapter 5 is a reference for the template language used to build views. It shows how to embed Python code into HTML, and demonstrates the use of helpers (objects that can generate HTML).
- Chapter 6 covers the Database Abstraction Layer, or DAL. The syntax of the DAL is presented through a series of examples.
- Chapter 7 covers forms, form validation and form processing. FORM is the low level helper for form building. SQLFORM is the high level form builder. In Chapter 7 we also discuss Create/Read/Update/Delete (CRUD) API.
- Chapter 8 covers communication features as retrieving and sending emails and SMSes.
- Chapter 9 covers authentication, authorization and the extensible Role-Based Access Control mechanism available in web2py. Mail configuration and CAPTCHA are also discussed here, since they are used for authentication. In the third edition of the book we have added extensive coverage of integration with third-party authentication mechanisms such as OpenID, OAuth, Google, Facebook, LinkedIn, etc.
- Chapter 10 is about creating web services in web2py. We provide examples of integration with the Google Web Toolkit via Pyjamas, and with Adobe Flash via PyAMF.
- Chapter 11 is about web2py and jQuery recipes. web2py is designed mainly for server-side programming, but it includes jQuery, since we have found it to be the best open-source JavaScript library available for effects and Ajax. In this chapter, we discuss how to effectively use jQuery with web2py.
- Chapter 12 discusses web2py components and plugins as a way to build modular applications. We provide an example of a plugin that implements many commonly used functionality, such as charting, comments, and tagging.
- Chapter 13 is about production deployment of web2py applications. We specifically discuss the deployment on a LAMP web server (which we consider the main deployment alternative). We discuss alterantive web servers, and configuration of the PostgreSQL database. We discuss running as a service on a Microsoft Windows environment, and deployment on some specific platforms including Google Applications Engine, Heorku, and PythonAnywhere. In this chapter, we also discuss security and scalability issues.
- Chapter 14 contains a variety of other recipes to solve specific tasks, including upgrades, geocoding, pagination, the Twitter API, and more.
This book only covers basic web2py functionalities and the API that ships with web2py.
This book does not cover web2py appliances (i.e. ready made applications).
You can download web2py appliances from the corresponding web site ``appliances``:cite.
You can find additional topics discussed on the usergroup``usergroup``:cite. There is also AlterEgo``alterego``:cite, the old web2py blog and FAQ.
``MARKMIN``:inxx
This book has been written using the markmin syntax and automatically converted to HTML, LaTeX and PDF.
### Support
The main support channel is the usergroup``usergroup``:cite, with dozens of posts every day. Even if you're a newbie, don't hesitate to ask - we'll be pleased to help you.
There is also a formal issue tracker system on http://code.google.com/p/web2py/issues . Last but not least, you can have professional support (see the web site for details).
### Contribute
Any help is really appreciated. You can help other users on the user group, or by directly submitting patches on the program (at the GitHub site https://github.com/web2py/web2py).
Even if you find a typo on this book, or have an improvement on it, the best way to help is by patching the book itself (which is under the source folder of the repository
at https://github.com/mdipierro/web2py-book).
### Elements of style
PEP8 ``style``:cite contains good style practices when programming with Python. You will find
that web2py does not always follow these rules. This is not because of omissions or negligence; it is our
belief that the users of web2py should follow these rules and we encourage it. We chose not to
follow some of those rules when defining web2py helper objects in order to minimize the probability
of name conflict with objects defined by the user.
For example, the class that represents a ``<div>`` is called ``DIV``, while according to the
Python style reference it should have been called ``Div``. We believe that, for this specific example that
using an all-upper-case "DIV" is a more natural choice. Moreover, this approach leaves programmers
free to create a class called "Div" if they choose to do so.
Our syntax also maps naturally into the DOM notation of most browsers (including, for example, Firefox).
variables. Continuing with our example, even considering that ``DIV`` is a class
it is a special class that should never be modified by
the user because doing so would break other web2py applications.
Hence, we believe this qualifies the ``DIV`` class as
something that should be treated as a constant, further justifying our choice of notation.
In summary, the following conventions are followed:
- HTML helpers and validators are all upper case for the reasons discussed above (for example ``DIV``, ``A``, ``FORM``, ``URL``).
- The translator object ``T`` is upper case despite the fact that it is an instance of a class and not a class itself. Logically the translator object performs an action similar to the HTML helpers, it affects rendering part of the presentation. Also, ``T`` needs to be easy to locate in the code and must have a short name.
- DAL classes follow the Python style guide (first letter capitalized), for example ``Table``, ``Field``, ``Query``, ``Row``, ``Rows``, etc.
In all other cases we believe we have followed, as much as possible,
the Python Style Guide (PEP8).
For example all instance objects are lower-case (request, response, session, cache), and all internal classes are capitalized.
In all the examples of this book, web2py keywords are shown in bold, while strings and comments are shown in italic.
### License
``license``:inxx
web2py is licensed under the LGPL version 3 License. The full text of the license is available in ref.``lgpl3``:cite.
In accordance with LGPL you may:
- redistribute web2py with your apps (including official web2py binary versions)
- release your applications which use official web2py libraries under any license you wish
Yet you must:
- make clear in the documentation that your application uses web2py
- release any modification of the web2py libraries under the LGPLv3 license
The license includes the usual disclaimer:
THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW.
EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES
PROVIDE THE PROGRAM “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED,
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE
PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL
NECESSARY SERVICING, REPAIR OR CORRECTION.
IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT
HOLDER, OR ANY OTHER PARTY WHO MODIFIES AND/OR CONVEYS THE PROGRAM AS PERMITTED ABOVE,
BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL
DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED
TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES
OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER
PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
**Earlier versions**
Earlier versions of web2py, 1.0.*-1.90.*, were released under the GPL2 license plus a
commercial exception which, for practical purposes, was very similar to the current LGPLv3.
The source code distribution can be used in any platform where Python runs and includes the above-mentioned components.
To run the source code, you need Python 2.5 or 2.7 pre-installed on the system. You also need one of the supported database engines installed.
For testing and light-demand applications, you can use the SQLite database, included with Python 2.7.
The binary versions of web2py (for Windows and Mac OS X) include a Python 2.7 interpreter and
the SQLite database. Technically, these two are not components of web2py. Including them in the binary distributions
enables you to run web2py out of the box.
The following image depicts the overall web2py structure:
[[image @///image/en300.png center 480px]]
At the bottom we find the interpreter. Moving up we find the web server (rocket), the libraries, and the applications. Each application consists for its own MVC design (models, controllers, views, modules, languages, databases, and static files). Each application includes it own database administration code (appadmin). Every web2py instance ships with three applications: welcome (the scaffolding app), admin (the web based IDE), and examples (copy of website and examples).
### About this book
This book includes the following chapters, besides this introduction:
- Chapter 2 is a minimalist introduction to Python. It assumes knowledge of both procedural and object-oriented programming concepts such as loops, conditions, function calls and classes, and covers basic Python syntax. It also covers examples of Python modules that are used throughout the book. If you already know Python, you may skip Chapter 2.
- Chapter 3 shows how to start web2py, discusses the administrative interface, and guides the reader through various examples of increasing complexity: an application that returns a string, a counter application, an image blog, and a full blown wiki application that allows image uploads and comments, provides authentication, authorization, web services and an RSS feed. While reading this chapter, you may need to refer to Chapter 2 for general Python syntax and to the following chapters for a more detailed reference about the functions that are used.
- Chapter 4 covers more systematically the core structure and libraries: URL mapping, request, response, sessions, caching, schedulre, cron, internationalization and general workflow.
- Chapter 5 is a reference for the template language used to build views. It shows how to embed Python code into HTML, and demonstrates the use of helpers (objects that can generate HTML).
- Chapter 6 covers the Database Abstraction Layer, or DAL. The syntax of the DAL is presented through a series of examples.
- Chapter 7 covers forms, form validation and form processing. FORM is the low level helper for form building. SQLFORM is the high level form builder. In Chapter 7 we also discuss Create/Read/Update/Delete (CRUD) API.
- Chapter 8 covers communication with as sending emails and SMSes.
- Chapter 9 covers authentication, authorization and the extensible Role-Based Access Control mechanism available in web2py. Mail configuration and CAPTCHA are also discussed here, since they are used for authentication. In the third edition of the book we have added extensive coverage of integration with third-party authentication mechanisms such as OpenID, OAuth, Google, Facebook, LinkedIn, etc.
- Chapter 10 is about creating web services in web2py. We provide examples of integration with the Google Web Toolkit via Pyjamas, and with Adobe Flash via PyAMF.
- Chapter 11 is about web2py and jQuery recipes. web2py is designed mainly for server-side programming, but it includes jQuery, since we have found it to be the best open-source JavaScript library available for effects and Ajax. In this chapter, we discuss how to effectively use jQuery with web2py.
- Chapter 12 discusses web2py components and plugins as a way to build modular applications. We provide an example of a plugin that implements many commonly used functionality, such as charting, comments, and tagging.
- Chapter 13 is about production deployment of web2py applications. We specifically discuss the deployment on a LAMP web server (which we consider the main deployment alternative). We discuss alterantive web servers, and configuration of the PostgreSQL database. We discuss running as a service on a Microsoft Windows environment, and deployment on some specific platforms including Google Applications Engine, Heorku, and PythonAnywhere. In this chapter, we also discuss security and scalability issues.
- Chapter 14 contains a variety of other recipes to solve specific tasks, including upgrades, geocoding, pagination, the Twitter API, and more.
This book only covers basic web2py functionalities and the API that ships with web2py.
This book does not cover web2py appliances (i.e. ready made applications).
You can download web2py appliances from the corresponding web site ``appliances``:cite.
You can find additional topics discussed on the usergroup``usergroup``:cite. There is also AlterEgo``alterego``:cite, the old web2py blog and FAQ.
``MARKMIN``:inxx
This book has been written using the markmin syntax and automatically converted to HTML, LaTeX and PDF.
### Support
The main support channel is the usergroup``usergroup``:cite, with dozens of posts every day. Even if you're a newbie, don't hesitate to ask - we'll be pleased to help you.
There is also a formal issue tracker system on http://code.google.com/p/web2py/issue . Last but not least, you can have professional support (see the web site for details).
### Contribute
Any help is really appreciated. You can help other users on the user group, or by directly submitting patches on the program (at the GitHub site https://github.com/web2py/web2py).
Even if you find a typo on this book, or have an improvement on it, the best way to help is by patching the book itself (which is under the source folder of the repository
at https://github.com/mdipierro/web2py-book).
### Elements of style
PEP8 ``style``:cite contains good style practices when programming with Python. You will find
that web2py does not always follow these rules. This is not because of omissions or negligence; it is our
belief that the users of web2py should follow these rules and we encourage it. We chose not to
follow some of those rules when defining web2py helper objects in order to minimize the probability
of name conflict with objects defined by the user.
For example, the class that represents a ``<div>`` is called ``DIV``, while according to the
Python style reference it should have been called ``Div``. We believe that, for this specific example that
using an all-upper-case "DIV" is a more natural choice. Moreover, this approach leaves programmers
free to create a class called "Div" if they choose to do so.
Our syntax also maps naturally into the DOM notation of most browsers (including, for example, Firefox).
variables. Continuing with our example, even considering that ``DIV`` is a class
it is a special class that should never be modified by
the user because doing so would break other web2py applications.
Hence, we believe this qualifies the ``DIV`` class as
something that should be treated as a constant, further justifying our choice of notation.
In summary, the following conventions are followed:
- HTML helpers and validators are all upper case for the reasons discussed above (for example ``DIV``, ``A``, ``FORM``, ``URL``).
- The translator object ``T`` is upper case despite the fact that it is an instance of a class and not a class itself. Logically the translator object performs an action similar to the HTML helpers, it affects rendering part of the presentation. Also, ``T`` needs to be easy to locate in the code and must have a short name.
- DAL classes follow the Python style guide (first letter capitalized), for example ``Table``, ``Field``, ``Query``, ``Row``, ``Rows``, etc.
In all other cases we believe we have followed, as much as possible,
the Python Style Guide (PEP8).
For example all instance objects are lower-case (request, response, session, cache), and all internal classes are capitalized.
In all the examples of this book, web2py keywords are shown in bold, while strings and comments are shown in italic.
### License
``license``:inxx
web2py is licensed under the LGPL version 3 License. The full text of the license if available in ref.``lgpl3``:cite.
In accordance with LGPL you may:
- redistribute web2py with your apps (including official web2py binary versions)
- release your applications which use official web2py libraries under any license you wish
Yet you must:
- make clear in the documentation that your application uses web2py
- release any modification of the web2py libraries under the LGPLv3 license
The license includes the usual disclaimer:
THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW.
EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES
PROVIDE THE PROGRAM “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED,
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE
PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL
NECESSARY SERVICING, REPAIR OR CORRECTION.
IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT
HOLDER, OR ANY OTHER PARTY WHO MODIFIES AND/OR CONVEYS THE PROGRAM AS PERMITTED ABOVE,
BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL
DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED
TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES
OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER
PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
**Earlier versions**
Earlier versions of web2py, 1.0.*-1.90.*, were released under the GPL2 license plus a
commercial exception which, for practical purposes, was very similar to the current LPGLv3.
+This 5th edition of the book describes ``web2py`` 2.4.1 and later versions.
+
### Principles
### Principles
web2py differs from other web frameworks in that it is the only framework to fully embrace the Web 2.0
paradigm, where the web is the computer. In fact, web2py does not require installation or configuration; it
runs on any architecture that can run Python (Windows, Windows CE, Mac OS X, iOS, and Unix/Linux), and the development, deployment, and maintenance phases for the applications can be done via a local or remote web interface. web2py runs with CPython (the C implementation) and PyPy (Python written in Python), on Python versions 2.5, 2.6, and 2.7.
web2py provides a ticketing system for error events. If an error occurs, a ticket is issued to the user,
and the error is logged for the administrator.
web2py is open source and released under the LGPL version 3 license.
Another important feature of web2py is that we, its developers, commit to maintain backward compatibility in future versions. We have done so since the first release of web2py in October, 2007.
New features have been added and bugs have been fixed, but if a program worked with web2py 1.0, that program will work even better today.
Here are some examples of web2py statements that illustrate its power and simplicity. The following code:
``
db.define_table('person', Field('name'), Field('image', 'upload'))
``:code
creates a database table called "person" with two fields: "name", a string; and "image", something that
needs to be uploaded (the actual image). If the table already exists but does not match this definition, it is altered appropriately.
Given the table defined above, the following code:
``
form = SQLFORM(db.person).process()
``:code
creates an insert form for this table that allows users to upload images. It also
validates the submitted form, renames the uploaded image in a secure way, stores the image in a file,
inserts the corresponding record in the database, prevents double submission, and eventually modifies
the form itself by adding error messages if the data submitted by the user does not pass validation.
This code embeds a fully working wiki with tags, search, tag cloud, permissions, media attachments, and oembed support:
``
def index(): return auth.wiki()
``
The following code instead:
``
@auth.requires_permission('read','person')
def f(): ....
``:code
prevents visitors from accessing the function ``f`` unless the visitor is a member of a group whose members have permissions to "read" records of table "person". If the visitor is not logged in, the visitor gets directed to a login page (provided by default by web2py).
web2py also supports components, i.e. actions which can be loaded in a view and interact with the visitor via Ajax without re-loading the entire page. This is done via a ``LOAD`` helper which allows very modular design of applications; it is discussed in chapter 3 in the context of the wiki and, in some detail, in the last chapter of this book.
### Principles
Python programming typically follows these basic principles:
- Don't repeat yourself (DRY).
- There should be only one way of doing things.
- Explicit is better than implicit.
web2py fully embraces the first two principles by forcing the developer to use sound software
engineering practices that discourage repetition of code. web2py guides the developer through almost
all the tasks common in web application development (creating and processing forms, managing
sessions, cookies, errors, etc.).
``request``:inxx
web2py differs from other frameworks with regard to the third principle, which sometimes conflicts
with the other two. In particular, web2py does not import user applications, but executes them in a predefined context. This context exposes the Python keywords, as well as the web2py keywords.
To some this may appear as magic, but it should not.
That list is reproduced here, along with a description of how each issue is addr
web2py was reviewed for security and you can find the result of the review in ref.``pythonsecurity``:cite.
### In the box
You can download web2py from the official web site:
``
http://www.web2py.com
``:code
web2py is composed of the following components:
- **libraries**: provide core functionality of web2py and are accessible programmatically.
- **web server**: the Rocket WSGI web server.
- the **admin** application: used to create, design, and manage other web2py applications. **admin** provides a complete web-based Integrated Development Environment (IDE) for building web2py applications. It also includes other functionality, such as web-based testing and a web-based shell.
- the **examples** application: contains documentation and interactive examples. **examples** is a clone of the official web2py.com web site, and includes epydoc documentation.
- the **welcome** application: the basic scaffolding template for any other application. By default it includes a pure CSS cascading menu and user authentication (discussed in Chapter 9).
web2py is distributed in source code, and in binary form for Microsoft Windows and for Mac OS X.
The source code distribution can be used in any platform where Python runs and includes the above-mentioned components.
+To run the source code, you need Python 2.5 or 2.7 pre-installed on the system. You also need one of the supported database engines installed.
+For testing and light-demand applications, you can use the SQLite database, included with Python 2.7.
The binary versions of web2py (for Windows and Mac OS X) include a Python 2.7 interpreter and
the SQLite database. Technically, these two are not components of web2py. Including them in the binary distributions
enables you to run web2py out of the box.
The following image depicts the overall web2py structure:
[[image @///image/en300.png center 480px]]
+At the bottom we find the interpreter. Moving up we find the web server (rocket), the libraries, and the applications. Each application consists for its own MVC design (models, controllers, views, modules, languages, databases, and static files). Each application includes it own database administration code (appadmin). Every web2py instance ships with three applications: welcome (the scaffolding app), admin (the web based IDE), and examples (copy of website and examples).
+
### About this book
This book includes the following chapters, besides this introduction:
- Chapter 2 is a minimalist introduction to Python. It assumes knowledge of both procedural and object-oriented programming concepts such as loops, conditions, function calls and classes, and covers basic Python syntax. It also covers examples of Python modules that are used throughout the book. If you already know Python, you may skip Chapter 2.
- Chapter 3 shows how to start web2py, discusses the administrative interface, and guides the reader through various examples of increasing complexity: an application that returns a string, a counter application, an image blog, and a full blown wiki application that allows image uploads and comments, provides authentication, authorization, web services and an RSS feed. While reading this chapter, you may need to refer to Chapter 2 for general Python syntax and to the following chapters for a more detailed reference about the functions that are used.
- Chapter 4 covers more systematically the core structure and libraries: URL mapping, request, response, sessions, caching, schedulre, cron, internationalization and general workflow.
- Chapter 5 is a reference for the template language used to build views. It shows how to embed Python code into HTML, and demonstrates the use of helpers (objects that can generate HTML).
- Chapter 6 covers the Database Abstraction Layer, or DAL. The syntax of the DAL is presented through a series of examples.
- Chapter 7 covers forms, form validation and form processing. FORM is the low level helper for form building. SQLFORM is the high level form builder. In Chapter 7 we also discuss Create/Read/Update/Delete (CRUD) API.
- Chapter 8 covers communication with as sending emails and SMSes.
- Chapter 9 covers authentication, authorization and the extensible Role-Based Access Control mechanism available in web2py. Mail configuration and CAPTCHA are also discussed here, since they are used for authentication. In the third edition of the book we have added extensive coverage of integration with third-party authentication mechanisms such as OpenID, OAuth, Google, Facebook, LinkedIn, etc.
- Chapter 10 is about creating web services in web2py. We provide examples of integration with the Google Web Toolkit via Pyjamas, and with Adobe Flash via PyAMF.
- Chapter 11 is about web2py and jQuery recipes. web2py is designed mainly for server-side programming, but it includes jQuery, since we have found it to be the best open-source JavaScript library available for effects and Ajax. In this chapter, we discuss how to effectively use jQuery with web2py.
+- Chapter 12 discusses web2py components and plugins as a way to build modular applications. We provide an example of a plugin that implements many commonly used functionality, such as charting, comments, and tagging.
+- Chapter 13 is about production deployment of web2py applications. We specifically discuss the deployment on a LAMP web server (which we consider the main deployment alternative). We discuss alterantive web servers, and configuration of the PostgreSQL database. We discuss running as a service on a Microsoft Windows environment, and deployment on some specific platforms including Google Applications Engine, Heorku, and PythonAnywhere. In this chapter, we also discuss security and scalability issues.
- Chapter 14 contains a variety of other recipes to solve specific tasks, including upgrades, geocoding, pagination, the Twitter API, and more.
web2py differs from other web frameworks in that it is the only framework to fully embrace the Web 2.0
paradigm, where the web is the computer. In fact, web2py does not require installation or configuration; it
runs on any architecture that can run Python (Windows, Windows CE, Mac OS X, iOS, and Unix/Linux), and the development, deployment, and maintenance phases for the applications can be done via a local or remote web interface. web2py runs with CPython (the C implementation) and PyPy (Python written in Python), on Python versions 2.5, 2.6, and 2.7, although "officially" it only supports 2.5 so that we can guarantee backward compatibility for applications.
web2py provides a ticketing system for error events. If an error occurs, a ticket is issued to the user,
and the error is logged for the administrator.
web2py is open source and released under the LGPL version 3 license.
Another important feature of web2py is that we, its developers, commit to maintain backward compatibility in future versions. We have done so since the first release of web2py in October, 2007.
New features have been added and bugs have been fixed, but if a program worked with web2py 1.0, that program will work even better today.
Here are some examples of web2py statements that illustrate its power and simplicity. The following code:
``
db.define_table('person', Field('name'), Field('image', 'upload'))
``:code
creates a database table called "person" with two fields: "name", a string; and "image", something that
needs to be uploaded (the actual image). If the table already exists but does not match this definition, it is altered appropriately.
Given the table defined above, the following code:
``
form = SQLFORM(db.person).process()
``:code
creates an insert form for this table that allows users to upload images. It also
validates a submitted form, renames the uploaded image in a secure way, stores the image in a file,
inserts the corresponding record in the database, prevents double submission, and eventually modifies
the form itself by adding error messages if the data submitted by the user does not pass validation.
This code embeds a fully working wiki with tags, search, tag cloud, permissions, media attachments, and oembed support:
``
def index(): return auth.wiki()
``
The following code instead:
``
@auth.requires_permission('read','person')
def f(): ....
``:code
prevents visitors from accessing the function ``f`` unless the visitor is a member of a group whose members have permissions to "read" records of table "person". If the visitor is not logged in, he gets directed to a login page (provided by default by web2py).
web2py also supports components, i.e. actions which can be loaded in a view and interact with the visitor via Ajax without re-loading the entire page. This is done via a ``LOAD`` helper which allows very modular design of applications; it is discussed in chapter 3 in the context of the wiki and, in some detail, in the last chapter of this book.
### Principles
Python programming typically follows these basic principles:
- Don't repeat yourself (DRY).
- There should be only one way of doing things.
- Explicit is better than implicit.
web2py fully embraces the first two principles by forcing the developer to use sound software
engineering practices that discourage repetition of code. web2py guides the developer through almost
all the tasks common in web application development (creating and processing forms, managing
sessions, cookies, errors, etc.).
``request``:inxx
web2py differs from other frameworks with regard to the third principle, which sometimes conflicts
with the other two. In particular, web2py does not import user applications, but executes them in a predefined context. This context exposes the Python keywords, as well as the web2py keywords.
To some this may appear as magic, but it should not.
That list is reproduced here, along with a description of how each issue is addr
web2py was reviewed for security and you can find the result of the review in ref.``pythonsecurity``:cite.
### In the box
You can download web2py from the official web site:
``
http://www.web2py.com
``:code
web2py is composed of the following components:
- **libraries**: provide core functionality of web2py and are accessible programmatically.
- **web server**: the Rocket WSGI web server.
- the **admin** application: used to create, design, and manage other web2py applications. **admin** provides a complete web-based Integrated Development Environment (IDE) for building web2py applications. It also includes other functionality, such as web-based testing and a web-based shell.
- the **examples** application: contains documentation and interactive examples. **examples** is a clone of the official web2py.com web site, and includes epydoc documentation.
- the **welcome** application: the basic scaffolding template for any other application. By default it includes a pure CSS cascading menu and user authentication (discussed in Chapter 9).
web2py is distributed in source code, and in binary form for Microsoft Windows and for Mac OS X.
The source code distribution can be used in any platform where Python runs and includes the above-mentioned components.
-To run the source code, you need Python 2.5 pre-installed on the system. You also need one of the supported database engines installed.
-For testing and light-demand applications, you can use the SQLite database, included with Python 2.5.
The binary versions of web2py (for Windows and Mac OS X) include a Python 2.5 interpreter and
the SQLite database. Technically, these two are not components of web2py. Including them in the binary distributions
enables you to run web2py out of the box.
The following image depicts the overall web2py structure:
[[image @///image/en300.png center 480px]]
### About this book
This book includes the following chapters, besides this introduction:
- Chapter 2 is a minimalist introduction to Python. It assumes knowledge of both procedural and object-oriented programming concepts such as loops, conditions, function calls and classes, and covers basic Python syntax. It also covers examples of Python modules that are used throughout the book. If you already know Python, you may skip Chapter 2.
- Chapter 3 shows how to start web2py, discusses the administrative interface, and guides the reader through various examples of increasing complexity: an application that returns a string, a counter application, an image blog, and a full blown wiki application that allows image uploads and comments, provides authentication, authorization, web services and an RSS feed. While reading this chapter, you may need to refer to Chapter 2 for general Python syntax and to the following chapters for a more detailed reference about the functions that are used.
- Chapter 4 covers more systematically the core structure and libraries: URL mapping, request, response, sessions, caching, cron, internationalization and general workflow.
- Chapter 5 is a reference for the template language used to build views. It shows how to embed Python code into HTML, and demonstrates the use of helpers (objects that can generate HTML).
- Chapter 6 covers the Database Abstraction Layer, or DAL. The syntax of the DAL is presented through a series of examples.
- Chapter 7 covers forms, form validation and form processing. FORM is the low level helper for form building. SQLFORM is the high level form builder. In Chapter 7 we also discuss legacy Create/Read/Update/Delete (CRUD) API.
- Chapter 8 covers communication with as sending emails and SMSes.
- Chapter 9 covers authentication, authorization and the extensible Role-Based Access Control mechanism available in web2py. Mail configuration and CAPTCHA are also discussed here, since they are used for authentication. In the third edition of the book we have added extensive coverage of integration with third-party authentication mechanisms such as OpenID, OAuth, Google, Facebook, LinkedIn, etc.
- Chapter 10 is about creating web services in web2py. We provide examples of integration with the Google Web Toolkit via Pyjamas, and with Adobe Flash via PyAMF.
- Chapter 11 is about web2py and jQuery recipes. web2py is designed mainly for server-side programming, but it includes jQuery, since we have found it to be the best open-source JavaScript library available for effects and Ajax. In this chapter, we discuss how to effectively use jQuery with web2py.
-- Chapter 12 discusses web2py components and plugins as a way to build modular applications. We provide an example of a plugin that implements many commonly used functionality, such as charting, comments, tagging, and wiki.
-- Chapter 13 is about production deployment of web2py applications. We mainly address three possible production scenarios: on a Linux web server or a set of servers (which we consider the main deployment alternative), running as a service on a Microsoft Windows environment, and deployment on the Google Applications Engine. In this chapter, we also discuss security and scalability issues.
- Chapter 14 contains a variety of other recipes to solve specific tasks, including upgrades, geocoding, pagination, the Twitter API, and more.
+Nick Vargish,
Nico de Groot,
Nico Zanferrari,
Nicolas Bruxer,
Nik Klever,
Olaf Ferger,
Oliver Dain,
Olivier Roch Vilato,
Omi Chiba,
Ondrej Such,
Ont Rif,
Oscar Benjamin,
Osman Masood,
Ovidio Marinho Falcao Neto,
Pai,
Panos Jee,
Paolo Betti,
Paolo Caruccio,
Paolo Gasparello,
Paolo Valleri,
Patrick Breitenbach,
Pearu Peterson,
Peli Gergely,
Pete Hunt,
+Peter Kirchner,
Phyo Arkar Lwin,
Pierre Thibault,
Pieter Muller,
Piotr Banasziewicz,
Ramjee Ganti,
Richard Gordon,
Richard Ree,
Robert Kooij,
Robert Valentak,
Roberto Perdomo,
Robin Bhattacharyya,
Roman Bataev,
Ron McOuat,
Ross Peoples,
Ruijun Luo,
Running Calm,
Ryan Seto,
Salomon Derossi,
Sam Sheftel,
Scott Roberts,
Vladimir Donnikov,
Vladyslav Kozlovsky,
Vladyslav Kozlovskyy,
Wang Huaiyu,
Wen Gong,
Wes James,
Will Stevens,
Yair Eshel,
Yarko Tymciurak,
Yoshiyuki Nakamura,
Younghyun Jo,
Zahariash.
I am sure I forgot somebody, so I apologize.
I particularly thank Anthony, Jonathan, Mariano, Bruno, Vladyslav, Martin, Nathan, Simone, Thadeus, Tim, Iceberg, Denes, Hans, Christian, Fran and Patrick for their major contributions to web2py and Anthony, Alvaro, Brian, Bruno, Denes, Dane Denny, Erwin, Felipe, Graham, Jonathan, Hans, Kyle, Mark, Margaret, Michele, Nico, Richard, Roberto, Robin, Roman, Scott, Shane, Sharriff, Sriram, Sterling, Stuart, Thadeus, Wen (and others) for proofreading various versions of this book. Their contribution was invaluable. If you find any errors in this book, they are exclusively my fault, probably introduced by a last-minute edit. I also thank Ryan Steffen of Wiley Custom Learning Solutions for help with publishing the first edition of this book.
web2py contains code from the following authors, whom I would like to thank:
Guido van Rossum for Python``python``:cite, Peter Hunt, Richard Gordon, Timothy Farrell for the Rocket``rocket``:cite web server, Christopher Dolivet for EditArea``editarea``:cite, Bob Ippolito for simplejson``simplejson``:cite, Simon Cusack and Grant Edwards for pyRTF``pyrtf``:cite, Dalke Scientific Software for pyRSS2Gen``pyrss2gen``:cite, Mark Pilgrim for feedparser``feedparser``:cite, Trent Mick for markdown2``markdown2``:cite, Allan Saddi for fcgi.py, Evan Martin for the Python memcache module``memcache``:cite, John Resig for jQuery``jquery``:cite.
I thank Helmut Epp (provost of DePaul University), David Miller (Dean of the College of Computing and Digital Media of DePaul University), and Estia Eichten (Member of MetaCryption LLC), for their continuous trust and support.
Nico de Groot,
Nico Zanferrari,
Nicolas Bruxer,
Nik Klever,
Olaf Ferger,
Oliver Dain,
Olivier Roch Vilato,
Omi Chiba,
Ondrej Such,
Ont Rif,
Oscar Benjamin,
Osman Masood,
Ovidio Marinho Falcao Neto,
Pai,
Panos Jee,
Paolo Betti,
Paolo Caruccio,
Paolo Gasparello,
Paolo Valleri,
Patrick Breitenbach,
Pearu Peterson,
Peli Gergely,
Pete Hunt,
Phyo Arkar Lwin,
Pierre Thibault,
Pieter Muller,
Piotr Banasziewicz,
Ramjee Ganti,
Richard Gordon,
Richard Ree,
Robert Kooij,
Robert Valentak,
Roberto Perdomo,
Robin Bhattacharyya,
Roman Bataev,
Ron McOuat,
Ross Peoples,
Ruijun Luo,
Running Calm,
Ryan Seto,
Salomon Derossi,
Sam Sheftel,
Scott Roberts,
Vladimir Donnikov,
Vladyslav Kozlovsky,
Vladyslav Kozlovskyy,
Wang Huaiyu,
Wen Gong,
Wes James,
Will Stevens,
Yair Eshel,
Yarko Tymciurak,
Yoshiyuki Nakamura,
Younghyun Jo,
Zahariash.
I am sure I forgot somebody, so I apologize.
I particularly thank Anthony, Jonathan, Mariano, Bruno, Vladyslav, Martin, Nathan, Simone, Thadeus, Tim, Iceberg, Denes, Hans, Christian, Fran and Patrick for their major contributions to web2py and Anthony, Alvaro, Brian, Bruno, Denes, Dane Denny, Erwin, Felipe, Graham, Jonathan, Hans, Kyle, Mark, Margaret, Michele, Nico, Richard, Roberto, Robin, Roman, Scott, Shane, Sharriff, Sriram, Sterling, Stuart, Thadeus, Wen (and others) for proofreading various versions of this book. Their contribution was invaluable. If you find any errors in this book, they are exclusively my fault, probably introduced by a last-minute edit. I also thank Ryan Steffen of Wiley Custom Learning Solutions for help with publishing the first edition of this book.
web2py contains code from the following authors, whom I would like to thank:
Guido van Rossum for Python``python``:cite, Peter Hunt, Richard Gordon, Timothy Farrell for the Rocket``rocket``:cite web server, Christopher Dolivet for EditArea``editarea``:cite, Bob Ippolito for simplejson``simplejson``:cite, Simon Cusack and Grant Edwards for pyRTF``pyrtf``:cite, Dalke Scientific Software for pyRSS2Gen``pyrss2gen``:cite, Mark Pilgrim for feedparser``feedparser``:cite, Trent Mick for markdown2``markdown2``:cite, Allan Saddi for fcgi.py, Evan Martin for the Python memcache module``memcache``:cite, John Resig for jQuery``jquery``:cite.
-The cover of this book was designed by Peter Kirchner at Young Designers.
-
I thank Helmut Epp (provost of DePaul University), David Miller (Dean of the College of Computing and Digital Media of DePaul University), and Estia Eichten (Member of MetaCryption LLC), for their continuous trust and support.
I particularly thank Anthony, Jonathan, Mariano, Bruno, Vladyslav, Martin, Nathan, Simone, Thadeus, Tim, Iceberg, Denes, Hans, Christian, Fran and Patrick for their major contributions to web2py and Anthony, Alvaro, Brian, Bruno, Denes, Dane Denny, Erwin, Felipe, Graham, Jonathan, Hans, Kyle, Mark, Margaret, Michele, Nico, Richard, Roberto, Robin, Roman, Scott, Shane, Sharriff, Sriram, Sterling, Stuart, Thadeus, Wen (and others) for proofreading various versions of this book. Their contribution was invaluable. If you find any errors in this book, they are exclusively my fault, probably introduced by a last-minute edit. I also thank Ryan Steffen of Wiley Custom Learning Solutions for help with publishing the first edition of this book.
I particularly thank Anthony, Jonathan, Mariano, Bruno, Vladyslav, Martin, Nathan, Simone, Thadeus, Tim, Iceberg, Denes, Hans, Christian, Fran and Patrick for their major contributions to web2py and Anthony, Alvaro, Brian, Bruno, Denes, Dane Denny, Erwin, Felipe, Graham, Jonathan, Hans, Kyle, Mark, Margaret, Michele, Richard, Roberto, Robin, Roman, Scott, Shane, Sharriff, Sriram, Sterling, Stuart, Thadeus, Wen (and others) for proofreading various versions of this book. Their contribution was invaluable. If you find any errors in this book, they are exclusively my fault, probably introduced by a last-minute edit. I also thank Ryan Steffen of Wiley Custom Learning Solutions for help with publishing the first edition of this book.
+### About this book
+
+This book includes the following chapters, besides this introduction:
+- Chapter 2 is a minimalist introduction to Python. It assumes knowledge of both procedural and object-oriented programming concepts such as loops, conditions, function calls and classes, and covers basic Python syntax. It also covers examples of Python modules that are used throughout the book. If you already know Python, you may skip Chapter 2.
+- Chapter 3 shows how to start web2py, discusses the administrative interface, and guides the reader through various examples of increasing complexity: an application that returns a string, a counter application, an image blog, and a full blown wiki application that allows image uploads and comments, provides authentication, authorization, web services and an RSS feed. While reading this chapter, you may need to refer to Chapter 2 for general Python syntax and to the following chapters for a more detailed reference about the functions that are used.
+- Chapter 4 covers more systematically the core structure and libraries: URL mapping, request, response, sessions, caching, cron, internationalization and general workflow.
+- Chapter 5 is a reference for the template language used to build views. It shows how to embed Python code into HTML, and demonstrates the use of helpers (objects that can generate HTML).
+- Chapter 6 covers the Database Abstraction Layer, or DAL. The syntax of the DAL is presented through a series of examples.
+- Chapter 7 covers forms, form validation and form processing. FORM is the low level helper for form building. SQLFORM is the high level form builder. In Chapter 7 we also discuss legacy Create/Read/Update/Delete (CRUD) API.
+- Chapter 8 covers communication with as sending emails and SMSes.
+- Chapter 9 covers authentication, authorization and the extensible Role-Based Access Control mechanism available in web2py. Mail configuration and CAPTCHA are also discussed here, since they are used for authentication. In the third edition of the book we have added extensive coverage of integration with third-party authentication mechanisms such as OpenID, OAuth, Google, Facebook, LinkedIn, etc.
+- Chapter 10 is about creating web services in web2py. We provide examples of integration with the Google Web Toolkit via Pyjamas, and with Adobe Flash via PyAMF.
+- Chapter 11 is about web2py and jQuery recipes. web2py is designed mainly for server-side programming, but it includes jQuery, since we have found it to be the best open-source JavaScript library available for effects and Ajax. In this chapter, we discuss how to effectively use jQuery with web2py.
+- Chapter 12 discusses web2py components and plugins as a way to build modular applications. We provide an example of a plugin that implements many commonly used functionality, such as charting, comments, tagging, and wiki.
+- Chapter 13 is about production deployment of web2py applications. We mainly address three possible production scenarios: on a Linux web server or a set of servers (which we consider the main deployment alternative), running as a service on a Microsoft Windows environment, and deployment on the Google Applications Engine. In this chapter, we also discuss security and scalability issues.
+- Chapter 14 contains a variety of other recipes to solve specific tasks, including upgrades, geocoding, pagination, the Twitter API, and more.
+
+This book only covers basic web2py functionalities and the API that ships with web2py.
+This book does not cover web2py appliances (i.e. ready made applications).
+
+You can download web2py appliances from the corresponding web site ``appliances``:cite.
+
+You can find additional topics discussed on the usergroup``usergroup``:cite. There is also AlterEgo``alterego``:cite, the old web2py blog and FAQ.
+``MARKMIN``:inxx
+This book has been written using the markmin syntax and automatically converted to HTML, LaTeX and PDF.
+
+### Support
+
+The main support channel is the usergroup``usergroup``:cite, with dozens of posts every day. Even if you're a newbie, don't hesitate to ask - we'll be pleased to help you.
+There is also a formal issue tracker system on http://code.google.com/p/web2py/issue . Last but not least, you can have professional support (see the web site for details).
+
+### Contribute
+
+Any help is really appreciated. You can help other users on the user group, or by directly submitting patches on the program (at the GitHub site https://github.com/web2py/web2py).
+Even if you find a typo on this book, or have an improvement on it, the best way to help is by patching the book itself (which is under the source folder of the repository
+at https://github.com/mdipierro/web2py-book).
+
+### Elements of style
+
+PEP8 ``style``:cite contains good style practices when programming with Python. You will find
+that web2py does not always follow these rules. This is not because of omissions or negligence; it is our
+belief that the users of web2py should follow these rules and we encourage it. We chose not to
+follow some of those rules when defining web2py helper objects in order to minimize the probability
+of name conflict with objects defined by the user.
+
+For example, the class that represents a ``<div>`` is called ``DIV``, while according to the
+Python style reference it should have been called ``Div``. We believe that, for this specific example that
+using an all-upper-case "DIV" is a more natural choice. Moreover, this approach leaves programmers
+free to create a class called "Div" if they choose to do so.
+Our syntax also maps naturally into the DOM notation of most browsers (including, for example, Firefox).
+
+According to the Python style guide, all-upper-case strings should be used for constants and not
+variables. Continuing with our example, even considering that ``DIV`` is a class,
+it is a special class that should never be modified by
+the user because doing so would break other web2py applications.
+Hence, we believe this qualifies the ``DIV`` class as
+something that should be treated as a constant, further justifying our choice of notation.
+
+In summary, the following conventions are followed:
+- HTML helpers and validators are all upper case for the reasons discussed above (for example ``DIV``, ``A``, ``FORM``, ``URL``).
+- The translator object ``T`` is upper case despite the fact that it is an instance of a class and not a class itself. Logically the translator object performs an action similar to the HTML helpers, it affects rendering part of the presentation. Also, ``T`` needs to be easy to locate in the code and must have a short name.
+- DAL classes follow the Python style guide (first letter capitalized), for example ``Table``, ``Field``, ``Query``, ``Row``, ``Rows``, etc.
+
+In all other cases we believe we have followed, as much as possible,
+the Python Style Guide (PEP8).
+For example all instance objects are lower-case (request, response, session, cache), and all internal classes are capitalized.
+
+In all the examples of this book, web2py keywords are shown in bold, while strings and comments are shown in italic.
+
+
### License
``license``:inxx
web2py is licensed under the LGPL version 3 License. The full text of the license if available in ref.``lgpl3``:cite.
In accordance with LGPL you may:
- redistribute web2py with your apps (including official web2py binary versions)
- release your applications which use official web2py libraries under any license you wish
Yet you must:
- make clear in the documentation that your application uses web2py
- release any modification of the web2py libraries under the LGPLv3 license
The license includes the usual disclaimer:
THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW.
EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES
PROVIDE THE PROGRAM “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED,
Will Stevens,
Yair Eshel,
Yarko Tymciurak,
Yoshiyuki Nakamura,
Younghyun Jo,
Zahariash.
I am sure I forgot somebody, so I apologize.
I particularly thank Anthony, Jonathan, Mariano, Bruno, Vladyslav, Martin, Nathan, Simone, Thadeus, Tim, Iceberg, Denes, Hans, Christian, Fran and Patrick for their major contributions to web2py and Anthony, Alvaro, Brian, Bruno, Denes, Dane Denny, Erwin, Felipe, Graham, Jonathan, Hans, Kyle, Mark, Margaret, Michele, Richard, Roberto, Robin, Roman, Scott, Shane, Sharriff, Sriram, Sterling, Stuart, Thadeus, Wen (and others) for proofreading various versions of this book. Their contribution was invaluable. If you find any errors in this book, they are exclusively my fault, probably introduced by a last-minute edit. I also thank Ryan Steffen of Wiley Custom Learning Solutions for help with publishing the first edition of this book.
web2py contains code from the following authors, whom I would like to thank:
Guido van Rossum for Python``python``:cite, Peter Hunt, Richard Gordon, Timothy Farrell for the Rocket``rocket``:cite web server, Christopher Dolivet for EditArea``editarea``:cite, Bob Ippolito for simplejson``simplejson``:cite, Simon Cusack and Grant Edwards for pyRTF``pyrtf``:cite, Dalke Scientific Software for pyRSS2Gen``pyrss2gen``:cite, Mark Pilgrim for feedparser``feedparser``:cite, Trent Mick for markdown2``markdown2``:cite, Allan Saddi for fcgi.py, Evan Martin for the Python memcache module``memcache``:cite, John Resig for jQuery``jquery``:cite.
The cover of this book was designed by Peter Kirchner at Young Designers.
I thank Helmut Epp (provost of DePaul University), David Miller (Dean of the College of Computing and Digital Media of DePaul University), and Estia Eichten (Member of MetaCryption LLC), for their continuous trust and support.
Finally, I wish to thank my wife, Claudia, and my son, Marco, for putting up with me during the many hours I have spent developing web2py, exchanging emails with users and collaborators, and writing this book. This book is dedicated to them.
### License
``license``:inxx
web2py is licensed under the LGPL version 3 License. The full text of the license if available in ref.``lgpl3``:cite.
In accordance with LGPL you may:
- redistribute web2py with your apps (including official web2py binary versions)
- release your applications which use official web2py libraries under any license you wish
Yet you must:
- make clear in the documentation that your application uses web2py
- release any modification of the web2py libraries under the LGPLv3 license
The license includes the usual disclaimer:
THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW.
EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES
PROVIDE THE PROGRAM “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED,
Will Stevens,
Yair Eshel,
Yarko Tymciurak,
Yoshiyuki Nakamura,
Younghyun Jo,
Zahariash.
I am sure I forgot somebody, so I apologize.
I particularly thank Anthony, Jonathan, Mariano, Bruno, Vladyslav, Martin, Nathan, Simone, Thadeus, Tim, Iceberg, Denes, Hans, Christian, Fran and Patrick for their major contributions to web2py and Anthony, Alvaro, Brian, Bruno, Denes, Dane Denny, Erwin, Felipe, Graham, Jonathan, Hans, Kyle, Mark, Margaret, Michele, Richard, Roberto, Robin, Roman, Scott, Shane, Sharriff, Sriram, Sterling, Stuart, Thadeus, Wen (and others) for proofreading various versions of this book. Their contribution was invaluable. If you find any errors in this book, they are exclusively my fault, probably introduced by a last-minute edit. I also thank Ryan Steffen of Wiley Custom Learning Solutions for help with publishing the first edition of this book.
web2py contains code from the following authors, whom I would like to thank:
Guido van Rossum for Python``python``:cite, Peter Hunt, Richard Gordon, Timothy Farrell for the Rocket``rocket``:cite web server, Christopher Dolivet for EditArea``editarea``:cite, Bob Ippolito for simplejson``simplejson``:cite, Simon Cusack and Grant Edwards for pyRTF``pyrtf``:cite, Dalke Scientific Software for pyRSS2Gen``pyrss2gen``:cite, Mark Pilgrim for feedparser``feedparser``:cite, Trent Mick for markdown2``markdown2``:cite, Allan Saddi for fcgi.py, Evan Martin for the Python memcache module``memcache``:cite, John Resig for jQuery``jquery``:cite.
The cover of this book was designed by Peter Kirchner at Young Designers.
I thank Helmut Epp (provost of DePaul University), David Miller (Dean of the College of Computing and Digital Media of DePaul University), and Estia Eichten (Member of MetaCryption LLC), for their continuous trust and support.
Finally, I wish to thank my wife, Claudia, and my son, Marco, for putting up with me during the many hours I have spent developing web2py, exchanging emails with users and collaborators, and writing this book. This book is dedicated to them.
-### About this book
-
-This book includes the following chapters, besides this introduction:
-- Chapter 2 is a minimalist introduction to Python. It assumes knowledge of both procedural and object-oriented programming concepts such as loops, conditions, function calls and classes, and covers basic Python syntax. It also covers examples of Python modules that are used throughout the book. If you already know Python, you may skip Chapter 2.
-- Chapter 3 shows how to start web2py, discusses the administrative interface, and guides the reader through various examples of increasing complexity: an application that returns a string, a counter application, an image blog, and a full blown wiki application that allows image uploads and comments, provides authentication, authorization, web services and an RSS feed. While reading this chapter, you may need to refer to Chapter 2 for general Python syntax and to the following chapters for a more detailed reference about the functions that are used.
-- Chapter 4 covers more systematically the core structure and libraries: URL mapping, request, response, sessions, caching, cron, internationalization and general workflow.
-- Chapter 5 is a reference for the template language used to build views. It shows how to embed Python code into HTML, and demonstrates the use of helpers (objects that can generate HTML).
-- Chapter 6 covers the Database Abstraction Layer, or DAL. The syntax of the DAL is presented through a series of examples.
-- Chapter 7 covers forms, form validation and form processing. FORM is the low level helper for form building. SQLFORM is the high level form builder. In Chapter 7 we also discuss legacy Create/Read/Update/Delete (CRUD) API.
-- Chapter 8 covers communication with as sending emails and SMSes.
-- Chapter 9 covers authentication, authorization and the extensible Role-Based Access Control mechanism available in web2py. Mail configuration and CAPTCHA are also discussed here, since they are used for authentication. In the third edition of the book we have added extensive coverage of integration with third-party authentication mechanisms such as OpenID, OAuth, Google, Facebook, LinkedIn, etc.
-- Chapter 10 is about creating web services in web2py. We provide examples of integration with the Google Web Toolkit via Pyjamas, and with Adobe Flash via PyAMF.
-- Chapter 11 is about web2py and jQuery recipes. web2py is designed mainly for server-side programming, but it includes jQuery, since we have found it to be the best open-source JavaScript library available for effects and Ajax. In this chapter, we discuss how to effectively use jQuery with web2py.
-- Chapter 12 discusses web2py components and plugins as a way to build modular applications. We provide an example of a plugin that implements many commonly used functionality, such as charting, comments, tagging, and wiki.
-- Chapter 13 is about production deployment of web2py applications. We mainly address three possible production scenarios: on a Linux web server or a set of servers (which we consider the main deployment alternative), running as a service on a Microsoft Windows environment, and deployment on the Google Applications Engine. In this chapter, we also discuss security and scalability issues.
-- Chapter 14 contains a variety of other recipes to solve specific tasks, including upgrades, geocoding, pagination, the Twitter API, and more.
-
-This book only covers basic web2py functionalities and the API that ships with web2py.
-This book does not cover web2py appliances (i.e. ready made applications).
-
-You can download web2py appliances from the corresponding web site ``appliances``:cite.
-
-You can find additional topics discussed on the usergroup``usergroup``:cite. There is also AlterEgo``alterego``:cite, the old web2py blog and FAQ.
-``MARKMIN``:inxx
-This book has been written using the markmin syntax and automatically converted to HTML, LaTeX and PDF.
-
-### Support
-
-The main support channel is the usergroup``usergroup``:cite, with dozens of posts every day. Even if you're a newbie, don't hesitate to ask - we'll be pleased to help you.
-There is also a formal issue tracker system on http://code.google.com/p/web2py/issue . Last but not least, you can have professional support (see the web site for details).
-
-### Contribute
-
-Any help is really appreciated. You can help other users on the user group, or by directly submitting patches on the program (at the GitHub site https://github.com/web2py/web2py).
-Even if you find a typo on this book, or have an improvement on it, the best way to help is by patching the book itself (which is under the source folder of the repository
-at https://github.com/mdipierro/web2py-book).
-
-### Elements of style
-
-PEP8 ``style``:cite contains good style practices when programming with Python. You will find
-that web2py does not always follow these rules. This is not because of omissions or negligence; it is our
-belief that the users of web2py should follow these rules and we encourage it. We chose not to
-follow some of those rules when defining web2py helper objects in order to minimize the probability
-of name conflict with objects defined by the user.
-
-For example, the class that represents a ``<div>`` is called ``DIV``, while according to the
-Python style reference it should have been called ``Div``. We believe that, for this specific example that
-using an all-upper-case "DIV" is a more natural choice. Moreover, this approach leaves programmers
-free to create a class called "Div" if they choose to do so.
-Our syntax also maps naturally into the DOM notation of most browsers (including, for example, Firefox).
-
-According to the Python style guide, all-upper-case strings should be used for constants and not
-variables. Continuing with our example, even considering that ``DIV`` is a class,
-it is a special class that should never be modified by
-the user because doing so would break other web2py applications.
-Hence, we believe this qualifies the ``DIV`` class as
-something that should be treated as a constant, further justifying our choice of notation.
-
-In summary, the following conventions are followed:
-- HTML helpers and validators are all upper case for the reasons discussed above (for example ``DIV``, ``A``, ``FORM``, ``URL``).
-- The translator object ``T`` is upper case despite the fact that it is an instance of a class and not a class itself. Logically the translator object performs an action similar to the HTML helpers, it affects rendering part of the presentation. Also, ``T`` needs to be easy to locate in the code and must have a short name.
-- DAL classes follow the Python style guide (first letter capitalized), for example ``Table``, ``Field``, ``Query``, ``Row``, ``Rows``, etc.
-
-In all other cases we believe we have followed, as much as possible,
-the Python Style Guide (PEP8).
-For example all instance objects are lower-case (request, response, session, cache), and all internal classes are capitalized.
-
-In all the examples of this book, web2py keywords are shown in bold, while strings and comments are shown in italic.
web2py is built for security. This means that it automatically addresses many of the issues
that can lead to security vulnerabilities, by following well established practices. For
example, it validates all input (to prevent injections), escapes all output (to prevent cross-site scripting),
renames uploaded files (to prevent directory traversal attacks).
web2py takes care of main security issues, so developers have less chances of introducing vulnerabilities.
web2py includes a Database Abstraction Layer (DAL) that writes SQL``sql-w``:cite dynamically so that you, the developer, don't have to. The DAL knows how to generate SQL transparently for
SQLite``sqlite``:cite, MySQL``mysql``:cite, PostgreSQL``postgres``:cite, MSSQL``mssql``:cite,
FireBird``firebird``:cite, Oracle``oracle``:cite, IBM DB2``db2``:cite, Informix``informix``:cite,
Ingres``ingresdb``:cite, and MongoDB``mongodb``:cite.
The DAL can also generate function calls for the Google Datastore
when running on the Google App Engine (GAE)``gae``:cite.
+Experimentally we support more databases and new ones are constantly added.
+Please check on the web2py web site and mailing list for more recent adapters.
+Once one or more database tables are defined, web2py automatically generates a fully functional web-based database
administration interface to access the database and the tables.
web2py differs from other web frameworks in that it is the only framework to fully embrace the Web 2.0
paradigm, where the web is the computer. In fact, web2py does not require installation or configuration; it
runs on any architecture that can run Python (Windows, Windows CE, Mac OS X, iOS, and Unix/Linux), and the development, deployment, and maintenance phases for the applications can be done via a local or remote web interface. web2py runs with CPython (the C implementation) and PyPy (Python written in Python), on Python versions 2.5, 2.6, and 2.7, although "officially" it only supports 2.5 so that we can guarantee backward compatibility for applications.
web2py provides a ticketing system for error events. If an error occurs, a ticket is issued to the user,
and the error is logged for the administrator.
web2py is open source and released under the LGPL version 3 license.
Another important feature of web2py is that we, its developers, commit to maintain backward compatibility in future versions. We have done so since the first release of web2py in October, 2007.
New features have been added and bugs have been fixed, but if a program worked with web2py 1.0, that program will work even better today.
Here are some examples of web2py statements that illustrate its power and simplicity. The following code:
``
db.define_table('person', Field('name'), Field('image', 'upload'))
``:code
creates a database table called "person" with two fields: "name", a string; and "image", something that
needs to be uploaded (the actual image). If the table already exists but does not match this definition, it is altered appropriately.
Given the table defined above, the following code:
``
form = SQLFORM(db.person).process()
``:code
creates an insert form for this table that allows users to upload images. It also
validates a submitted form, renames the uploaded image in a secure way, stores the image in a file,
inserts the corresponding record in the database, prevents double submission, and eventually modifies
the form itself by adding error messages if the data submitted by the user does not pass validation.
Bruno Rocha,
CJ Lazell,
Caleb Hattingh,
Carlos Galindo,
Carlos Hanson,
Carsten Haese,
Cedric Meyer,
Charles Law,
Charles Winebrinner,
Chris Clark,
Chris May,
Chris Sanders,
Christian Foster Howes,
Christopher Smiga,
Christopher Steel,
Clavin Sim,
Cliff Kachinske,
Corne Dickens,
Craig Younkins,
Dan McGee,
Dan Ragubba,
+Dane Wright,
Danny Morgan,
Daniel Gonz,
Daniel Haag,
Daniel Lin,
Dave Stoll,
David Adley,
David Harrison,
David Lin,
David Marko,
David Wagner,
Denes Lengyel,
Diaz Luis,
Dirk Krause,
Dominic Koenig,
Doug Warren,
Douglas Philips,
Douglas Soares de Andrade,
Douglas and Alan,
Dustin Bensing,
Elcio Ferreira,
Josh Jaques,
José Vicente de Sousa,
Jurgis Pralgauskis,
Keith Yang,
Kenji Hosoda,
Kenneth Lundstr,
Kirill Spitsin,
Kyle Smith,
Larry Weinberg,
Limodou,
Loren McGinnis,
Louis DaPrato,
Luca De Alfaro,
Luca Zachetti,
Lucas D'Ávila,
Madhukar R Pai,
Manuele Presenti,
Marc Abramowitz,
Marcel Hellkamp,
Marcel Leuthi,
Marcello Della Longa,
+Margaret Greaney,
Maria Mitica,
Mariano Reingart,
Marin Prajic,
Marin Pranji,
Marius van Niekerk,
Mark Kirkwood,
Mark Larsen,
Mark Moore,
Markus Gritsch,
Mart Senecal,
Martin Hufsky,
Martin Mulone,
Martin Weissenboeck,
Mateusz Banach,
Mathew Grabau,
Mathieu Clabaut,
Matt Doiron,
Matthew Norris,
Michael Fig,
Michael Herman,
Tito Garrido,
Tyrone Hattingh,
Vasile Ermicioi,
Vidul Nikolaev Petrov,
Vidul Petrov,
Vinicius Assef,
Vladimir Donnikov,
Vladyslav Kozlovsky,
Vladyslav Kozlovskyy,
Wang Huaiyu,
Wen Gong,
Wes James,
Will Stevens,
Yair Eshel,
Yarko Tymciurak,
Yoshiyuki Nakamura,
Younghyun Jo,
Zahariash.
I am sure I forgot somebody, so I apologize.
I particularly thank Anthony, Jonathan, Mariano, Bruno, Vladyslav, Martin, Nathan, Simone, Thadeus, Tim, Iceberg, Denes, Hans, Christian, Fran and Patrick for their major contributions to web2py and Anthony, Alvaro, Brian, Bruno, Denes, Dane Denny, Erwin, Felipe, Graham, Jonathan, Hans, Kyle, Mark, Margaret, Michele, Richard, Roberto, Robin, Roman, Scott, Shane, Sharriff, Sriram, Sterling, Stuart, Thadeus, Wen (and others) for proofreading various versions of this book. Their contribution was invaluable. If you find any errors in this book, they are exclusively my fault, probably introduced by a last-minute edit. I also thank Ryan Steffen of Wiley Custom Learning Solutions for help with publishing the first edition of this book.
web2py is built for security. This means that it automatically addresses many of the issues
that can lead to security vulnerabilities, by following well established practices. For
example, it validates all input (to prevent injections), escapes all output (to prevent cross-site scripting),
renames uploaded files (to prevent directory traversal attacks).
web2py leaves little choice to application developers in matters related to security.
web2py includes a Database Abstraction Layer (DAL) that writes SQL``sql-w``:cite dynamically so that you, the developer, don't have to. The DAL knows how to generate SQL transparently for
SQLite``sqlite``:cite, MySQL``mysql``:cite, PostgreSQL``postgres``:cite, MSSQL``mssql``:cite,
FireBird``firebird``:cite, Oracle``oracle``:cite, IBM DB2``db2``:cite, Informix``informix``:cite,
Ingres``ingresdb``:cite, and MongoDB``mongodb``:cite.
The DAL can also generate function calls for the Google Datastore
when running on the Google App Engine (GAE)``gae``:cite.
-Experimentally we support more databases. Please check on the web2py web site and mailing list for more recent adapters.
-Once one or more database tables are defined, web2py also generates a fully functional web-based database
administration interface to access the database and the tables.
web2py differs from other web frameworks in that it is the only framework to fully embrace the Web 2.0
paradigm, where the web is the computer. In fact, web2py does not require installation or configuration; it
runs on any architecture that can run Python (Windows, Windows CE, Mac OS X, iOS, and Unix/Linux), and the development, deployment, and maintenance phases for the applications can be done via a local or remote web interface. web2py runs with CPython (the C implementation) and PyPy (Python written in Python), on Python versions 2.5, 2.6, and 2.7, although "officially" it only supports 2.5 so that we can guarantee backward compatibility for applications.
web2py provides a ticketing system. If an error occurs, a ticket is issued to the user,
and the error is logged for the administrator.
web2py is open source and released under the LGPL version 3 license.
-Another feature of web2py is that we, its developers, commit to maintain backward compatibility in future versions.
We have done so since the first release of web2py in October, 2007.
New features have been added and bugs have been fixed, but if a program worked with web2py 1.0, that program will work even better today.
Here are some examples of web2py statements that illustrate its power and simplicity. The following code:
``
db.define_table('person', Field('name'), Field('image', 'upload'))
``:code
creates a database table called "person" with two fields: "name", a string; and "image", something that
needs to be uploaded (the actual image). If the table already exists but does not match this definition, it is altered appropriately.
Given the table defined above, the following code:
``
form = SQLFORM(db.person).process()
``:code
creates an insert form for this table that allows users to upload images. It also
validates a submitted form, renames the uploaded image in a secure way, stores the image in a file,
inserts the corresponding record in the database, prevents double submission, and eventually modifies
the form itself by adding error messages if the data submitted by the user does not pass validation.
Bruno Rocha,
CJ Lazell,
Caleb Hattingh,
Carlos Galindo,
Carlos Hanson,
Carsten Haese,
Cedric Meyer,
Charles Law,
Charles Winebrinner,
Chris Clark,
Chris May,
Chris Sanders,
Christian Foster Howes,
Christopher Smiga,
Christopher Steel,
Clavin Sim,
Cliff Kachinske,
Corne Dickens,
Craig Younkins,
Dan McGee,
Dan Ragubba,
Danny Morgan,
Daniel Gonz,
Daniel Haag,
Daniel Lin,
Dave Stoll,
David Adley,
David Harrison,
David Lin,
David Marko,
David Wagner,
Denes Lengyel,
Diaz Luis,
Dirk Krause,
Dominic Koenig,
Doug Warren,
Douglas Philips,
Douglas Soares de Andrade,
Douglas and Alan,
Dustin Bensing,
Elcio Ferreira,
Josh Jaques,
José Vicente de Sousa,
Jurgis Pralgauskis,
Keith Yang,
Kenji Hosoda,
Kenneth Lundstr,
Kirill Spitsin,
Kyle Smith,
Larry Weinberg,
Limodou,
Loren McGinnis,
Louis DaPrato,
Luca De Alfaro,
Luca Zachetti,
Lucas D'Ávila,
Madhukar R Pai,
Manuele Presenti,
Marc Abramowitz,
Marcel Hellkamp,
Marcel Leuthi,
Marcello Della Longa,
Maria Mitica,
Mariano Reingart,
Marin Prajic,
Marin Pranji,
Marius van Niekerk,
Mark Kirkwood,
Mark Larsen,
Mark Moore,
Markus Gritsch,
Mart Senecal,
Martin Hufsky,
Martin Mulone,
Martin Weissenboeck,
Mateusz Banach,
Mathew Grabau,
Mathieu Clabaut,
Matt Doiron,
Matthew Norris,
Michael Fig,
Michael Herman,
Tito Garrido,
Tyrone Hattingh,
Vasile Ermicioi,
Vidul Nikolaev Petrov,
Vidul Petrov,
Vinicius Assef,
Vladimir Donnikov,
Vladyslav Kozlovsky,
Vladyslav Kozlovskyy,
Wang Huaiyu,
Wen Gong,
Wes James,
Will Stevens,
Yair Eshel,
Yarko Tymciurak,
Yoshiyuki Nakamura,
Younghyun Jo,
Zahariash.
I am sure I forgot somebody, so I apologize.
I particularly thank Anthony, Jonathan, Mariano, Bruno, Vladyslav, Martin, Nathan, Simone, Thadeus, Tim, Iceberg, Denes, Hans, Christian, Fran and Patrick for their major contributions to web2py and Anthony, Alvaro, Bruno, Denes, Denny, Erwin, Felipe, Graham, Jonathan, Hans, Kyle, Mark, Michele, Richard, Roberto, Robin, Roman, Scott, Shane, Sharriff, Sriram, Sterling, Stuart, Thadeus, Wen (and others) for proofreading various versions of this book. Their contribution was invaluable. If you find any errors in this book, they are exclusively my fault, probably introduced by a last-minute edit. I also thank Ryan Steffen of Wiley Custom Learning Solutions for help with publishing the first edition of this book.
+Danny Morgan,
Daniel Gonz,
Daniel Haag,
Daniel Lin,
Dave Stoll,
David Adley,
David Harrison,
David Lin,
David Marko,
David Wagner,
Denes Lengyel,
Diaz Luis,
Dirk Krause,
Dominic Koenig,
Doug Warren,
Douglas Philips,
Douglas Soares de Andrade,
Douglas and Alan,
Dustin Bensing,
Elcio Ferreira,
Eric Vicenti,
Simone Bizzotto,
Sriram Durbha,
Sterling Hankins,
Stuart Rackham,
Telman Yusupov,
Thadeus Burgess,
Thomas Dallagnese,
Tim Farrell,
Tim Michelsen,
Tim Richardson,
Timothy Farrell,
Tito Garrido,
Tyrone Hattingh,
Vasile Ermicioi,
Vidul Nikolaev Petrov,
Vidul Petrov,
Vinicius Assef,
Vladimir Donnikov,
Vladyslav Kozlovsky,
Vladyslav Kozlovskyy,
Wang Huaiyu,
+Wen Gong,
Wes James,
Will Stevens,
Yair Eshel,
Yarko Tymciurak,
Yoshiyuki Nakamura,
Younghyun Jo,
Zahariash.
I am sure I forgot somebody, so I apologize.
I particularly thank Anthony, Jonathan, Mariano, Bruno, Vladyslav, Martin, Nathan, Simone, Thadeus, Tim, Iceberg, Denes, Hans, Christian, Fran and Patrick for their major contributions to web2py and Anthony, Alvaro, Bruno, Denes, Denny, Erwin, Felipe, Graham, Jonathan, Hans, Kyle, Mark, Michele, Richard, Roberto, Robin, Roman, Scott, Shane, Sharriff, Sriram, Sterling, Stuart, Thadeus, Wen (and others) for proofreading various versions of this book. Their contribution was invaluable. If you find any errors in this book, they are exclusively my fault, probably introduced by a last-minute edit. I also thank Ryan Steffen of Wiley Custom Learning Solutions for help with publishing the first edition of this book.
Daniel Gonz,
Daniel Haag,
Daniel Lin,
Dave Stoll,
David Adley,
David Harrison,
David Lin,
David Marko,
David Wagner,
Denes Lengyel,
Diaz Luis,
Dirk Krause,
Dominic Koenig,
Doug Warren,
Douglas Philips,
Douglas Soares de Andrade,
Douglas and Alan,
Dustin Bensing,
Elcio Ferreira,
Eric Vicenti,
Simone Bizzotto,
Sriram Durbha,
Sterling Hankins,
Stuart Rackham,
Telman Yusupov,
Thadeus Burgess,
Thomas Dallagnese,
Tim Farrell,
Tim Michelsen,
Tim Richardson,
Timothy Farrell,
Tito Garrido,
Tyrone Hattingh,
Vasile Ermicioi,
Vidul Nikolaev Petrov,
Vidul Petrov,
Vinicius Assef,
Vladimir Donnikov,
Vladyslav Kozlovsky,
Vladyslav Kozlovskyy,
Wang Huaiyu,
Wes James,
Will Stevens,
Yair Eshel,
Yarko Tymciurak,
Yoshiyuki Nakamura,
Younghyun Jo,
Zahariash.
I am sure I forgot somebody, so I apologize.
I particularly thank Anthony, Jonathan, Mariano, Bruno, Vladyslav, Martin, Nathan, Simone, Thadeus, Tim, Iceberg, Denes, Hans, Christian, Fran and Patrick for their major contributions to web2py and Anthony, Alvaro, Bruno, Denes, Erwin, Felipe, Graham, Jonathan, Hans, Kyle, Mark, Michele, Richard, Roberto, Robin, Roman, Scott, Shane, Sharriff, Sriram, Sterling, Stuart, Thadeus (and others) for proofreading various versions of this book. Their contribution was invaluable. If you find any errors in this book, they are exclusively my fault, probably introduced by a last-minute edit. I also thank Ryan Steffen of Wiley Custom Learning Solutions for help with publishing the first edition of this book.
In the diagram:
- The Server can be the web2py built-in web server or a third-party server, such as Apache. The Server handles multi-threading.
- "main" is the main WSGI application. It performs all common tasks and wraps user applications. It deals with cookies, sessions, transactions, URL routing and reverse routing, and dispatching.
It can serve and stream static files if the web server is not doing it already.
- The Models, Views and Controller components make up the user application.
- Multiple applications can be hosted in the same web2py instance.
- The dashed arrows represent communication with the database engine(s). The database queries can be written in raw SQL (discouraged) or by using the web2py Database Abstraction Layer (recommended), so that web2py application code is not dependent on the specific database engine.
- The dispatcher maps the requested URL to a function call in the controller. The output of the function can be a string or a dictionary of symbols (a hash table). The data in the dictionary is rendered by a view. If the visitor requests an HTML page (the default), the dictionary is rendered into an HTML page. If the visitor requests the same page in XML, web2py tries to find a view that can render the dictionary in XML. The developer can create views to render pages in any of the already supported protocols (HTML, XML, JSON, RSS, CSV, and RTF) or in additional custom protocols.
- All calls are wrapped into a transaction, and any uncaught exception causes the transaction to be rolled back. If the request succeeds, the transaction is committed.
- web2py also handles sessions and session cookies automatically, and when a transaction is committed, the session is also stored, unless specified otherwise.
- It is possible to register recurrent tasks (via cron) to run at scheduled times and/or after the completion of certain actions. In this way it is possible to run long and compute-intensive tasks in the background without slowing down navigation.
Here is a minimal and complete MVC application, consisting of three files:
**"db.py" is the model:**
``
db = DAL('sqlite://storage.sqlite')
db.define_table('contact',
Field('name'),
Field('phone'))
``:code
It connects to the database (in this example a SQLite database stored in the ``storage.sqlite`` file) and
defines a table called ``contact``. If the table does not exist, web2py creates it and, transparently
and in the background,
generates SQL code in the appropriate SQL dialect for the specific database engine used.
The developer can
Here is a screenshot of the main web2py **admin** interface:
[[image @///image/en200.png center 480px]]
### Security
``security``:inxx
The Open Web Application Security Project``owasp``:cite (OWASP) is a free and open worldwide community focused
on improving the security of application software.
OWASP has listed the top ten security issues that put web applications at risk.
That list is reproduced here, along with a description of how each issue is addressed by web2py:
- ``cross site scripting``:inxx "Cross Site Scripting (XSS): XSS flaws occur whenever an application takes user supplied data and sends it to a web browser without first validating or encoding that content. XSS allows attackers to execute scripts in the victim's browser which can hijack user sessions, deface web sites, possibly introduce worms, etc." ''web2py, by default, escapes all variables rendered in the view, preventing XSS.''
- ``injection flaws``:inxx "Injection Flaws: Injection flaws, particularly SQL injection, are common in web applications. Injection occurs when user-supplied data is sent to an interpreter as part of a command or query. The attacker's hostile data tricks the interpreter into executing unintended commands or changing data." ''web2py includes a Database Abstraction Layer that makes SQL injection impossible. Normally, SQL statements are not written by the developer. Instead, SQL is generated dynamically by the DAL, ensuring that all inserted data is properly escaped.''
- ``malicious file execution``:inxx "Malicious File Execution: Code vulnerable to remote file inclusion (RFI) allows attackers to include hostile code and data, resulting in devastating attacks, such as total server compromise." ''web2py allows only exposed functions to be executed, preventing malicious file execution. Imported functions are never exposed; only actions are exposed. web2py uses a Web-based administration interface which makes it very easy to keep track of what is exposed and what is not.''
- ``insecure object reference``:inxx "Insecure Direct Object Reference: A direct object reference occurs when a developer exposes a reference to an internal implementation object, such as a file, directory, database record, or key, as a URL or form parameter. Attackers can manipulate those references to access other objects without authorization." ''web2py does not expose any internal objects; moreover, web2py validates all URLs, thus preventing directory traversal attacks. web2py also provides a simple mechanism to create forms that automatically validate all input values.''
- ``CSRF``:inxx "Cross Site Request Forgery (CSRF): A CSRF attack forces a logged-on victim's browser to send a pre-authenticated request to a vulnerable web application, which then forces the victim's browser to perform a hostile action to the benefit of the attacker. CSRF can be as powerful as the web application that it attacks." ''web2py prevents CSRF as well as accidental double submission of forms by assigning a one-time random token to each form. Moreover web2py uses UUID for session cookie.''
- ``information leakage``:inxx ``improper error handling``:inxx "Information Leakage and Improper Error Handling: Applications can unintentionally leak information about their configuration, internal workings, or violate privacy through a variety of application problems. Attackers use this weakness to steal sensitive data, or conduct more serious attacks." ''web2py includes a ticketing system. No error can result in code being exposed to the users. All errors are logged and a ticket is issued to the user that allows error tracking. But errors and source code are accessible only to the administrator.''
- "Broken Authentication and Session Management: Account credentials and session tokens are often not properly protected. Attackers compromise passwords, keys, or authentication tokens to assume other users' identities." ''web2py provides a built-in mechanism for administrator authentication, and it manages sessions independently for each application. The administrative interface also forces the use of secure session cookies when the client is not "localhost". For applications, it includes a powerful Role Based Access Control API.''
- ``cryptographic store``:inxx "Insecure Cryptographic Storage: Web applications rarely use cryptographic functions properly to protect data and credentials. Attackers use weakly protected data to conduct identity theft and other crimes, such as credit card fraud." ''web2py uses the MD5 or the HMAC+SHA-512 hash algorithms to protect stored passwords. Other algorithms are also available.''
- ``secure communications``:inxx "Insecure Communications: Applications frequently fail to encrypt network traffic when it is necessary to protect sensitive communications." ''web2py includes the SSL-enabled``ssl``:cite Rocket WSGI server, but it can also use Apache or Lighttpd and mod_ssl to provide SSL encryption of communications.''
- ``access restriction``:inxx "Failure to Restrict URL Access: Frequently an application only protects sensitive functionality by preventing the display of links or URLs to unauthorized users. Attackers can use this weakness to access and perform unauthorized operations by accessing those URLs directly." ''web2py maps URL requests to Python modules and functions. web2py provides a mechanism for declaring which functions are public and which require authentication and authorization. The included Role Based Access Control API allow developers to restrict access to any function based on login, group membership or group based permissions. The permissions are very granular and can be combined with database filters to allow, for example, to give access to specific tables and/or records. web2py also allows digitally signed URL and provides API to digitally sign Ajax callbacks.''
web2py was reviewed for security and you can find the result of the review in ref.``pythonsecurity``:cite.
### In the box
You can download web2py from the official web site:
``
http://www.web2py.com
``:code
web2py is composed of the following components:
- **libraries**: provide core functionality of web2py and are accessible programmatically.
- **web server**: the Rocket WSGI web server.
- the **admin** application: used to create, design, and manage other web2py applications. **admin** provides a complete web-based Integrated Development Environment (IDE) for building web2py applications. It also includes other functionality, such as web-based testing and a web-based shell.
- the **examples** application: contains documentation and interactive examples. **examples** is a clone of the official web2py.com web site, and includes epydoc documentation.
- the **welcome** application: the basic scaffolding template for any other application. By default it includes a pure CSS cascading menu and user authentication (discussed in Chapter 9).
web2py is distributed in source code, and in binary form for Microsoft Windows and for Mac OS X.
The source code distribution can be used in any platform where Python runs and includes the above-mentioned components.
To run the source code, you need Python 2.5 pre-installed on the system. You also need one of the supported database engines installed.
For testing and light-demand applications, you can use the SQLite database, included with Python 2.5.
The binary versions of web2py (for Windows and Mac OS X) include a Python 2.5 interpreter and
the SQLite database. Technically, these two are not components of web2py. Including them in the binary distributions
enables you to run web2py out of the box.
The following image depicts the overall web2py structure:
[[image @///image/en300.png center 480px]]
### License
``license``:inxx
This book includes the following chapters, besides this introduction:
- Chapter 7 covers forms, form validation and form processing. FORM is the low level helper for form building. SQLFORM is the high level form builder. In Chapter 7 we also discuss legacy Create/Read/Update/Delete (CRUD) API.
- Chapter 8 covers communication with as sending emails and SMSes.
- Chapter 9 covers authentication, authorization and the extensible Role-Based Access Control mechanism available in web2py. Mail configuration and CAPTCHA are also discussed here, since they are used for authentication. In the third edition of the book we have added extensive coverage of integration with third-party authentication mechanisms such as OpenID, OAuth, Google, Facebook, LinkedIn, etc.
- Chapter 10 is about creating web services in web2py. We provide examples of integration with the Google Web Toolkit via Pyjamas, and with Adobe Flash via PyAMF.
- Chapter 11 is about web2py and jQuery recipes. web2py is designed mainly for server-side programming, but it includes jQuery, since we have found it to be the best open-source JavaScript library available for effects and Ajax. In this chapter, we discuss how to effectively use jQuery with web2py.
- Chapter 12 discusses web2py components and plugins as a way to build modular applications. We provide an example of a plugin that implements many commonly used functionality, such as charting, comments, tagging, and wiki.
- Chapter 13 is about production deployment of web2py applications. We mainly address three possible production scenarios: on a Linux web server or a set of servers (which we consider the main deployment alternative), running as a service on a Microsoft Windows environment, and deployment on the Google Applications Engine. In this chapter, we also discuss security and scalability issues.
- Chapter 14 contains a variety of other recipes to solve specific tasks, including upgrades, geocoding, pagination, the Twitter API, and more.
This book only covers basic web2py functionalities and the API that ships with web2py.
This book does not cover web2py appliances (i.e. ready made applications).
You can download web2py appliances from the corresponding web site ``appliances``:cite.
You can find additional topics discussed on the usergroup``usergroup``:cite. There is also AlterEgo``alterego``:cite, the old web2py blog and FAQ.
``MARKMIN``:inxx
This book has been written using the markmin syntax and automatically converted to HTML, LaTeX and PDF.
### Support
The main support channel is the usergroup``usergroup``:cite, with dozens of posts every day. Even if you're a newbie, don't hesitate to ask - we'll be pleased to help you.
There is also a formal issue tracker system on http://code.google.com/p/web2py/issue . Last but not least, you can have professional support (see the web site for details).
### Contribute
Any help is really appreciated. You can help other users on the user group, or by directly submitting patches on the program (at the GitHub site https://github.com/web2py/web2py).
Even if you find a typo on this book, or have an improvement on it, the best way to help is by patching the book itself (which is under the source folder of the repository
at https://github.com/mdipierro/web2py-book).
In the diagram:
- The Server can be the web2py built-in web server or a third-party server, such as Apache. The Server handles multi-threading.
- "main" is the main WSGI application. It performs all common tasks and wraps user applications. It deals with cookies, sessions, transactions, URL routing and reverse routing, and dispatching.
It can serve and stream static files if the web server is not doing it already.
- The Models, Views and Controller components make up the user application.
- Multiple applications can be hosted in the same web2py instance.
- The dashed arrows represent communication with the database engine(s). The database queries can be written in raw SQL (discouraged) or by using the web2py Database Abstraction Layer (recommended), so that web2py application code is not dependent on the specific database engine.
- The dispatcher maps the requested URL to a function call in the controller. The output of the function can be a string or a dictionary of symbols (a hash table). The data in the dictionary is rendered by a view. If the visitor requests an HTML page (the default), the dictionary is rendered into an HTML page. If the visitor requests the same page in XML, web2py tries to find a view that can render the dictionary in XML. The developer can create views to render pages in any of the already supported protocols (HTML, XML, JSON, RSS, CSV, RTF) or in additional custom protocols.
- All calls are wrapped into a transaction, and any uncaught exception causes the transaction to be rolled back. If the request succeeds, the transaction is committed.
- web2py also handles sessions and session cookies automatically, and when a transaction is committed, the session is also stored, unless specified otherwise.
- It is possible to register recurrent tasks (via cron) to run at scheduled times and/or after the completion of certain actions. In this way it is possible to run long and compute-intensive tasks in the background without slowing down navigation.
Here is a minimal and complete MVC application, consisting of three files:
**"db.py" is the model:**
``
db = DAL('sqlite://storage.sqlite')
db.define_table('contact',
Field('name'),
Field('phone'))
``:code
It connects to the database (in this example a SQLite database stored in the ``storage.sqlite`` file) and
defines a table called ``contact``. If the table does not exist, web2py creates it and, transparently
and in the background,
generates SQL code in the appropriate SQL dialect for the specific database engine used.
The developer can
Here is a screenshot of the main web2py **admin** interface:
[[image @///image/en200.png center 480px]]
### Security
``security``:inxx
The Open Web Application Security Project``owasp``:cite (OWASP) is a free and open worldwide community focused
on improving the security of application software.
OWASP has listed the top ten security issues that put web applications at risk.
That list is reproduced here, along with a description of how each issue is addressed by web2py:
- ``cross site scripting``:inxx "Cross Site Scripting (XSS): XSS flaws occur whenever an application takes user supplied data and sends it to a web browser without first validating or encoding that content. XSS allows attackers to execute scripts in the victim's browser which can hijack user sessions, deface web sites, possibly introduce worms, etc." ''web2py, by default, escapes all variables rendered in the view, preventing XSS.''
- ``injection flaws``:inxx "Injection Flaws: Injection flaws, particularly SQL injection, are common in web applications. Injection occurs when user-supplied data is sent to an interpreter as part of a command or query. The attacker's hostile data tricks the interpreter into executing unintended commands or changing data." ''web2py includes a Database Abstraction Layer that makes SQL injection impossible. Normally, SQL statements are not written by the developer. Instead, SQL is generated dynamically by the DAL, ensuring that all inserted data is properly escaped.''
- ``malicious file execution``:inxx "Malicious File Execution: Code vulnerable to remote file inclusion (RFI) allows attackers to include hostile code and data, resulting in devastating attacks, such as total server compromise." ''web2py allows only exposed functions to be executed, preventing malicious file execution. Imported functions are never exposed; only actions are exposed. web2py uses a Web-based administration interface which makes it very easy to keep track of what is exposed and what is not.''
- ``insecure object reference``:inxx "Insecure Direct Object Reference: A direct object reference occurs when a developer exposes a reference to an internal implementation object, such as a file, directory, database record, or key, as a URL or form parameter. Attackers can manipulate those references to access other objects without authorization." ''web2py does not expose any internal objects; moreover, web2py validates all URLs, thus preventing directory traversal attacks. web2py also provides a simple mechanism to create forms that automatically validate all input values.''
- ``CSRF``:inxx "Cross Site Request Forgery (CSRF): A CSRF attack forces a logged-on victim's browser to send a pre-authenticated request to a vulnerable web application, which then forces the victim's browser to perform a hostile action to the benefit of the attacker. CSRF can be as powerful as the web application that it attacks." ''web2py prevents CSRF as well as accidental double submission of forms by assigning a one-time random token to each form. Moreover web2py uses UUID for session cookie.''
- ``information leakage``:inxx ``improper error handling``:inxx "Information Leakage and Improper Error Handling: Applications can unintentionally leak information about their configuration, internal workings, or violate privacy through a variety of application problems. Attackers use this weakness to steal sensitive data, or conduct more serious attacks." ''web2py includes a ticketing system. No error can result in code being exposed to the users. All errors are logged and a ticket is issued to the user that allows error tracking. But errors and source code are accessible only to the administrator.''
- "Broken Authentication and Session Management: Account credentials and session tokens are often not properly protected. Attackers compromise passwords, keys, or authentication tokens to assume other users' identities." ''web2py provides a built-in mechanism for administrator authentication, and it manages sessions independently for each application. The administrative interface also forces the use of secure session cookies when the client is not "localhost". For applications, it includes a powerful Role Based Access Control API.''
- ``cryptographic store``:inxx "Insecure Cryptographic Storage: Web applications rarely use cryptographic functions properly to protect data and credentials. Attackers use weakly protected data to conduct identity theft and other crimes, such as credit card fraud." ''web2py uses the MD5 or the HMAC+SHA-512 hash algorithms to protect stored passwords. Other algorithms are also available.''
- ``secure communications``:inxx "Insecure Communications: Applications frequently fail to encrypt network traffic when it is necessary to protect sensitive communications." ''web2py includes the SSL-enabled``ssl``:cite Rocket WSGI server, but it can also use Apache or Lighttpd and mod_ssl to provide SSL encryption of communications.''
- ``access restriction``:inxx "Failure to Restrict URL Access: Frequently an application only protects sensitive functionality by preventing the display of links or URLs to unauthorized users. Attackers can use this weakness to access and perform unauthorized operations by accessing those URLs directly." ''web2py maps URL requests to Python modules and functions. web2py provides a mechanism for declaring which functions are public and which require authentication and authorization. The included Role Based Access Control API allow developers to restrict access to any function based on login, group membership or group based permissions. The permissions are very granular and can be combined with database filters to allow, for example, to give access to specific tables and/or records. web2py also allows digitally signed URL and provides API to digitally sign ajax callbacks.''
web2py was reviewed for security and you can find the result of the review in ref.``pythonsecurity``:cite.
### In the box
You can download web2py from the official web site:
``
http://www.web2py.com
``:code
web2py is composed of the following components:
- **libraries**: provide core functionality of web2py and are accessible programmatically.
- **web server**: the Rocket WSGI web server.
- the **admin** application: used to create, design, and manage other web2py applications. **admin** provide a complete web-based Integrated Development Environment (IDE) for building web2py applications. It also includes other functionality, such as web-based testing and a web-based shell.
- the **examples** application: contains documentation and interactive examples. **examples** is a clone of the official web2py.com web site, and includes epydoc documentation.
- the **welcome** application: the basic scaffolding template for any other application. By default it includes a pure CSS cascading menu and user authentication (discussed in Chapter 9).
web2py is distributed in source code, and in binary form for Microsoft Windows and for Mac OS X.
The source code distribution can be used in any platform where Python runs and includes the above-mentioned components.
To run the source code, you need Python 2.5 pre-installed on the system. You also need one of the supported database engines installed.
For testing and light-demand applications, you can use the SQLite database, included with Python 2.5.
The binary versions of web2py (for Windows and Mac OS X) include a Python 2.5 interpreter and
the SQLite database. Technically, these two are not components of web2py. Including them in the binary distributions
enables you to run web2py out of the box.
The following image depicts the overall web2py structure:
[[image @///image/en300.png center 480px]]
### License
``license``:inxx
This book includes the following chapters, besides this introduction:
- Chapter 7 covers forms, form validation and form processing. FORM is the low level helper for form building. SQLFORM is the high level form builder. In Chapter 7 we also discuss legacy Create/Read/Update/Delete (CRUD) API.
- Chapter 8 covers communication with as sending emails and SMSes.
- Chapter 9 covers authentication, authorization and the extensible Role-Based Access Control mechanism available in web2py. Mail configuration and CAPTCHA are also discussed here, since they are used for authentication. In the third edition of the book we have added extensive coverage of integration with third-party authentication mechanisms such as OpenID, OAuth, Google, Facebook, LinkedIn, etc.
- Chapter 10 is about creating web services in web2py. We provide examples of integration with the Google Web Toolkit via Pyjamas, and with Adobe Flash via PyAMF.
- Chapter 11 is about web2py and jQuery recipes. web2py is designed mainly for server-side programming, but it includes jQuery, since we have found it to be the best open-source JavaScript library available for effects and Ajax. In this chapter, we discuss how to effectively use jQuery with web2py.
- Chapter 12 discusses web2py components and plugins as a way to build modular applications. We provide an example of a plugin that implements many commonly used functionality, such as charting, comments, tagging, and wiki.
- Chapter 13 is about production deployment of web2py applications. We mainly address three possible production scenarios: on a Linux web server or a set of servers (which we consider the main deployment alternative), running as a service on a Microsoft Windows environment, and deployment on the Google Applications Engine. In this chapter, we also discuss security and scalability issues.
- Chapter 14 contains a variety of other recipes to solve specific tasks, including upgrades, geocoding, pagination, the Twitter API, and more.
This book only covers basic web2py functionalities and the API that ships with web2py.
This book does not cover web2py appliances (i.e. ready made applications).
You can download web2py appliances from the corresponding web site ``appliances``:cite.
You can find additional topics discussed on the usergroup``usergroup``:cite. There is also AlterEgo``alterego``:cite, the old web2py blog and FAQ.
``MARKMIN``:inxx
This book has been written using the markmin syntax and automatically converted to HTML, LaTeX and PDF.
### Support
The main support channel is the usergroup``usergroup``:cite, with dozens of posts everyday. Even if you're a newby, don't hesitate to ask - we'll be pleased to help you.
There is also a formal issue tracker system on http://code.google.com/p/web2py/issue . Last but not least, you can have professional support (see the web site for details).
### Contribute
Any help is really appreciated. You can help other users on the usergroup, or by directly submitting patches on the program (at the GitHub site https://github.com/web2py/web2py).
Even if you find a typo on this book, or have an improvement on it, the best way to help is by patching the book itself (which is under the source folder of the repository
at https://github.com/mdipierro/web2py-book).
web2py includes a Database Abstraction Layer (DAL) that writes SQL``sql-w``:cite dynamically so that you, the developer, don't have to. The DAL knows how to generate SQL transparently for
SQLite``sqlite``:cite, MySQL``mysql``:cite, PostgreSQL``postgres``:cite, MSSQL``mssql``:cite,
+FireBird``firebird``:cite, Oracle``oracle``:cite, IBM DB2``db2``:cite, Informix``informix``:cite,
+Ingres``ingresdb``:cite, and MongoDB``mongodb``:cite.
The DAL can also generate function calls for the Google Datastore
when running on the Google App Engine (GAE)``gae``:cite.
Experimentally we support more databases. Please check on the web2py web site and mailing list for more recent adapters.
Once one or more database tables are defined, web2py also generates a fully functional web-based database
administration interface to access the database and the tables.
web2py differs from other web frameworks in that it is the only framework to fully embrace the Web 2.0
paradigm, where the web is the computer. In fact, web2py does not require installation or configuration; it
runs on any architecture that can run Python (Windows, Windows CE, Mac OS X, iOS, and Unix/Linux), and the development, deployment, and maintenance phases for the applications can be done via a local or remote web interface. web2py runs with CPython (the C implementation) and PyPy (Python written in Python), on Python versions 2.5, 2.6, and 2.7, although "officially" it only supports 2.5 so that we can guarantee backward compatibility for applications.
web2py provides a ticketing system. If an error occurs, a ticket is issued to the user,
and the error is logged for the administrator.
web2py is open source and released under the LGPL version 3 license.
Another feature of web2py is that we, its developers, commit to maintain backward compatibility in future versions.
We have done so since the first release of web2py in October, 2007.
New features have been added and bugs have been fixed, but if a program worked with web2py 1.0, that program will work even better today.
Here are some examples of web2py statements that illustrate its power and simplicity. The following code:
Robin Bhattacharyya,
Roman Bataev,
Ron McOuat,
Ross Peoples,
Ruijun Luo,
Running Calm,
Ryan Seto,
Salomon Derossi,
Sam Sheftel,
Scott Roberts,
Sergey Podlesnyi,
Sharriff Aina,
Simone Bizzotto,
Sriram Durbha,
Sterling Hankins,
Stuart Rackham,
Telman Yusupov,
Thadeus Burgess,
Thomas Dallagnese,
Tim Farrell,
Tim Michelsen,
+Tim Richardson,
Timothy Farrell,
Tito Garrido,
Tyrone Hattingh,
Vasile Ermicioi,
Vidul Nikolaev Petrov,
Vidul Petrov,
Vinicius Assef,
Vladimir Donnikov,
Vladyslav Kozlovsky,
Vladyslav Kozlovskyy,
Wang Huaiyu,
Wes James,
Will Stevens,
Yair Eshel,
Yarko Tymciurak,
Yoshiyuki Nakamura,
Younghyun Jo,
Zahariash.
web2py includes a Database Abstraction Layer (DAL) that writes SQL``sql-w``:cite dynamically so that you, the developer, don't have to. The DAL knows how to generate SQL transparently for
SQLite``sqlite``:cite, MySQL``mysql``:cite, PostgreSQL``postgres``:cite, MSSQL``mssql``:cite,
-FireBird``firebird``:cite, Oracle``oracle``:cite, IBM DB2``db2``:cite, Informix``informix``:cite, and
-Ingres``ingresdb``:cite.
The DAL can also generate function calls for the Google Datastore
when running on the Google App Engine (GAE)``gae``:cite.
Experimentally we support more databases. Please check on the web2py web site and mailing list for more recent adapters.
Once one or more database tables are defined, web2py also generates a fully functional web-based database
administration interface to access the database and the tables.
web2py differs from other web frameworks in that it is the only framework to fully embrace the Web 2.0
paradigm, where the web is the computer. In fact, web2py does not require installation or configuration; it
runs on any architecture that can run Python (Windows, Windows CE, Mac OS X, iOS, and Unix/Linux), and the development, deployment, and maintenance phases for the applications can be done via a local or remote web interface. web2py runs with CPython (the C implementation) and PyPy (Python written in Python), on Python versions 2.5, 2.6, and 2.7, although "officially" it only supports 2.5 so that we can guarantee backward compatibility for applications.
web2py provides a ticketing system. If an error occurs, a ticket is issued to the user,
and the error is logged for the administrator.
web2py is open source and released under the LGPL version 3 license.
Another feature of web2py is that we, its developers, commit to maintain backward compatibility in future versions.
We have done so since the first release of web2py in October, 2007.
New features have been added and bugs have been fixed, but if a program worked with web2py 1.0, that program will work even better today.
Here are some examples of web2py statements that illustrate its power and simplicity. The following code:
Robin Bhattacharyya,
Roman Bataev,
Ron McOuat,
Ross Peoples,
Ruijun Luo,
Running Calm,
Ryan Seto,
Salomon Derossi,
Sam Sheftel,
Scott Roberts,
Sergey Podlesnyi,
Sharriff Aina,
Simone Bizzotto,
Sriram Durbha,
Sterling Hankins,
Stuart Rackham,
Telman Yusupov,
Thadeus Burgess,
Thomas Dallagnese,
Tim Farrell,
Tim Michelsen,
Timothy Farrell,
Tito Garrido,
Tyrone Hattingh,
Vasile Ermicioi,
Vidul Nikolaev Petrov,
Vidul Petrov,
Vinicius Assef,
Vladimir Donnikov,
Vladyslav Kozlovsky,
Vladyslav Kozlovskyy,
Wang Huaiyu,
Wes James,
Will Stevens,
Yair Eshel,
Yarko Tymciurak,
Yoshiyuki Nakamura,
Younghyun Jo,
Zahariash.
Another feature of web2py is that we, its developers, commit to maintain backward compatibility in future versions.
We have done so since the first release of web2py in October, 2007.
New features have been added and bugs have been fixed, but if a program worked with web2py 1.0, that program will work even better today.
Here are some examples of web2py statements that illustrate its power and simplicity. The following code:
``
db.define_table('person', Field('name'), Field('image', 'upload'))
``:code
creates a database table called "person" with two fields: "name", a string; and "image", something that
needs to be uploaded (the actual image). If the table already exists but does not match this definition, it is altered appropriately.
Given the table defined above, the following code:
``
form = SQLFORM(db.person).process()
``:code
creates an insert form for this table that allows users to upload images. It also
validates a submitted form, renames the uploaded image in a secure way, stores the image in a file,
inserts the corresponding record in the database, prevents double submission, and eventually modifies
the form itself by adding error messages if the data submitted by the user does not pass validation.
This code embeds a fully working wiki with tags, search, tag cloud, permissions, media attachments, and oembed support:
This book includes the following chapters, besides this introduction:
- Chapter 5 is a reference for the template language used to build views. It shows how to embed Python code into HTML, and demonstrates the use of helpers (objects that can generate HTML).
- Chapter 6 covers the Database Abstraction Layer, or DAL. The syntax of the DAL is presented through a series of examples.
- Chapter 7 covers forms, form validation and form processing. FORM is the low level helper for form building. SQLFORM is the high level form builder. In Chapter 7 we also discuss legacy Create/Read/Update/Delete (CRUD) API.
- Chapter 8 covers communication with as sending emails and SMSes.
- Chapter 9 covers authentication, authorization and the extensible Role-Based Access Control mechanism available in web2py. Mail configuration and CAPTCHA are also discussed here, since they are used for authentication. In the third edition of the book we have added extensive coverage of integration with third-party authentication mechanisms such as OpenID, OAuth, Google, Facebook, LinkedIn, etc.
- Chapter 10 is about creating web services in web2py. We provide examples of integration with the Google Web Toolkit via Pyjamas, and with Adobe Flash via PyAMF.
- Chapter 11 is about web2py and jQuery recipes. web2py is designed mainly for server-side programming, but it includes jQuery, since we have found it to be the best open-source JavaScript library available for effects and Ajax. In this chapter, we discuss how to effectively use jQuery with web2py.
- Chapter 12 discusses web2py components and plugins as a way to build modular applications. We provide an example of a plugin that implements many commonly used functionality, such as charting, comments, tagging, and wiki.
- Chapter 13 is about production deployment of web2py applications. We mainly address three possible production scenarios: on a Linux web server or a set of servers (which we consider the main deployment alternative), running as a service on a Microsoft Windows environment, and deployment on the Google Applications Engine. In this chapter, we also discuss security and scalability issues.
- Chapter 14 contains a variety of other recipes to solve specific tasks, including upgrades, geocoding, pagination, the Twitter API, and more.
This book only covers basic web2py functionalities and the API that ships with web2py.
This book does not cover web2py appliances (i.e. ready made applications).
You can download web2py appliances from the corresponding web site ``appliances``:cite.
You can find additional topics discussed on the usergroup``usergroup``:cite. There is also AlterEgo``alterego``:cite, the old web2py blog and FAQ.
``MARKMIN``:inxx
This book has been written using the markmin syntax and automatically converted to HTML, LaTeX and PDF.
+### Support
+
+The main support channel is the usergroup``usergroup``:cite, with dozens of posts everyday. Even if you're a newby, don't hesitate to ask - we'll be pleased to help you.
+There is also a formal issue tracker system on http://code.google.com/p/web2py/issue . Last but not least, you can have professional support (see the web site for details).
+
+### Contribute
+
+Any help is really appreciated. You can help other users on the usergroup, or by directly submitting patches on the program (at the GitHub site https://github.com/web2py/web2py).
+Even if you find a typo on this book, or have an improvement on it, the best way to help is by patching the book itself (which is under the source folder of the repository
+at https://github.com/mdipierro/web2py-book).
+
### Elements of style
Another feature of web2py is that we, its developers, commit to maintain backward compatibility in future versions.
We have done so since the first release of web2py in October, 2007.
New features have been added and bugs have been fixed, but if a program worked with web2py 1.0, that program will still work today.
Here are some examples of web2py statements that illustrate its power and simplicity. The following code:
``
db.define_table('person', Field('name'), Field('image', 'upload'))
``:code
creates a database table called "person" with two fields: "name", a string; and "image", something that
needs to be uploaded (the actual image). If the table already exists but does not match this definition, it is altered appropriately.
Given the table defined above, the following code:
``
form = SQLFORM(db.person).process()
``:code
creates an insert form for this table that allows users to upload images. It also
validates a submitted form, renames the uploaded image in a secure way, stores the image in a file,
inserts the corresponding record in the database, prevents double submission, and eventually modifies
the form itself by adding error messages if the data submitted by the user does not pass validation.
This code embeds a fully working wiki with tags, search, tag cloud, permissions, media attachments, and oembed support:
This book includes the following chapters, besides this introduction:
- Chapter 5 is a reference for the template language used to build views. It shows how to embed Python code into HTML, and demonstrates the use of helpers (objects that can generate HTML).
- Chapter 6 covers the Database Abstraction Layer, or DAL. The syntax of the DAL is presented through a series of examples.
- Chapter 7 covers forms, form validation and form processing. FORM is the low level helper for form building. SQLFORM is the high level form builder. In Chapter 7 we also discuss legacy Create/Read/Update/Delete (CRUD) API.
- Chapter 8 covers communication with as sending emails and SMSes.
- Chapter 9 covers authentication, authorization and the extensible Role-Based Access Control mechanism available in web2py. Mail configuration and CAPTCHA are also discussed here, since they are used for authentication. In the third edition of the book we have added extensive coverage of integration with third-party authentication mechanisms such as OpenID, OAuth, Google, Facebook, LinkedIn, etc.
- Chapter 10 is about creating web services in web2py. We provide examples of integration with the Google Web Toolkit via Pyjamas, and with Adobe Flash via PyAMF.
- Chapter 11 is about web2py and jQuery recipes. web2py is designed mainly for server-side programming, but it includes jQuery, since we have found it to be the best open-source JavaScript library available for effects and Ajax. In this chapter, we discuss how to effectively use jQuery with web2py.
- Chapter 12 discusses web2py components and plugins as a way to build modular applications. We provide an example of a plugin that implements many commonly used functionality, such as charting, comments, tagging, and wiki.
- Chapter 13 is about production deployment of web2py applications. We mainly address three possible production scenarios: on a Linux web server or a set of servers (which we consider the main deployment alternative), running as a service on a Microsoft Windows environment, and deployment on the Google Applications Engine. In this chapter, we also discuss security and scalability issues.
- Chapter 14 contains a variety of other recipes to solve specific tasks, including upgrades, geocoding, pagination, the Twitter API, and more.
This book only covers basic web2py functionalities and the API that ships with web2py.
This book does not cover web2py appliances (i.e. ready made applications).
You can download web2py appliances from the corresponding web site ``appliances``:cite.
You can find additional topics discussed on the usergroup``usergroup``:cite. There is also AlterEgo``alterego``:cite, the old web2py blog and FAQ.
``MARKMIN``:inxx
This book has been written using the markmin syntax and automatically converted to HTML, LaTeX and PDF.
### Elements of style
Paolo Valleri,
Paolo Velleri,
This code embeds a fully working wiki with tags, search, tag cloud, permissions, media attachments, and oembed support:
``
def index(): return auth.wiki()
``
The following code instead:
``
@auth.requires_permission('read','person')
def f(): ....
``:code
prevents visitors from accessing the function ``f`` unless the visitor is a member of a group whose members have permissions to "read" records of table "person". If the visitor is not logged in, he gets directed to a login page (provided by default by web2py).
web2py also supports components, i.e. actions which can be loaded in a view and interact with the visitor via Ajax without re-loading the entire page. This is done via a ``LOAD`` helper which allows very modular design of applications; it is discussed in chapter 3 in the context of the wiki and, in some detail, in the last chapter of this book.
### Principles
Python programming typically follows these basic principles:
- Don't repeat yourself (DRY).
- There should be only one way of doing things.
and returns the grid to the view.
**"default/contacts.html" is the view:**
``
{{extend 'layout.html'}}
<h1>Manage My Contacts</h1>
{{=grid}}
``:code
This view is called automatically by web2py after the associated controller function (action) is executed.
The purpose of this view is to render the variables in the returned dictionary (in our case ``grid``) into HTML.
The view file is written in HTML, but it embeds Python code delimited by the special ``{{`` and ``}}``
delimiters. This is quite different from the PHP code example, because the only code
embedded into the HTML is "presentation layer" code. The "layout.html" file referenced at the top of the
view is provided by web2py and constitutes the basic layout for all web2py applications. The layout file can
easily be modified or replaced.
### Why web2py
web2py is one of many web application frameworks, but it has compelling and unique features.
web2py was originally developed as a teaching tool, with the following primary motivations:
- Easy for users to learn server-side web development without compromising functionality. For this reason, web2py requires no installation and no configuration, has no dependencies (except for the source code distribution, which requires Python 2.5 and its standard library modules), and exposes most of its functionality via a Web interface, including an Integrated Development Environment with Debugger and database interface.
- web2py has been stable from day one because it follows a top-down design; i.e., its API was designed before it was implemented. Even as new functionality has been added, web2py has never broken backwards compatibility, and it will not break compatibility when additional functionality is added in the future.
- web2py proactively addresses the most important security issues which plague many modern web applications, as determined by OWASP``owasp``:cite below.
- web2py is lightweight. Its core libraries, including the Database Abstraction Layer, the template language, and all the helpers amount to 1.4MB. The entire source code including sample applications and images amounts to 10.4MB.
- web2py has a small footprint and is very fast. It uses the Rocket``rocket``:cite WSGI web server developed by Timothy Farrell. It is as fast as Apache with mod_wsgi, and supports SSL and IPv6.
- web2py uses Python syntax for models, controllers, and views, but does not import models and controllers (as all the other Python frameworks do) - instead it executes them. This means that apps can be installed, uninstalled, and modified without having to restart the web server (even in production), and different apps can coexist without their modules interfering with one another.
- web2py uses a Database Abstraction Layer (DAL) instead of an Object Relational Mapper (ORM). From a conceptual point of view, this means that different database tables are mapped into different instances of one ``Table`` class and not into different classes, while records are mapped into instances of one ``Row`` class, not into instances of the corresponding table class. From a practical point of view, it means that SQL syntax maps almost one-to-one into DAL syntax, and there is no complex metaclass programming going on under the hood as in popular ORMs, which would add latency.
WSGI ``wsgi-w``:cite ``wsgi-o``:cite (Web Server Gateway Interface) is an emerging Python standard for communication between a web server and Python applications).
Here is a screenshot of the main web2py **admin** interface:
[[image @///image/en200.png center 480px]]
### Security
``security``:inxx
The Open Web Application Security Project``owasp``:cite (OWASP) is a free and open worldwide community focused
on improving the security of application software.
OWASP has listed the top ten security issues that put web applications at risk.
That list is reproduced here, along with a description of how each issue is addressed by web2py:
- ``cross site scripting``:inxx "Cross Site Scripting (XSS): XSS flaws occur whenever an application takes user supplied data and sends it to a web browser without first validating or encoding that content. XSS allows attackers to execute scripts in the victim's browser which can hijack user sessions, deface web sites, possibly introduce worms, etc." ''web2py, by default, escapes all variables rendered in the view, preventing XSS.''
- ``injection flaws``:inxx "Injection Flaws: Injection flaws, particularly SQL injection, are common in web applications. Injection occurs when user-supplied data is sent to an interpreter as part of a command or query. The attacker's hostile data tricks the interpreter into executing unintended commands or changing data." ''web2py includes a Database Abstraction Layer that makes SQL injection impossible. Normally, SQL statements are not written by the developer. Instead, SQL is generated dynamically by the DAL, ensuring that all inserted data is properly escaped.''
- ``malicious file execution``:inxx "Malicious File Execution: Code vulnerable to remote file inclusion (RFI) allows attackers to include hostile code and data, resulting in devastating attacks, such as total server compromise." ''web2py allows only exposed functions to be executed, preventing malicious file execution. Imported functions are never exposed; only actions are exposed. web2py uses a Web-based administration interface which makes it very easy to keep track of what is exposed and what is not.''
Timothy Farrell,
Tito Garrido,
Tyrone Hattingh,
Vasile Ermicioi,
Vidul Nikolaev Petrov,
Vidul Petrov,
Vinicius Assef,
Vladimir Donnikov,
Vladyslav Kozlovsky,
Vladyslav Kozlovskyy,
Wang Huaiyu,
Wes James,
Will Stevens,
Yair Eshel,
Yarko Tymciurak,
Yoshiyuki Nakamura,
Younghyun Jo,
Zahariash.
I am sure I forgot somebody, so I apologize.
I particularly thank Anthony, Jonathan, Mariano, Bruno, Vladyslav, Martin, Nathan, Simone, Thadeus, Tim, Iceberg, Denes, Hans, Christian, Fran and Patrick for their major contributions to web2py and Anthony, Alvaro, Bruno, Denes, Erwin, Felipe, Graham, Jonathan, Hans, Kyle, Mark, Michele, Richard, Roberto, Robin, Roman, Scott, Shane, Sharriff, Sriram, Sterling, Stuart, Thadeus (and others) for proofreading various versions of this book. Their contribution was invaluable. If you find any errors in this book, they are exclusively my fault, probably introduced by a last-minute edit. I also thank Ryan Steffen of Wiley Custom Learning Solutions for help with publishing the first edition of this book.
This code embeds a fully working wiki with tags, search, tag cloud, permissions, media attachments, adn oembed support:
``
def index(): return auth.wiki()
``
The following code instead:
``
@auth.requires_permission('read','person')
def f(): ....
``:code
prevents visitors from accessing the function ``f`` unless the visitor is a member of a group whose members have permissions to "read" records of table "person". If the visitor is not logged in, he gets directed to a login page (provided by default by web2py).
web2py also supports components, i.e. actions which can be loaded in a view and interact with the visitor via Ajax without re-loading the entire page. This is done via a ``LOAD`` helper which allows very modular design of applications; it is discussed in chapter 3 in the context of the wiki and, in some detail, in the last chapter of this book.
### Principles
Python programming typically follows these basic principles:
- Don't repeat yourself (DRY).
- There should be only one way of doing things.
and returns the grid to the view.
**"default/contacts.html" is the view:**
``
{{extend 'layout.html'}}
<h1>Manage My Contacts</h1>
{{=grid}}
``:code
This view is called automatically by web2py after the associated controller function (action) is executed.
The purpose of this view is to render the variables in the returned dictionary (in our case ``grid``) into HTML.
The view file is written in HTML, but it embeds Python code delimited by the special ``{{`` and ``}}``
delimiters. This is quite different from the PHP code example, because the only code
embedded into the HTML is "presentation layer" code. The "layout.html" file referenced at the top of the
view is provided by web2py and constitutes the basic layout for all web2py applications. The layout file can
easily be modified or replaced.
### Why web2py
web2py is one of many web application frameworks, but it has compelling and unique features.
web2py was originally developed as a teaching tool, with the following primary motivations:
- Easy for users to learn server-side web development without compromising functionality. For this reason, web2py requires no installation and no configuration, has no dependencies (except for the source code distribution, which requires Python 2.5 and its standard library modules), and exposes most of its functionality via a Web interface, incuding an Integrated Development Environment with Debugger and database interface.
- web2py has been stable from day one because it follows a top-down design; i.e., its API was designed before it was implemented. Even as new functionality has been added, web2py has never broken backwards compatibility, and it will not break compatibility when additional functionality is added in the future.
- web2py proactively addresses the most important security issues which plague many modern web applications, as determined by OWASP``owasp``:cite below.
- web2py is lightweight. Its core libraries, including the Database Abstraction Layer, the template language, and all the helpers amount to 1.4MB. The entire source code including sample applications and images amounts to 10.4MB.
- web2py has a small footprint and is very fast. It uses the Rocket``rocket``:cite WSGI web server developed by Timothy Farrell. It is as fast as Apache with mod_wsgi, supports ssl and IPv6.
- web2py uses Python syntax for models, controllers, and views, but does not import models and controllers (as all the other Python frameworks do) - instead it executes them. This means that apps can be installed, uninstalled, and modified without having to restart the web server (even in production), and different apps can coexist without their modules interfering with one another.
- web2py uses a Database Abstraction Layer (DAL) instead of an Object Relational Mapper (ORM). From a conceptual point of view, this means that different database tables are mapped into different instances of one ``Table`` class and not into different classes, while records are mapped into instances of one ``Row`` class, not into instances of the corresponding table class. From a practical point of view, it means that SQL syntax maps almost one-to-one into DAL syntax, and there is no complex metaclass programming going on under the hood as in popular ORMs, which would add latency.
WSGI ``wsgi-w``:cite ``wsgi-o``:cite (Web Server Gateway Interface) is an emerging Python standard for communication between a web server and Python applications).
Here is a screenshot of the main web2py **admin** interface:
[[image @///image/en200.png center 480px]]
### Security
``security``:inxx
The Open Web Application Security Project``owasp``:cite (OWASP) is a free and open worldwide community focused
on improving the security of application software.
OWASP has listed the top ten security issues that put web applications at risk.
That list is reproduced here, along with a description of how each issue is addressed by web2py:
- ``cross site scripting``:inxx "Cross Site Scripting (XSS): XSS flaws occur whenever an application takes user supplied data and sends it to a web browser without first validating or encoding that content. XSS allows attackers to execute scripts in the victim's browser which can hijack user sessions, deface web sites, possibly introduce worms, etc." ''web2py, by default, escapes all variables rendered in the view, preventing XSS.''
- ``injection flaws``:inxx "Injection Flaws: Injection flaws, particularly SQL injection, are common in web applications. Injection occurs when user-supplied data is sent to an interpreter as part of a command or query. The attacker's hostile data tricks the interpreter into executing unintended commands or changing data." ''web2py includes a Database Abstraction Layer that makes SQL injection impossible. Normally, SQL statements are not written by the developer. Instead, SQL is generated dynamically by the DAL, ensuring that all inserted data is properly escaped.''
- ``malicious file execution``:inxx "Malicious File Execution: Code vulnerable to remote file inclusion (RFI) allows attackers to include hostile code and data, resulting in devastating attacks, such as total server compromise." ''web2py allows only exposed functions to be executed, preventing malicious file execution. Imported functions are never exposed; only actions are exposed. web2py uses a Web-based administration interface which makes it very easy to keep track of what is exposed and what is not.''
Timothy Farrell,
Tito Garrido,
Tyrone Hattingh,
Vasile Ermicioi,
Vidul Nikolaev Petrov,
Vidul Petrov,
Vinicius Assef,
Vladimir Donnikov,
Vladyslav Kozlovsky,
Vladyslav Kozlovskyy,
Wang Huaiyu,
Wes James,
Will Stevens,
Yair Eshel,
Yarko Tymciurak,
Yoshiyuki Nakamura,
Younghyun Jo,
Zahariash.
I am sure I forgot somebody, so I apologize.
I particularly thank Anthony, Jonathan, Mariano, Bruno, Vladyslav, Martin, Nathan, Simone, Thadeus, Tim, Iceberg, Denes, Hans, Christian, Fran and Patrick for their major contributions to web2py and Anthony, Alvaro, Bruno, Denes, Felipe, Graham, Jonathan, Hans, Kyle, Mark, Michele, Richard, Robin, Roman, Scott, Shane, Sharriff, Sriram, Sterling, Stuart, Thadeus (and others) for proofreading various versions of this book. Their contribution was invaluable. If you find any errors in this book, they are exclusively my fault, probably introduced by a last-minute edit. I also thank Ryan Steffen of Wiley Custom Learning Solutions for help with publishing the first edition of this book.
+Nico Zanferrari,
Nicolas Bruxer,
Nik Klever,
Olaf Ferger,
Oliver Dain,
Olivier Roch Vilato,
Omi Chiba,
Ondrej Such,
Ont Rif,
Oscar Benjamin,
Osman Masood,
Ovidio Marinho Falcao Neto,
Pai,
Panos Jee,
Paolo Betti,
Paolo Caruccio,
Paolo Gasparello,
Paolo Velleri,
Patrick Breitenbach,
Pearu Peterson,
Peli Gergely,
Pete Hunt,
Phyo Arkar Lwin,
Pierre Thibault,
Pieter Muller,
Piotr Banasziewicz,
Ramjee Ganti,
Richard Gordon,
Richard Ree,
Robert Kooij,
Robert Valentak,
+Roberto Perdomo,
Nicolas Bruxer,
Nik Klever,
Olaf Ferger,
Oliver Dain,
Olivier Roch Vilato,
Omi Chiba,
Ondrej Such,
Ont Rif,
Oscar Benjamin,
Osman Masood,
Ovidio Marinho Falcao Neto,
Pai,
Panos Jee,
Paolo Betti,
Paolo Caruccio,
Paolo Gasparello,
Paolo Velleri,
Patrick Breitenbach,
Pearu Peterson,
Peli Gergely,
Pete Hunt,
Phyo Arkar Lwin,
Pierre Thibault,
Pieter Muller,
Piotr Banasziewicz,
Ramjee Ganti,
Richard Gordon,
Richard Ree,
Robert Kooij,
Robert Valentak,
Some of the major developers and contributors are, in alphabetical order by first name:
Some of the major contributors are, in alphabetical order by first name:
web2py is one of many web application frameworks, but it has compelling and unique features.
web2py was originally developed as a teaching tool, with the following primary motivations:
- Easy for users to learn server-side web development without compromising functionality. For this reason, web2py requires no installation and no configuration, has no dependencies (except for the source code distribution, which requires Python 2.5 and its standard library modules), and exposes most of its functionality via a Web interface, incuding an Integrated Development Environment with Debugger and database interface.
- web2py has been stable from day one because it follows a top-down design; i.e., its API was designed before it was implemented. Even as new functionality has been added, web2py has never broken backwards compatibility, and it will not break compatibility when additional functionality is added in the future.
- web2py proactively addresses the most important security issues which plague many modern web applications, as determined by OWASP``owasp``:cite below.
- web2py is lightweight. Its core libraries, including the Database Abstraction Layer, the template language, and all the helpers amount to 1.4MB. The entire source code including sample applications and images amounts to 10.4MB.
- web2py has a small footprint and is very fast. It uses the Rocket``rocket``:cite WSGI web server developed by Timothy Farrell. It is as fast as Apache with mod_wsgi, supports ssl and IPv6.
- web2py uses Python syntax for models, controllers, and views, but does not import models and controllers (as all the other Python frameworks do) - instead it executes them. This means that apps can be installed, uninstalled, and modified without having to restart the web server (even in production), and different apps can coexist without their modules interfering with one another.
- web2py uses a Database Abstraction Layer (DAL) instead of an Object Relational Mapper (ORM). From a conceptual point of view, this means that different database tables are mapped into different instances of one ``Table`` class and not into different classes, while records are mapped into instances of one ``Row`` class, not into instances of the corresponding table class. From a practical point of view, it means that SQL syntax maps almost one-to-one into DAL syntax, and there is no complex metaclass programming going on under the hood as in popular ORMs, which would add latency.
web2py is one of many web application frameworks, but it has compelling and unique features.
web2py was originally developed as a teaching tool, with the following primary motivations:
- Easy for users to learn server-side web development without compromising functionality. For this reason, web2py requires no installation and no configuration, has no dependencies (except for the source code distribution, which requires Python 2.5 and its standard library modules), and exposes most of its functionality via a Web browser interface.
- web2py has been stable from day one because it follows a top-down design; i.e., its API was designed before it was implemented. Even as new functionality has been added, web2py has never broken backwards compatibility, and it will not break compatibility when additional functionality is added in the future.
- web2py proactively addresses the most important security issues which plague many modern web applications, as determined by OWASP``owasp``:cite below.
- web2py is lightweight. Its core libraries, including the Database Abstraction Layer, the template language, and all the helpers amount to 1.4MB. The entire source code including sample applications and images amounts to 10.4MB.
- web2py has a small footprint and is very fast. It uses the Rocket``rocket``:cite WSGI web server developed by Timothy Farrell. It is as fast as Apache with mod_wsgi, supports ssl and IPv6.
- web2py uses Python syntax for models, controllers, and views, but does not import models and controllers (as all the other Python frameworks do) - instead it executes them. This means that apps can be installed, uninstalled, and modified without having to restart the web server (even in production), and different apps can coexist without their modules interfering with one another.
- web2py uses a Database Abstraction Layer (DAL) instead of an Object Relational Mapper (ORM). From a conceptual point of view, this means that different database tables are mapped into different instances of one ``Table`` class and not into different classes, while records are mapped into instances of one ``Row`` class, not into instances of the corresponding table class. From a practical point of view, it means that SQL syntax maps almost one-to-one into DAL syntax, and there is no complex metaclass programming going on under the hood as in popular ORMs, which would add latency.
+Adam Bryzak,
+Adam Gojdas,
+Adrian Klaver,
+Alain Boulch,
+Alan Etkin,
+Alec Taylor,
+Alexandre Andrade,
Alexey Nezhdanov,
Alvaro Justen,
+Anand Vaidya,
+Anatoly Belyakov,
+Ander Arbelaiz,
+Anders Roos,
+Andrew Replogle,
Andrew Willimott,
Angelo Compagnucci,
+Angelo and Villas,
+Annet Vermeer,
Anthony Bastardi,
+Anton Muecki,
Antonio Ramos,
Arun Rajeevan,
Attila Csipa,
+Ben Goosman,
Ben Reinhart,
+Benjamin,
+Bernd Rothert,
Bill Ferret,
+Blomqvist,
Boris Manojlovic,
Branko Vukelic,
+Brent Zeiben,
+Brian Cottingham,
+Brian Harrison,
Brian Meredyk,
Bruno Rocha,
+CJ Lazell,
+Caleb Hattingh,
Carlos Galindo,
+Carlos Hanson,
Carsten Haese,
+Cedric Meyer,
+Charles Law,
+Charles Winebrinner,
Chris Clark,
+Chris May,
+Chris Sanders,
Christian Foster Howes,
Christopher Smiga,
+Christopher Steel,
+Clavin Sim,
Cliff Kachinske,
+Corne Dickens,
Craig Younkins,
+Dan McGee,
+Dan Ragubba,
+Daniel Gonz,
+Daniel Haag,
Daniel Lin,
+Dave Stoll,
+David Adley,
David Harrison,
+David Lin,
+David Marko,
David Wagner,
Denes Lengyel,
+Diaz Luis,
Dirk Krause,
+Dominic Koenig,
+Doug Warren,
+Douglas Philips,
Douglas Soares de Andrade,
+Douglas and Alan,
+Dustin Bensing,
+Elcio Ferreira,
Eric Vicenti,
Falko Krause,
Farsheed Ashouri,
+Felipe Meirelles,
+Flavien Scheurer,
Fran Boon,
Francisco Gama,
Fred Yanowski,
+Friedrich Weber,
+Gabriele Alberti,
+Gergely Kontra,
+Gergely Peli,
+Gerley Kontra,
Gilson Filho,
+Glenn Caltech,
Graham Dumpleton,
+Gregory Benjamin,
+Gustavo Di Pietro,
Gyuris Szabolcs,
Hamdy Abdel-Badeea,
+Hans C. v. Stockhausen,
Hans Donner,
Hans Murx,
Huaiyu Wang,
Ian Reinhart Geiser,
+Iceberg,
+Igor Gassko,
Ismael Serratos,
Jan Beilicke,
+Jay Kelkar,
+Jeff Bauer,
+Jesus Matrinez,
+Jim Karsten,
+Joachim Breitsprecher,
+Joakim Eriksson,
+Joe Barnhart,
+Joel Carrier,
+Joel Samuelsson,
+John Heenan,
+Jon Romero,
+Jonas Rundberg,
Jonathan Benn,
Jonathan Lundell,
Jose Jachuf,
+Joseph Piron,
+Josh Goldfoot,
Josh Jaques,
José Vicente de Sousa,
+Jurgis Pralgauskis,
Keith Yang,
Kenji Hosoda,
+Kenneth Lundstr,
+Kirill Spitsin,
Kyle Smith,
+Larry Weinberg,
Limodou,
+Loren McGinnis,
+Louis DaPrato,
+Luca Zachetti,
Lucas D'Ávila,
+Madhukar R Pai,
+Manuele Presenti,
+Marc Abramowitz,
Marcel Hellkamp,
+Marcel Leuthi,
Marcello Della Longa,
+Maria Mitica,
Mariano Reingart,
+Marin Prajic,
+Marin Pranji,
+Marius van Niekerk,
+Mark Kirkwood,
Mark Larsen,
Mark Moore,
Markus Gritsch,
+Mart Senecal,
Martin Hufsky,
Martin Mulone,
+Martin Weissenboeck,
Mateusz Banach,
+Mathew Grabau,
+Mathieu Clabaut,
+Matt Doiron,
+Matthew Norris,
+Michael Fig,
+Michael Herman,
+Michael Howden,
+Michael Jursa,
+Michael Toomim,
Michael Willis,
Michele Comitini,
+Miguel Goncalves,
+Miguel Lopez,
+Mike Amy,
+Mike Dickun,
+Mike Ellis,
+Mike Pechkin,
+Milan Melena,
+Muhammet Aydin,
+Napoleon Moreno,
Nathan Freeze,
Niall Sweeny,
Niccolo Polo,
+Nick Groenke,
+Nico de Groot,
Nicolas Bruxer,
+Nik Klever,
Olaf Ferger,
+Oliver Dain,
+Olivier Roch Vilato,
Omi Chiba,
Ondrej Such,
+Ont Rif,
+Oscar Benjamin,
+Osman Masood,
Ovidio Marinho Falcao Neto,
Pai,
+Panos Jee,
+Paolo Betti,
Paolo Caruccio,
+Paolo Gasparello,
+Paolo Velleri,
Patrick Breitenbach,
+Pearu Peterson,
+Peli Gergely,
+Pete Hunt,
Phyo Arkar Lwin,
Pierre Thibault,
+Pieter Muller,
+Piotr Banasziewicz,
Ramjee Ganti,
+Richard Gordon,
+Richard Ree,
+Robert Kooij,
+Robert Valentak,
Robin Bhattacharyya,
+Roman Bataev,
+Ron McOuat,
Ross Peoples,
Ruijun Luo,
+Running Calm,
Ryan Seto,
+Salomon Derossi,
+Sam Sheftel,
Scott Roberts,
Sergey Podlesnyi,
Sharriff Aina,
Simone Bizzotto,
Sriram Durbha,
Sterling Hankins,
Stuart Rackham,
Telman Yusupov,
Thadeus Burgess,
+Thomas Dallagnese,
+Tim Farrell,
Tim Michelsen,
Timothy Farrell,
+Tito Garrido,
+Tyrone Hattingh,
+Vasile Ermicioi,
Vidul Nikolaev Petrov,
+Vidul Petrov,
Vinicius Assef,
+Vladimir Donnikov,
+Vladyslav Kozlovsky,
Vladyslav Kozlovskyy,
+Wang Huaiyu,
+Wes James,
+Will Stevens,
+Yair Eshel,
+Yarko Tymciurak,
+Yoshiyuki Nakamura,
+Younghyun Jo,
Zahariash.
I am sure I forgot somebody, so I apologize.
Alexey Nezhdanov,
Alvaro Justen,
Andrew Willimott,
Angelo Compagnucci,
Anthony Bastardi,
Antonio Ramos,
Arun K. Rajeevan,
Attila Csipa,
Ben Reinhart,
Bill Ferret,
Boris Manojlovic,
Branko Vukelic,
Brian Meredyk,
Bruno Rocha,
Carlos Galindo,
Carsten Haese,
Chris Clark,
-Chris Steel,
Christian Foster Howes,
Christopher Smiga,
-CJ Lazell,
Cliff Kachinske,
Craig Younkins,
Daniel Lin,
David Harrison,
David Wagner,
Denes Lengyel,
Dirk Krause,
Douglas Soares de Andrade,
Eric Vicenti,
Falko Krause,
Farsheed Ashouri,
Fran Boon,
Francisco Gama,
Fred Yanowski,
Gilson Filho,
Graham Dumpleton,
Gyuris Szabolcs,
Hamdy Abdel-Badeea,
Hans Donner,
Hans Murx,
Hans C. v. Stockhausen,
Ian Reinhart Geiser,
Ismael Serratos,
Jan Beilicke,
Jonathan Benn,
Jonathan Lundell,
-Josh Goldfoot,
Jose Jachuf,
Josh Jaques,
José Vicente de Sousa,
Keith Yang,
Kenji Hosoda,
Kyle Smith,
Limodou,
Lucas D'Ávila,
-Marcel Leuthi,
Marcel Hellkamp,
Marcello Della Longa,
Mariano Reingart,
Mark Larsen,
Mark Moore,
Markus Gritsch,
Martin Hufsky,
Martin Mulone,
Mateusz Banach,
-Miguel Lopez,
Michael Willis,
Michele Comitini,
Nathan Freeze,
Niall Sweeny,
Niccolo Polo,
Nicolas Bruxer,
Olaf Ferger,
Omi Chiba,
Ondrej Such,
Ovidio Marinho Falcao Neto,
Pai,
Paolo Caruccio,
Patrick Breitenbach,
Phyo Arkar Lwin,
Pierre Thibault,
Ramjee Ganti,
Robin Bhattacharyya,
Ross Peoples,
Ruijun Luo,
Ryan Seto,
Scott Roberts,
Sergey Podlesnyi,
Sharriff Aina,
Simone Bizzotto,
Sriram Durbha,
Sterling Hankins,
Stuart Rackham,
Telman Yusupov,
Thadeus Burgess,
Tim Michelsen,
Timothy Farrell,
-Yair Eshel,
-Yarko Tymciurak,
-Younghyun Jo,
Vidul Nikolaev Petrov,
Vinicius Assef,
Vladyslav Kozlovskyy,
Zahariash.
-
I am sure I forgot somebody, so I apologize.
web2py includes a Database Abstraction Layer (DAL) that writes SQL``sql-w``:cite dynamically so that you, the developer, don't have to. The DAL knows how to generate SQL transparently for
SQLite``sqlite``:cite, MySQL``mysql``:cite, PostgreSQL``postgres``:cite, MSSQL``mssql``:cite,
FireBird``firebird``:cite, Oracle``oracle``:cite, IBM DB2``db2``:cite, Informix``informix``:cite, and
Ingres``ingresdb``:cite.
The DAL can also generate function calls for the Google Datastore
when running on the Google App Engine (GAE)``gae``:cite.
Experimentally we support more databases. Please check on the web2py web site and mailing list for more recent adapters.
Once one or more database tables are defined, web2py also generates a fully functional web-based database
administration interface to access the database and the tables.
web2py differs from other web frameworks in that it is the only framework to fully embrace the Web 2.0
paradigm, where the web is the computer. In fact, web2py does not require installation or configuration; it
runs on any architecture that can run Python (Windows, Windows CE, Mac OS X, iOS, and Unix/Linux), and the development, deployment, and maintenance phases for the applications can be done via a local or remote web interface. web2py runs with CPython (the C implementation) and PyPy (Python written in Python), on Python versions 2.5, 2.6, and 2.7, although "officially" it only supports 2.5 so that we can guarantee backward compatibility for applications.
web2py provides a ticketing system. If an error occurs, a ticket is issued to the user,
and the error is logged for the administrator.
web2py is open source and released under the LGPL version 3 license.
Another feature of web2py is that we, its developers, commit to maintain backward compatibility in future versions.
We have done so since the first release of web2py in October, 2007.
New features have been added and bugs have been fixed, but if a program worked with web2py 1.0, that program will still work today.
Here are some examples of web2py statements that illustrate its power and simplicity. The following code:
``
db.define_table('person', Field('name'), Field('image', 'upload'))
``:code
using an all-upper-case "DIV" is a more natural choice. Moreover, this approach
free to create a class called "Div" if they choose to do so.
Our syntax also maps naturally into the DOM notation of most browsers (including, for example, Firefox).
According to the Python style guide, all-upper-case strings should be used for constants and not
variables. Continuing with our example, even considering that ``DIV`` is a class,
it is a special class that should never be modified by
the user because doing so would break other web2py applications.
Hence, we believe this qualifies the ``DIV`` class as
something that should be treated as a constant, further justifying our choice of notation.
In summary, the following conventions are followed:
- HTML helpers and validators are all upper case for the reasons discussed above (for example ``DIV``, ``A``, ``FORM``, ``URL``).
- The translator object ``T`` is upper case despite the fact that it is an instance of a class and not a class itself. Logically the translator object performs an action similar to the HTML helpers, it affects rendering part of the presentation. Also, ``T`` needs to be easy to locate in the code and must have a short name.
- DAL classes follow the Python style guide (first letter capitalized), for example ``Table``, ``Field``, ``Query``, ``Row``, ``Rows``, etc.
In all other cases we believe we have followed, as much as possible,
the Python Style Guide (PEP8).
For example all instance objects are lower-case (request, response, session, cache), and all internal classes are capitalized.
In all the examples of this book, web2py keywords are shown in bold, while strings and comments are shown in italic.
web2py includes a Database Abstraction Layer (DAL) that writes SQL``sql-w``:cite dynamically so that you, the developer, don't have to. The DAL knows how to generate SQL transparently for
SQLite``sqlite``:cite, MySQL``mysql``:cite, PostgreSQL``postgres``:cite, MSSQL``mssql``:cite,
FireBird``firebird``:cite, Oracle``oracle``:cite, IBM DB2``db2``:cite, Informix``informix``:cite, and
Ingres``ingresdb``:cite.
The DAL can also generate function calls for the Google Datastore
when running on the Google App Engine (GAE)``gae``:cite.
Experimentally we support more databases. Please check on the web2py web site and mailing list for more recent adapters.
Once one or more database tables are defined, web2py also generates a fully functional web-based database
administration interface to access the database and the tables.
web2py differs from other web frameworks in that it is the only framework to fully embrace the Web 2.0
paradigm, where the web is the computer. In fact, web2py does not require installation or configuration; it
runs on any architecture that can run Python (Windows, Windows CE, Mac OS X, iOS, and Unix/Linux), and the development, deployment, and maintenance phases for the applications can be done via a local or remote web interface. web2py runs with CPython (the C implementation) and PyPy (Python written in Python), on Python versions 2.5, 2.6, and 2.7, although "officially" it only supports 2.5 so that we can guarantee backward compatibility for applications.
web2py provides a ticketing system. If an error occurs, a ticket is issued to the user,
and the error is logged for the administrator.
web2py is open source and released under the LGPL version 3 license.
Another feature of web2py is that we, its developers, commit to maintain backward compatibility in future versions.
We have done so since the first release of web2py in October, 2007.
New features have been added and bugs have been fixed, but if a program worked with web2py 1.0, that program will still work today.
Here are some examples of web2py statements that illustrate its power and simplicity. The following code:
``
db.define_table('person', Field('name'), Field('image', 'upload'))
``:code
using an all-upper-case "DIV" is a more natural choice. Moreover, this approach
free to create a class called "Div" if they choose to do so.
Our syntax also maps naturally into the DOM notation of most browsers (including, for example, Firefox).
According to the Python style guide, all-upper-case strings should be used for constants and not
variables. Continuing with our example, even considering that ``DIV`` is a class,
it is a special class that should never be modified by
the user because doing so would break other web2py applications.
Hence, we believe this qualifies the ``DIV`` class as
something that should be treated as a constant, further justifying our choice of notation.
In summary, the following conventions are followed:
- HTML helpers and validators are all upper case for the reasons discussed above (for example ``DIV``, ``A``, ``FORM``, ``URL``).
- The translator object ``T`` is upper case despite the fact that it is an instance of a class and not a class itself. Logically the translator object performs an action similar to the HTML helpers, it affects rendering part of the presentation. Also, ``T`` needs to be easy to locate in the code and must have a short name.
- DAL classes follow the Python style guide (first letter capitalized), for example ``Table``, ``Field``, ``Query``, ``Row``, ``Rows``, etc.
In all other cases we believe we have followed, as much as possible,
the Python Style Guide (PEP8).
For example all instance objects are lower-case (request, response, session, cache), and all internal classes are capitalized.
In all the examples of this book, web2py keywords are shown in bold, while strings and comments are shown in italic.
-
web2py differs from other web frameworks in that it is the only framework to fully embrace the Web 2.0
paradigm, where the web is the computer. In fact, web2py does not require installation or configuration; it
runs on any architecture that can run Python (Windows, Windows CE, Mac OS X, iOS, and Unix/Linux), and the development, deployment, and maintenance phases for the applications can be done via a local or remote web interface. web2py runs with CPython (the C implementation) and PyPy (Python written in Python), on Python versions 2.5, 2.6, and 2.7, although "officially" it only supports 2.5 so that we can guarantee backward compatibility for applications.
web2py provides a ticketing system. If an error occurs, a ticket is issued to the user,
and the error is logged for the administrator.
web2py is open source and released under the LGPL version 3 license.
Another feature of web2py is that we, its developers, commit to maintain backward compatibility in future versions.
We have done so since the first release of web2py in October, 2007.
New features have been added and bugs have been fixed, but if a program worked with web2py 1.0, that program will still work today.
Here are some examples of web2py statements that illustrate its power and simplicity. The following code:
``
db.define_table('person', Field('name'), Field('image', 'upload'))
``:code
creates a database table called "person" with two fields: "name", a string; and "image", something that
needs to be uploaded (the actual image). If the table already exists but does not match this definition, it is altered appropriately.
Given the table defined above, the following code:
``
form = SQLFORM(db.person).process()
``:code
creates an insert form for this table that allows users to upload images. It also
validates a submitted form, renames the uploaded image in a secure way, stores the image in a file,
inserts the corresponding record in the database, prevents double submission, and eventually modifies
the form itself by adding error messages if the data submitted by the user does not pass validation.
+This code embeds a fully working wiki with tags, search, tag cloud, permissions, media attachments, adn oembed support:
+
+``
+def index(): return auth.wiki()
+``
+
+The following code instead:
``
@auth.requires_permission('read','person')
def f(): ....
``:code
prevents visitors from accessing the function ``f`` unless the visitor is a member of a group whose members have permissions to "read" records of table "person". If the visitor is not logged in, he gets directed to a login page (provided by default by web2py).
web2py also supports components, i.e. actions which can be loaded in a view and interact with the visitor via Ajax without re-loading the entire page. This is done via a ``LOAD`` helper which allows very modular design of applications; it is discussed in chapter 3 in the context of the wiki and, in some detail, in the last chapter of this book.
web2py differs from other web frameworks in that it is the only framework to fully embrace the Web 2.0
paradigm, where the web is the computer. In fact, web2py does not require installation or configuration; it
runs on any architecture that can run Python (Windows, Windows CE, Mac OS X, iOS, and Unix/Linux), and the development, deployment, and maintenance phases for the applications can be done via a local or remote web interface. web2py runs with CPython (the C implementation) and Jython (the Java implementation), on Python versions 2.4, 2.5, 2.6, and 2.7, although "officially" it only supports 2.5 so that we can guarantee backward compatibility for applications.
web2py provides a ticketing system. If an error occurs, a ticket is issued to the user,
and the error is logged for the administrator.
web2py is open source and released under the LGPL version 3 license.
Another feature of web2py is that we, its developers, commit to maintain backward compatibility in future versions.
We have done so since the first release of web2py in October, 2007.
New features have been added and bugs have been fixed, but if a program worked with web2py 1.0, that program will still work today.
Here are some examples of web2py statements that illustrate its power and simplicity. The following code:
``
db.define_table('person', Field('name'), Field('image', 'upload'))
``:code
creates a database table called "person" with two fields: "name", a string; and "image", something that
needs to be uploaded (the actual image). If the table already exists but does not match this definition, it is altered appropriately.
Given the table defined above, the following code:
``
form = SQLFORM(db.person).process()
``:code
creates an insert form for this table that allows users to upload images. It also
validates a submitted form, renames the uploaded image in a secure way, stores the image in a file,
inserts the corresponding record in the database, prevents double submission, and eventually modifies
the form itself by adding error messages if the data submitted by the user does not pass validation.
-The following code:
``
@auth.requires_permission('read','person')
def f(): ....
``:code
prevents visitors from accessing the function ``f`` unless the visitor is a member of a group whose members have permissions to "read" records of table "person". If the visitor is not logged in, he gets directed to a login page (provided by default by web2py).
-The following code embeds a page component.
-``
-{{=LOAD('other_controller','function.load',ajax=True, ajax_trap=True)}}
-``:code
-
-This instructs web2py to load in a view the content generated by the other controller function (this works with any function). It loads the content via Ajax, embeds it into the current page (using the current layout, not the layout of the other_controller function), and traps all forms contained in the loaded content so that they are also submitted via Ajax without reloading the page. It can also LOAD content from non-web2py applications.
-
The LOAD helper allows very modular design of applications; it is discussed in some detail in the last chapter of this book.
**"db.py" is the model:**
``
db = DAL('sqlite://storage.sqlite')
db.define_table('contact',
Field('name'),
Field('phone'))
``:code
It connects to the database (in this example a SQLite database stored in the ``storage.sqlite`` file) and
defines a table called ``contact``. If the table does not exist, web2py creates it and, transparently
and in the background,
generates SQL code in the appropriate SQL dialect for the specific database engine used.
The developer can
see the generated SQL but does not need to change the code if the database back-end, which defaults to
SQLite, is replaced with MySQL, PostgreSQL, MSSQL, FireBird, Oracle, DB2, Informix, Interbase, Ingres, and the Google App Engine (both SQL and NoSQL).
Once a table is defined and created, web2py also generates a fully functional web-based database
administration interface, called **appadmin**, to access the database and the tables.
**"default.py" is the controller:**
``
def contacts():
grid=SQLFORM.grid(db.contact, user_signature=False)
return locals()
``:code
In web2py, URLs are mapped to Python modules and function calls. In this case, the controller contains
a single function (or "action") called ``contacts``. An action may
return a string (the returned web page) or a Python dictionary (a set of
``key:value`` pairs) or the set of local variables (as in this example).
If the function returns a dictionary, it is passed to a view with the same
name as the controller/function, which in turn renders the page.
In this example, the function ``contacts`` generates a select/search/create/update/delete grid for table ``db.contact``
and returns the grid to the view.
**"default/contacts.html" is the view:**
"db.py" is the model:
``
db = DAL('sqlite://storage.sqlite')
db.define_table('contact',
Field('name'),
Field('phone'))
``:code
It connects to the database (in this example a SQLite database stored in the ``storage.sqlite`` file) and
defines a table called ``contact``. If the table does not exist, web2py creates it and, transparently
and in the background,
generates SQL code in the appropriate SQL dialect for the specific database engine used.
The developer can
see the generated SQL but does not need to change the code if the database back-end, which defaults to
SQLite, is replaced with MySQL, PostgreSQL, MSSQL, FireBird, Oracle, DB2, Informix, Interbase, Ingres, and the Google App Engine (both SQL and NoSQL).
Once a table is defined and created, web2py also generates a fully functional web-based database
administration interface, called **appadmin**, to access the database and the tables.
"default.py" is the controller:
``
def contacts():
grid=SQLFORM.grid(db.contact, user_signature=False)
return locals()
``:code
In web2py, URLs are mapped to Python modules and function calls. In this case, the controller contains
a single function (or "action") called ``contacts``. An action may
return a string (the returned web page) or a Python dictionary (a set of
``key:value`` pairs) or the set of local variables (as in this example).
If the function returns a dictionary, it is passed to a view with the same
name as the controller/function, which in turn renders the page.
In this example, the function ``contacts`` generates a select/search/create/update/delete grid for table ``db.contact``
and returns the grid to the view.
"default/contacts.html" is the view:
web2py is one of many web application frameworks, but it has compelling and unique features.
web2py was originally developed as a teaching tool, with the following primary motivations:
- Easy for users to learn server-side web development without compromising functionality. For this reason, web2py requires no installation and no configuration, has no dependencies (except for the source code distribution, which requires Python 2.5 and its standard library modules), and exposes most of its functionality via a Web browser interface.
- web2py has been stable from day one because it follows a top-down design; i.e., its API was designed before it was implemented. Even as new functionality has been added, web2py has never broken backwards compatibility, and it will not break compatibility when additional functionality is added in the future.
- web2py proactively addresses the most important security issues which plague many modern web applications, as determined by OWASP``owasp``:cite below.
- web2py is lightweight. Its core libraries, including the Database Abstraction Layer, the template language, and all the helpers amount to 1.4MB. The entire source code including sample applications and images amounts to 10.4MB.
- web2py has a small footprint and is very fast. It uses the Rocket``rocket``:cite WSGI web server developed by Timothy Farrell. It is as fast as Apache with mod_wsgi, supports ssl and IPv6.
- web2py uses Python syntax for models, controllers, and views, but does not import models and controllers (as all the other Python frameworks do) - instead it executes them. This means that apps can be installed, uninstalled, and modified without having to restart the web server (even in production), and different apps can coexist without their modules interfering with one another.
- web2py uses a Database Abstraction Layer (DAL) instead of an Object Relational Mapper (ORM). From a conceptual point of view, this means that different database tables are mapped into different instances of one ``Table`` class and not into different classes, while records are mapped into instances of one ``Row`` class, not into instances of the corresponding table class. From a practical point of view, it means that SQL syntax maps almost one-to-one into DAL syntax, and there is no complex metaclass programming going on under the hood as in popular ORMs, which would add latency.
web2py is one of many web application frameworks, but it has compelling and unique features.
web2py was originally developed as a teaching tool, with the following primary motivations:
- Easy for users to learn server-side web development without compromising functionality. For this reason, web2py requires no installation and no configuration, has no dependencies (except for the source code distribution, which requires Python 2.5 and its standard library modules), and exposes most of its functionality via a Web browser interface.
- web2py has been stable from day one because it follows a top-down design; i.e., its API was designed before it was implemented. Even as new functionality has been added, web2py has never broken backwards compatibility, and it will not break compatibility when additional functionality is added in the future.
- web2py proactively addresses the most important security issues which plague many modern web applications, as determined by OWASP``owasp``:cite below.
- web2py is lightweight. Its core libraries, including the Database Abstraction Layer, the template language, and all the helpers amount to 1.4MB. The entire source code including sample applications and images amounts to 10.4MB.
- web2py has a small footprint and is very fast. It uses the Rocket``rocket``:cite WSGI web server developed by Timothy Farrell. It is as fast as Apache with mod_wsgi, supports ssl and ipv6.
- web2py uses Python syntax for models, controllers, and views, but does not import models and controllers (as all the other Python frameworks do) - instead it executes them. This means that apps can be installed, uninstalled, and modified without having to restart the web server (even in production), and different apps can coexist without their modules interfering with one another.
- web2py uses a Database Abstraction Layer (DAL) instead of an Object Relational Mapper (ORM). From a conceptual point of view, this means that different database tables are mapped into different instances of one ``Table`` class and not into different classes, while records are mapped into instances of one ``Row`` class, not into instances of the corresponding table class. From a practical point of view, it means that SQL syntax maps almost one-to-one into DAL syntax, and there is no complex metaclass programming going on under the hood as in popular ORMs, which would add latency.
Given the table defined above, the following code:
``
form = SQLFORM(db.person).process()
``:code
creates an insert form for this table that allows users to upload images. It also
validates a submitted form, renames the uploaded image in a secure way, stores the image in a file,
inserts the corresponding record in the database, prevents double submission, and eventually modifies
the form itself by adding error messages if the data submitted by the user does not pass validation.
The following code:
``
@auth.requires_permission('read','person')
def f(): ....
``:code
prevents visitors from accessing the function ``f`` unless the visitor is a member of a group whose members have permissions to "read" records of table "person". If the visitor is not logged in, he gets directed to a login page (provided by default by web2py).
The following code embeds a page component.
``
{{=LOAD('other_controller','function.load',ajax=True, ajax_trap=True)}}
``:code
Here is a screenshot of the main web2py **admin** interface:
[[image @///image/en200.png center 480px]]
### Security
``security``:inxx
The Open Web Application Security Project``owasp``:cite (OWASP) is a free and open worldwide community focused
on improving the security of application software.
OWASP has listed the top ten security issues that put web applications at risk.
That list is reproduced here, along with a description of how each issue is addressed by web2py:
- ``cross site scripting``:inxx "Cross Site Scripting (XSS): XSS flaws occur whenever an application takes user supplied data and sends it to a web browser without first validating or encoding that content. XSS allows attackers to execute scripts in the victim's browser which can hijack user sessions, deface web sites, possibly introduce worms, etc." ''web2py, by default, escapes all variables rendered in the view, preventing XSS.''
- ``injection flaws``:inxx "Injection Flaws: Injection flaws, particularly SQL injection, are common in web applications. Injection occurs when user-supplied data is sent to an interpreter as part of a command or query. The attacker's hostile data tricks the interpreter into executing unintended commands or changing data." ''web2py includes a Database Abstraction Layer that makes SQL injection impossible. Normally, SQL statements are not written by the developer. Instead, SQL is generated dynamically by the DAL, ensuring that all inserted data is properly escaped.''
- ``malicious file execution``:inxx "Malicious File Execution: Code vulnerable to remote file inclusion (RFI) allows attackers to include hostile code and data, resulting in devastating attacks, such as total server compromise." ''web2py allows only exposed functions to be executed, preventing malicious file execution. Imported functions are never exposed; only actions are exposed. web2py uses a Web-based administration interface which makes it very easy to keep track of what is exposed and what is not.''
- ``insecure object reference``:inxx "Insecure Direct Object Reference: A direct object reference occurs when a developer exposes a reference to an internal implementation object, such as a file, directory, database record, or key, as a URL or form parameter. Attackers can manipulate those references to access other objects without authorization." ''web2py does not expose any internal objects; moreover, web2py validates all URLs, thus preventing directory traversal attacks. web2py also provides a simple mechanism to create forms that automatically validate all input values.''
- ``CSRF``:inxx "Cross Site Request Forgery (CSRF): A CSRF attack forces a logged-on victim's browser to send a pre-authenticated request to a vulnerable web application, which then forces the victim's browser to perform a hostile action to the benefit of the attacker. CSRF can be as powerful as the web application that it attacks." ''web2py prevents CSRF as well as accidental double submission of forms by assigning a one-time random token to each form. Moreover web2py uses UUID for session cookie.''
- ``information leakage``:inxx ``improper error handling``:inxx "Information Leakage and Improper Error Handling: Applications can unintentionally leak information about their configuration, internal workings, or violate privacy through a variety of application problems. Attackers use this weakness to steal sensitive data, or conduct more serious attacks." ''web2py includes a ticketing system. No error can result in code being exposed to the users. All errors are logged and a ticket is issued to the user that allows error tracking. But errors and source code are accessible only to the administrator.''
- "Broken Authentication and Session Management: Account credentials and session tokens are often not properly protected. Attackers compromise passwords, keys, or authentication tokens to assume other users' identities." ''web2py provides a built-in mechanism for administrator authentication, and it manages sessions independently for each application. The administrative interface also forces the use of secure session cookies when the client is not "localhost". For applications, it includes a powerful Role Based Access Control API.''
- ``cryptographic store``:inxx "Insecure Cryptographic Storage: Web applications rarely use cryptographic functions properly to protect data and credentials. Attackers use weakly protected data to conduct identity theft and other crimes, such as credit card fraud." ''web2py uses the MD5 or the HMAC+SHA-512 hash algorithms to protect stored passwords. Other algorithms are also available.''
- ``secure communications``:inxx "Insecure Communications: Applications frequently fail to encrypt network traffic when it is necessary to protect sensitive communications." ''web2py includes the SSL-enabled``ssl``:cite Rocket WSGI server, but it can also use Apache or Lighttpd and mod_ssl to provide SSL encryption of communications.''
- ``access restriction``:inxx "Failure to Restrict URL Access: Frequently an application only protects sensitive functionality by preventing the display of links or URLs to unauthorized users. Attackers can use this weakness to access and perform unauthorized operations by accessing those URLs directly." ''web2py maps URL requests to Python modules and functions. web2py provides a mechanism for declaring which functions are public and which require authentication and authorization. The included Role Based Access Control API allow developers to restrict access to any function based on login, group membership or group based permissions. The permissions are very granular and can be combined with database filters to allow, for example, to give access to specific tables and/or records. web2py also allows digitally signed URL and provides API to digitally sign ajax callbacks.''
web2py was reviewed for security and you can find the result of the review in ref.``pythonsecurity``:cite.
### In the box
You can download web2py from the official web site:
``
http://www.web2py.com
``:code
web2py is composed of the following components:
- **libraries**: provide core functionality of web2py and are accessible programmatically.
- **web server**: the Rocket WSGI web server.
- the **admin** application: used to create, design, and manage other web2py applications. **admin** provide a complete web-based Integrated Development Environment (IDE) for building web2py applications. It also includes other functionality, such as web-based testing and a web-based shell.
- the **examples** application: contains documentation and interactive examples. **examples** is a clone of the official web2py.com web site, and includes epydoc documentation.
- the **welcome** application: the basic scaffolding template for any other application. By default it includes a pure CSS cascading menu and user authentication (discussed in Chapter 9).
web2py is distributed in source code, and in binary form for Microsoft Windows and for Mac OS X.
I am sure I forgot somebody, so I apologize.
I particularly thank Anthony, Jonathan, Mariano, Bruno, Vladyslav, Martin, Nathan, Simone, Thadeus, Tim, Iceberg, Denes, Hans, Christian, Fran and Patrick for their major contributions to web2py and Anthony, Alvaro, Bruno, Denes, Felipe, Graham, Jonathan, Hans, Kyle, Mark, Michele, Richard, Robin, Roman, Scott, Shane, Sharriff, Sriram, Sterling, Stuart, Thadeus (and others) for proofreading various versions of this book. Their contribution was invaluable. If you find any errors in this book, they are exclusively my fault, probably introduced by a last-minute edit. I also thank Ryan Steffen of Wiley Custom Learning Solutions for help with publishing the first edition of this book.
web2py contains code from the following authors, whom I would like to thank:
Guido van Rossum for Python``python``:cite, Peter Hunt, Richard Gordon, Timothy Farrell for the Rocket``rocket``:cite web server, Christopher Dolivet for EditArea``editarea``:cite, Bob Ippolito for simplejson``simplejson``:cite, Simon Cusack and Grant Edwards for pyRTF``pyrtf``:cite, Dalke Scientific Software for pyRSS2Gen``pyrss2gen``:cite, Mark Pilgrim for feedparser``feedparser``:cite, Trent Mick for markdown2``markdown2``:cite, Allan Saddi for fcgi.py, Evan Martin for the Python memcache module``memcache``:cite, John Resig for jQuery``jquery``:cite.
The cover of this book was designed by Peter Kirchner at Young Designers.
I thank Helmut Epp (provost of DePaul University), David Miller (Dean of the College of Computing and Digital Media of DePaul University), and Estia Eichten (Member of MetaCryption LLC), for their continuous trust and support.
Finally, I wish to thank my wife, Claudia, and my son, Marco, for putting up with me during the many hours I have spent developing web2py, exchanging emails with users and collaborators, and writing this book. This book is dedicated to them.
### About this book
This book includes the following chapters, besides this introduction:
- Chapter 2 is a minimalist introduction to Python. It assumes knowledge of both procedural and object-oriented programming concepts such as loops, conditions, function calls and classes, and covers basic Python syntax. It also covers examples of Python modules that are used throughout the book. If you already know Python, you may skip Chapter 2.
- Chapter 3 shows how to start web2py, discusses the administrative interface, and guides the reader through various examples of increasing complexity: an application that returns a string, a counter application, an image blog, and a full blown wiki application that allows image uploads and comments, provides authentication, authorization, web services and an RSS feed. While reading this chapter, you may need to refer to Chapter 2 for general Python syntax and to the following chapters for a more detailed reference about the functions that are used.
- Chapter 4 covers more systematically the core structure and libraries: URL mapping, request, response, sessions, caching, cron, internationalization and general workflow.
- Chapter 5 is a reference for the template language used to build views. It shows how to embed Python code into HTML, and demonstrates the use of helpers (objects that can generate HTML).
- Chapter 6 covers the Database Abstraction Layer, or DAL. The syntax of the DAL is presented through a series of examples.
- Chapter 7 covers forms, form validation and form processing. FORM is the low level helper for form building. SQLFORM is the high level form builder. In Chapter 7 we also discuss legacy Create/Read/Update/Delete (CRUD) API.
- Chapter 8 covers communication with as sending emails and SMSes.
- Chapter 9 covers authentication, authorization and the extensible Role-Based Access Control mechanism available in web2py. Mail configuration and CAPTCHA are also discussed here, since they are used for authentication. In the third edition of the book we have added extensive coverage of integration with third-party authentication mechanisms such as OpenID, OAuth, Google, Facebook, LinkedIn, etc.
- Chapter 10 is about creating web services in web2py. We provide examples of integration with the Google Web Toolkit via Pyjamas, and with Adobe Flash via PyAMF.
- Chapter 11 is about web2py and jQuery recipes. web2py is designed mainly for server-side programming, but it includes jQuery, since we have found it to be the best open-source JavaScript library available for effects and Ajax. In this chapter, we discuss how to effectively use jQuery with web2py.
- Chapter 12 discusses web2py components and plugins as a way to build modular applications. We provide an example of a plugin that implements many commonly used functionality, such as charting, comments, tagging, and wiki.
- Chapter 13 is about production deployment of web2py applications. We mainly address three possible production scenarios: on a Linux web server or a set of servers (which we consider the main deployment alternative), running as a service on a Microsoft Windows environment, and deployment on the Google Applications Engine. In this chapter, we also discuss security and scalability issues.
- Chapter 14 contains a variety of other recipes to solve specific tasks, including upgrades, geocoding, pagination, the Twitter API, and more.
Given the table defined above, the following code:
``
form = crud.create(db.person)
``:code
creates an insert form for this table that allows users to upload images. It also
validates a submitted form, renames the uploaded image in a secure way, stores the image in a file,
inserts the corresponding record in the database, prevents double submission, and eventually modifies
the form itself by adding error messages if the data submitted by the user does not pass validation.
The following code:
``
@auth.requires_permission('read','person')
def f(): ....
``:code
prevents visitors from accessing the function ``f`` unless the visitor is a member of a group whose members have permissions to "read" records of table "person". If the visitor is not logged in, he gets directed to a login page (provided by default by web2py).
The following code embeds a page component.
``
{{=LOAD('other_controller','function.load',ajax=True, ajax_trap=True)}}
``:code
Here is a screenshot of the main web2py **admin** interface:
[[image @///image/en200.png center 480px]]
### Security
``security``:inxx
The Open Web Application Security Project``owasp``:cite (OWASP) is a free and open worldwide community focused
on improving the security of application software.
OWASP has listed the top ten security issues that put web applications at risk.
That list is reproduced here, along with a description of how each issue is addressed by web2py:
- ``cross site scripting``:inxx "Cross Site Scripting (XSS): XSS flaws occur whenever an application takes user supplied data and sends it to a web browser without first validating or encoding that content. XSS allows attackers to execute scripts in the victim's browser which can hijack user sessions, deface web sites, possibly introduce worms, etc." ''web2py, by default, escapes all variables rendered in the view, preventing XSS.''
- ``injection flaws``:inxx "Injection Flaws: Injection flaws, particularly SQL injection, are common in web applications. Injection occurs when user-supplied data is sent to an interpreter as part of a command or query. The attacker's hostile data tricks the interpreter into executing unintended commands or changing data." ''web2py includes a Database Abstraction Layer that makes SQL injection impossible. Normally, SQL statements are not written by the developer. Instead, SQL is generated dynamically by the DAL, ensuring that all inserted data is properly escaped.''
- ``malicious file execution``:inxx "Malicious File Execution: Code vulnerable to remote file inclusion (RFI) allows attackers to include hostile code and data, resulting in devastating attacks, such as total server compromise." ''web2py allows only exposed functions to be executed, preventing malicious file execution. Imported functions are never exposed; only actions are exposed. web2py uses a Web-based administration interface which makes it very easy to keep track of what is exposed and what is not.''
- ``insecure object reference``:inxx "Insecure Direct Object Reference: A direct object reference occurs when a developer exposes a reference to an internal implementation object, such as a file, directory, database record, or key, as a URL or form parameter. Attackers can manipulate those references to access other objects without authorization." ''web2py does not expose any internal objects; moreover, web2py validates all URLs, thus preventing directory traversal attacks. web2py also provides a simple mechanism to create forms that automatically validate all input values.''
- ``CSRF``:inxx "Cross Site Request Forgery (CSRF): A CSRF attack forces a logged-on victim's browser to send a pre-authenticated request to a vulnerable web application, which then forces the victim's browser to perform a hostile action to the benefit of the attacker. CSRF can be as powerful as the web application that it attacks." ''web2py prevents CSRF as well as accidental double submission of forms by assigning a one-time random token to each form. Moreover web2py uses UUID for session cookie.''
- ``information leakage``:inxx ``improper error handling``:inxx "Information Leakage and Improper Error Handling: Applications can unintentionally leak information about their configuration, internal workings, or violate privacy through a variety of application problems. Attackers use this weakness to steal sensitive data, or conduct more serious attacks." ''web2py includes a ticketing system. No error can result in code being exposed to the users. All errors are logged and a ticket is issued to the user that allows error tracking. But errors and source code are accessible only to the administrator.''
- "Broken Authentication and Session Management: Account credentials and session tokens are often not properly protected. Attackers compromise passwords, keys, or authentication tokens to assume other users' identities." ''web2py provides a built-in mechanism for administrator authentication, and it manages sessions independently for each application. The administrative interface also forces the use of secure session cookies when the client is not "localhost". For applications, it includes a powerful Role Based Access Control API.''
- ``cryptographic store``:inxx "Insecure Cryptographic Storage: Web applications rarely use cryptographic functions properly to protect data and credentials. Attackers use weakly protected data to conduct identity theft and other crimes, such as credit card fraud." ''web2py uses the MD5 or the HMAC+SHA-512 hash algorithms to protect stored passwords. Other algorithms are also available.''
- ``secure communications``:inxx "Insecure Communications: Applications frequently fail to encrypt network traffic when it is necessary to protect sensitive communications." ''web2py includes the SSL-enabled``ssl``:cite Rocket WSGI server, but it can also use Apache or Lighttpd and mod_ssl to provide SSL encryption of communications.''
- ``access restriction``:inxx "Failure to Restrict URL Access: Frequently an application only protects sensitive functionality by preventing the display of links or URLs to unauthorized users. Attackers can use this weakness to access and perform unauthorized operations by accessing those URLs directly." ''web2py maps URL requests to Python modules and functions. web2py provides a mechanism for declaring which functions are public and which require authentication and authorization. The included Role Based Access Control API allow developers to restrict access to any function based on login, group membership or group based permissions. The permissions are very granular and can be combined with CRUD to allow, for example, to give access to specific tables and/or records. web2py also allows digitally signed URL and provides API to digitally sign ajax callbacks.''
web2py was reviewed for security and you can find the result of the review in ref.``pythonsecurity``:cite.
### In the box
You can download web2py from the official web site:
``
http://www.web2py.com
``:code
web2py is composed of the following components:
- **libraries**: provide core functionality of web2py and are accessible programmatically.
- **web server**: the Rocket WSGI web server.
- the **admin** application: used to create, design, and manage other web2py applications. **admin** provide a complete web-based Integrated Development Environment (IDE) for building web2py applications. It also includes other functionality, such as web-based testing and a web-based shell.
- the **examples** application: contains documentation and interactive examples. **examples** is a clone of the official web2py.com web site, and includes epydoc documentation.
- the **welcome** application: the basic scaffolding template for any other application. By default it includes a pure CSS cascading menu and user authentication (discussed in Chapter 9).
web2py is distributed in source code, and in binary form for Microsoft Windows and for Mac OS X.
I am sure I forgot somebody, so I apologize.
I particularly thank Anthony, Jonathan, Mariano, Bruno, Vladyslav, Martin, Nathan, Simone, Thadeus, Tim, Iceberg, Denes, Hans, Christian, Fran and Patrick for their major contributions to web2py and Anthony, Alvaro, Bruno, Denes, Felipe, Graham, Jonathan, Hans, Kyle, Mark, Michele, Richard, Robin, Roman, Scott, Shane, Sharriff, Sriram, Sterling, Stuart, Thadeus (and others) for proofreading various versions of this book. Their contribution was invaluable. If you find any errors in this book, they are exclusively my fault, probably introduced by a last-minute edit. I also thank Ryan Steffen of Wiley Custom Learning Solutions for help with publishing the first edition of this book.
web2py contains code from the following authors, whom I would like to thank:
Guido van Rossum for Python``python``:cite, Peter Hunt, Richard Gordon, Timothy Farrell for the Rocket``rocket``:cite web server, Christopher Dolivet for EditArea``editarea``:cite, Bob Ippolito for simplejson``simplejson``:cite, Simon Cusack and Grant Edwards for pyRTF``pyrtf``:cite, Dalke Scientific Software for pyRSS2Gen``pyrss2gen``:cite, Mark Pilgrim for feedparser``feedparser``:cite, Trent Mick for markdown2``markdown2``:cite, Allan Saddi for fcgi.py, Evan Martin for the Python memcache module``memcache``:cite, John Resig for jQuery``jquery``:cite.
The cover of this book was designed by Peter Kirchner at Young Designers.
I thank Helmut Epp (provost of DePaul University), David Miller (Dean of the College of Computing and Digital Media of DePaul University), and Estia Eichten (Member of MetaCryption LLC), for their continuous trust and support.
Finally, I wish to thank my wife, Claudia, and my son, Marco, for putting up with me during the many hours I have spent developing web2py, exchanging emails with users and collaborators, and writing this book. This book is dedicated to them.
### About this book
This book includes the following chapters, besides this introduction:
- Chapter 2 is a minimalist introduction to Python. It assumes knowledge of both procedural and object-oriented programming concepts such as loops, conditions, function calls and classes, and covers basic Python syntax. It also covers examples of Python modules that are used throughout the book. If you already know Python, you may skip Chapter 2.
- Chapter 3 shows how to start web2py, discusses the administrative interface, and guides the reader through various examples of increasing complexity: an application that returns a string, a counter application, an image blog, and a full blown wiki application that allows image uploads and comments, provides authentication, authorization, web services and an RSS feed. While reading this chapter, you may need to refer to Chapter 2 for general Python syntax and to the following chapters for a more detailed reference about the functions that are used.
- Chapter 4 covers more systematically the core structure and libraries: URL mapping, request, response, sessions, caching, cron, internationalization and general workflow.
- Chapter 5 is a reference for the template language used to build views. It shows how to embed Python code into HTML, and demonstrates the use of helpers (objects that can generate HTML).
- Chapter 6 covers the Database Abstraction Layer, or DAL. The syntax of the DAL is presented through a series of examples.
- Chapter 7 covers forms, form validation and form processing. FORM is the low level helper for form building. SQLFORM is the high level form builder. In Chapter 7 we also discuss the Create/Read/Update/Delete (CRUD) API.
- Chapter 8 covers communication with as sending emails and SMSes.
- Chapter 9 covers authentication, authorization and the extensible Role-Based Access Control mechanism available in web2py. Mail configuration and CAPTCHA are also discussed here, since they are used for authentication. In the third edition of the book we have added extensive coverage of integration with third-party authentication mechanisms such as OpenID, OAuth, Google, Facebook, LinkedIn, etc.
- Chapter 10 is about creating web services in web2py. We provide examples of integration with the Google Web Toolkit via Pyjamas, and with Adobe Flash via PyAMF.
- Chapter 11 is about web2py and jQuery recipes. web2py is designed mainly for server-side programming, but it includes jQuery, since we have found it to be the best open-source JavaScript library available for effects and Ajax. In this chapter, we discuss how to effectively use jQuery with web2py.
- Chapter 12 discusses web2py components and plugins as a way to build modular applications. We provide an example of a plugin that implements many commonly used functionality, such as charting, comments, tagging, and wiki.
- Chapter 13 is about production deployment of web2py applications. We mainly address three possible production scenarios: on a Linux web server or a set of servers (which we consider the main deployment alternative), running as a service on a Microsoft Windows environment, and deployment on the Google Applications Engine. In this chapter, we also discuss security and scalability issues.
- Chapter 14 contains a variety of other recipes to solve specific tasks, including upgrades, geocoding, pagination, the Twitter API, and more.
web2py is one of many web application frameworks, but it has compelling and unique features.
web2py was originally developed as a teaching tool, with the following primary motivations:
- Easy for users to learn server-side web development without compromising functionality. For this reason, web2py requires no installation and no configuration, has no dependencies (except for the source code distribution, which requires Python 2.5 and its standard library modules), and exposes most of its functionality via a Web browser interface.
- web2py has been stable from day one because it follows a top-down design; i.e., its API was designed before it was implemented. Even as new functionality has been added, web2py has never broken backwards compatibility, and it will not break compatibility when additional functionality is added in the future.
- web2py proactively addresses the most important security issues which plague many modern web applications, as determined by OWASP``owasp``:cite below.
- web2py is lightweight. Its core libraries, including the Database Abstraction Layer, the template language, and all the helpers amount to 1.4MB. The entire source code including sample applications and images amounts to 10.4MB.
- web2py has a small footprint and is very fast. It uses the Rocket``rocket``:cite WSGI web server developed by Timothy Farrell. It is as fast as Apache with mod_wsgi, supports ssl and ipv6.
- web2py uses Python syntax for models, controllers, and views, but does not import models and controllers (as all the other Python frameworks do) - instead it executes them. This means that apps can be installed, uninstalled, and modified without having to restart the web server (even in production), and different apps can coexist without their modules interfering with one another.
- web2py uses a Database Abstraction Layer (DAL) instead of an Object Relational Mapper (ORM). From a conceptual point of view, this means that different database tables are mapped into different instances of one ``Table`` class and not into different classes, while records are mapped into instances of one ``Row`` class, not into instances of the corresponding table class. From a practical point of view, it means that SQL syntax maps almost one-to-one into DAL syntax, and there is no complex metaclass programming going on under the hood as in popular ORMs, which would add latency.
web2py is one of many web application frameworks, but it has compelling and unique features.
web2py was originally developed as a teaching tool, with the following primary motivations:
- Easy for users to learn server-side web development without compromising functionality. For this reason, web2py requires no installation and no configuration, has no dependencies (except for the source code distribution, which requires Python 2.5 and its standard library modules), and exposes most of its functionality via a Web browser interface.
- web2py has been stable from day one because it follows a top-down design; i.e., its API was designed before it was implemented. Even as new functionality has been added, web2py has never broken backwards compatibility, and it will not break compatibility when additional functionality is added in the future.
- web2py proactively addresses the most important security issues which plague many modern web applications, as determined by OWASP``owasp``:cite below.
- web2py is lightweight. Its core libraries, including the Database Abstraction Layer, the template language, and all the helpers amount to 1.4MB. The entire source code including sample applications and images amounts to 10.4MB.
- web2py has a small footprint and is very fast. It uses the Rocket``rocket``:cite WSGI web server developed By Timothy Farrell. It is as fast as Apache with mod_wsgi. Our tests also indicate that, on an average PC, it serves an average dynamic page without database access in about 10ms. The DAL has very low overhead, typically less than 3%.
- web2py uses Python syntax for models, controllers, and views, but does not import models and controllers (as all the other Python frameworks do) - instead it executes them. This means that apps can be installed, uninstalled, and modified without having to restart the web server (even in production), and different apps can coexist without their modules interfering with one another.
- web2py uses a Database Abstraction Layer (DAL) instead of an Object Relational Mapper (ORM). From a conceptual point of view, this means that different database tables are mapped into different instances of one ``Table`` class and not into different classes, while records are mapped into instances of one ``Row`` class, not into instances of the corresponding table class. From a practical point of view, it means that SQL syntax maps almost one-to-one into DAL syntax, and there is no complex metaclass programming going on under the hood as in popular ORMs, which would add latency.
+You can find additional topics discussed on the usergroup``usergroup``:cite. There is also AlterEgo``alterego``:cite, the old web2py blog and FAQ.
+``MARKMIN``:inxx
+This book has been written using the markmin syntax and automatically converted to HTML, LaTeX and PDF.
-You can find additional topics discussed on AlterEgo``alterego``:cite, the interactive web2py FAQ.
-
-This book has been written using the markmin syntax ``MARKMIN``:inxx and automatically converted to HTML, LaTeX and PDF.
WSGI ``wsgi-w``:cite ``wsgi-o``:cite (Web Server Gateway Interface) is an emerging Python standard for communication between a web server and Python applications).
WSGI ``wsgi:w,wsgi:o``:cite (Web Server Gateway Interface) is an emerging Python standard for communication between a web server and Python applications).
web2py includes a Database Abstraction Layer (DAL) that writes SQL``sql-w``:cite dynamically so that you, the developer, don't have to. The DAL knows how to generate SQL transparently for
SQLite``sqlite``:cite, MySQL``mysql``:cite, PostgreSQL``postgres``:cite, MSSQL``mssql``:cite,
FireBird``firebird``:cite, Oracle``oracle``:cite, IBM DB2``db2``:cite, Informix``informix``:cite, and
Ingres``ingresdb``:cite.
The DAL can also generate function calls for the Google Datastore
when running on the Google App Engine (GAE)``gae``:cite.
Experimentally we support more databases. Please check on the web2py web site and mailing list for more recent adapters.
Once one or more database tables are defined, web2py also generates a fully functional web-based database
administration interface to access the database and the tables.
web2py includes a Database Abstraction Layer (DAL) that writes SQL``sql:w``:cite dynamically so that you, the developer, don't have to. The DAL knows how to generate SQL transparently for
SQLite``sqlite``:cite, MySQL``mysql``:cite, PostgreSQL``postgres``:cite, MSSQL``mssql``:cite,
FireBird``firebird``:cite, Oracle``oracle``:cite, IBM DB2``db2``:cite, Informix``informix``:cite, and
Ingres``ingresdb``:cite.
The DAL can also generate function calls for the Google Datastore
when running on the Google App Engine (GAE)``gae``:cite.
Experimentally we support more databases. Please check on the web2py web site and mailing list for more recent adapters.
Once one or more database tables are defined, web2py also generates a fully functional web-based database
administration interface to access the database and the tables.
The two classic approaches for developing web applications are:
- Generating HTML``html-w``:cite ``html-o``:cite programmatically.
- Embedding code into HTML pages.
The two classic approaches for developing web applications are:
- Generating HTML``html:w,html:o``:cite programmatically.
- Embedding code into HTML pages.
+Vladyslav Kozlovskyy,
Zahariash.
I am sure I forgot somebody, so I apologize.
I particularly thank Anthony, Jonathan, Mariano, Bruno, Vladyslav, Martin, Nathan, Simone, Thadeus, Tim, Iceberg, Denes, Hans, Christian, Fran and Patrick for their major contributions to web2py and Anthony, Alvaro, Bruno, Denes, Felipe, Graham, Jonathan, Hans, Kyle, Mark, Michele, Richard, Robin, Roman, Scott, Shane, Sharriff, Sriram, Sterling, Stuart, Thadeus (and others) for proofreading various versions of this book. Their contribution was invaluable. If you find any errors in this book, they are exclusively my fault, probably introduced by a last-minute edit. I also thank Ryan Steffen of Wiley Custom Learning Solutions for help with publishing the first edition of this book.
Zahariash.
I am sure I forgot somebody, so I apologize.
I particularly thank Jonathan, Mariano, Bruno, Martin, Nathan, Simone, Thadeus, Tim, Iceberg, Denes, Hans, Christian, Fran and Patrick for their major contributions to web2py and Anthony, Alvaro, Bruno, Denes, Felipe, Graham, Jonathan, Hans, Kyle, Mark, Michele, Richard, Robin, Roman, Scott, Shane, Sharriff, Sriram, Sterling, Stuart, Thadeus (and others) for proofreading various versions of this book. Their contribution was invaluable. If you find any errors in this book, they are exclusively my fault, probably introduced by a last-minute edit. I also thank Ryan Steffen of Wiley Custom Learning Solutions for help with publishing the first edition of this book.
Alexey Nezhdanov,
Alvaro Justen,
Andrew Willimott,
Angelo Compagnucci,
Anthony Bastardi,
Antonio Ramos,
Arun K. Rajeevan,
Attila Csipa,
+Ben Reinhart,
Alexey Nezhdanov,
Alvaro Justen,
Andrew Willimott,
Angelo Compagnucci,
Anthony Bastardi,
Antonio Ramos,
Arun K. Rajeevan,
Attila Csipa,
web2py is one of many web application frameworks, but it has compelling and unique features.
web2py was originally developed as a teaching tool, with the following primary motivations:
- Easy for users to learn server-side web development without compromising functionality. For this reason, web2py requires no installation and no configuration, has no dependencies (except for the source code distribution, which requires Python 2.5 and its standard library modules), and exposes most of its functionality via a Web browser interface.
- web2py has been stable from day one because it follows a top-down design; i.e., its API was designed before it was implemented. Even as new functionality has been added, web2py has never broken backwards compatibility, and it will not break compatibility when additional functionality is added in the future.
- web2py proactively addresses the most important security issues which plague many modern web applications, as determined by OWASP``owasp``:cite below.
- web2py is lightweight. Its core libraries, including the Database Abstraction Layer, the template language, and all the helpers amount to 1.4MB. The entire source code including sample applications and images amounts to 10.4MB.
- web2py has a small footprint and is very fast. It uses the Rocket``rocket``:cite WSGI web server developed By Timothy Farrell. It is as fast as Apache with mod_wsgi. Our tests also indicate that, on an average PC, it serves an average dynamic page without database access in about 10ms. The DAL has very low overhead, typically less than 3%.
- web2py uses Python syntax for models, controllers, and views, but does not import models and controllers (as all the other Python frameworks do) - instead it executes them. This means that apps can be installed, uninstalled, and modified without having to restart the web server (even in production), and different apps can coexist without their modules interfering with one another.
- web2py uses a Database Abstraction Layer (DAL) instead of an Object Relational Mapper (ORM). From a conceptual point of view, this means that different database tables are mapped into different instances of one ``Table`` class and not into different classes, while records are mapped into instances of one ``Row`` class, not into instances of the corresponding table class. From a practical point of view, it means that SQL syntax maps almost one-to-one into DAL syntax, and there is no complex metaclass programming going on under the hood as in popular ORMs, which would add latency.
web2py is one of many web application frameworks, but it has compelling and unique features.
web2py was originally developed as a teaching tool, with the following primary motivations:
- Easy for users to learn server-side web development without compromising functionality. For this reason, web2py requires no installation and no configuration, has no dependencies (except for the source code distribution, which requires Python 2.5 and its standard library modules), and exposes most of its functionality via a Web browser interface.
- web2py has been stable from day one because it follows a top-down design; i.e., its API was designed before it was implemented. Even as new functionality has been added, web2py has never broken backwards compatibility, and it will not break compatibility when additional functionality is added in the future.
- web2py proactively addresses the most important security issues which plague many modern web applications, as determined by OWASP``owasp``:cite below.
- web2py is lightweight. Its core libraries, including the Database Abstraction Layer, the template language, and all the helpers amount to 1.4MB. The entire source code including sample applications and images amounts to 10.4MB.
- web2py has a small footprint and is very fast. It uses the Rocket``rocket``:cite WSGI web server developed By Timothy Farrell. It is as fast as Apache with mod_wsgi. Our tests also indicate that, on an average PC, it serves an average dynamic page without database access in about 10ms. The DAL has very low overhead, typically less than 3%.
- web2py uses Python syntax for models, controllers, and views, but does not import models and controllers (as all the other Python frameworks do) - instead it executes them. This means that apps can be installed, uninstalled, and modified without having to restart the web server (even in production), and different apps can cohexist without their modules interfering with one another.
- web2py uses a Database Abstraction Layer (DAL) instead of an Object Relational Mapper (ORM). From a conceptual point of view, this means that different database tables are mapped into different instances of one ``Table`` class and not into different classes, while records are mapped into instances of one ``Row`` class, not into instances of the corresponding table class. From a practical point of view, it means that SQL syntax maps almost one-to-one into DAL syntax, and there is no complex metaclass programming going on under the hood as in popular ORMs, which would add latency.