20130704 (Thursday, 04 July 2013)

About Content Security Policy

I read the article Bodyguard für Webseiten. which explains Content Security Policy for people like me. It also mentions the XSS Filter Evasion Cheat Sheet.

I then asked Google to find django-csp a model-less Django “app” which adds Content-Security-Policy headers to Django applications. It works using a middleware and some decorators. Especially the configuration is well done. It starts by stating: “Content-Security-Policy is a complicated header. There are many values you may need to tweak here.”

CSP is important for applications that accept arbitrary input from anonymous users.

Uncaught TypeError: Cannot read property ‘main_item’ of null

Dieser JS-Fehler kam manchmal, wenn man als jemand anderer gearbeitet hatte und dann zurück als “ich selbst” schalten wollte. Wenn Permalink nicht ermittelbar weil Lino.current_window nicht definiert ist, dann soll er ja trotzdem wenigstens umschalten und dann eben auf die Startseite springen.

Small changes to welfare, patrols and faggio

I checked in some small changes to welfare, patrols and faggio.

Updated demo sites on lino-framework.org

Updated the demo sites on lino-framework.org.

This made me discover a bug: the get_auth_middleware and authenticate in lino.utils.auth functions are indeed necessary, and they needed a bugfix for when auth_middleware.

TODO:

  • Add a test case that would have detected this bug. This view is being used only when not remote http auth.
  • Check with Joe whether there is a better solution for his problem than auth_middleware.

requirements with both user_groups and user_level

  • Melanie cannot see Configuration ‣ DSBE ‣ Fonctions.

This innocent user-reported Lino-Welfare problem revealed some subtle issues which caused me a few hours of internal work.

BTW this wasn’t being tested. Added a test case for profile 110: integ manager.

Requirements having both user_groups and user_level didn’t work as expected.

When user_groups is not specified, then the profile’s default level (UserProfile.level) is being tested, but otherwise Lino now tests only the userlevel of the group membership.

E.g. dd.required(user_level=’manager’,user_groups=’integ’) will pass when profile.integ_level is “manager” even when profile.level is only “user”.

The lino_welfare test suite had a failure which occured only when running certain combinations of cases within a same runner. The following two commands worked:

python manage.py test lino_welfare.DemoTest
python manage.py test lino_welfare.QuickTests

But running them together fails:

python manage.py test lino_welfare.QuickTests lino_welfare.DemoTest

This was complex. For example I didn’t yet know that Django creates the test database and loads any test fixtures before calling the setUp() method.

Added a new method lino.core.actors.Actor.clear_handle and manually call it in the database_ready handler which configures the dynamic columns of UsersWithClients:

When an actor has dynamic columns which depend on database content, then its layout handle must not persist between different Django test cases because a handle from a first test case may refer to elements which no longer exist in a second test case.

While trying to understand these reasons, I started a new document Signals overview.