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.
Updated DavLink signature¶
More updates in documentation for DavLink: https://www.lino-framework.org/davlink/index.html, https://www.lino-framework.org/davlink/usage.html and https://www.lino-framework.org/davlink/client.html.
Re-built a new self-signed DavLink.jar file included with Lino because the old one had expired.
TODO: automate the signature update and run it with every release.
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 .
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.