20130704 (Thursday, 04 July 2013)¶
About Content Security Policy¶
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
are indeed necessary, and they needed a
bugfix for when
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
requirements with both user_groups and user_level¶
Melanie cannot see.
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”.
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
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.