Host your own doodles with jawanndenn

Thursday, March 14. 2019

For a website where event dates are offered to a group of users who need to find those dates that most users can attend, doodles are a good solution. There are well known providers for that sort of thing like, or, with the latter two offering better privacy for european users (no transfer of data to servers in the USA).

Still, hosting your very own service is an attractive alternative. For this there is  which can be downloaded from It is a web application written in python by Sebastian Pipping, libre software.

Installation is easy with

pip install jawanndenn

and then run it from the command line with something like

jawanndenn --host your-domain.tld --port 23456  (the port is arbitrary).
navigate your browser to
https://your-domain.tld:23456 and create your first own poll.

You see the log entries written out on the console. This is nice for testing but to actually use jawanndenn you'll need something more stable than a manually started programm.

As my web server runs with apache this is how I did it:

- set up a subdomain dedicated for the application, like doodle.your-domain.tld

- get certificates for it from Let's Encrypt (i.e. using )

- create a folder for document root of the new subdomain and put a file app.wsgi and a favicon.ico there, the former you'll find at , the latter can be done with touch as we won't see that icon anyways but it saves 404 log entries to have a file named like it.

- make sure that apache2 has mod_wsgi enabled

- set up a virtual host for it in apache2/sites-available. Example:

#  doodle.your-domain.tld

# subdomain dedicated for running the jawanndenn web application
# don't separate .conf and .common since this will lead to errors when both :80 and :443 try to set
# a WSGIDaemonProcess with the same name.
# Don't include processes=1 into the WSGIDaemonProcess definition for this will lead to errors "Single process needed"

<VirtualHost :80>
#       include sites-available/doodle.
your-domain.tld.common ## this won't do, see above
        ServerName doodle.

        WSGIDaemonProcess doodle user=web123 group=web123 threads=5
        WSGIScriptAlias / /var/www/web123/doodle/app.wsgi

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

   CustomLog /var/log/apache2/doodle.
your-domain.tld.access.log combined
   ErrorLog  /var/log/apache2/doodle.your-domain.tld.error.log



ServerName doodle.your-domain.tld

    # supply a different name for the WSGIDaemonProcess on :443
    WSGIDaemonProcess doodler user=web123 group=web123 threads=5
    WSGIScriptAlias / /var/www/web123/doodle/app.wsgi

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

   CustomLog /var/log/apache2/doodle.your-domain.tld.access.log combined
   ErrorLog  /var/log/apache2/doodle.your-domain.tld.error.log

        SSLEngine on

        SSLCertificateFile      /etc/dehydrated/certs/
        SSLCertificateKeyFile   /etc/dehydrated/certs/
        SSLCertificateChainFile /etc/dehydrated/certs/


Now restart apache2, weed out typos and your done. You create new doodles from doodle.your-domain.tld,
make note of the handle of the new poll and embed it on a web site with an iframe like

<div class="dudel">
<iframe src="https://doodle.your-domain.tld/poll/a9108dcfa12006ce3c229d6f0110c5f976df14e963ddd9b7ffc8618013a0bd7e"
        width="100%" height="600" frameborder="0"
        allowfullscreen >
  <p> <a href="">
    Fallback link for browsers that don't support iframes
  </a> </p>


I had no luck trying to use sandbox with the iframe, YMMV


Now, is that secure?

Do a little exploration with the 'View Web Source' feature of your browser to see all the relevant URIs and handles visible in plain text. Who ever gets to that page with the doodles can do shyte like

  • create 'unofficial' doddle polls
  • post spam as the name of a doodle
  • what the heck

Thus, we do have the security feature of 'data never leave my own site'. Which is cool.
All the rest of your desired security you will have to provide on your own.

Now, can I edit a vote? As it comes jawanndenn does not support any editing of votes which is regarded a security feature but makes doodles pretty useless in real life cause people do change opinion all the time. You cannot manually edit the stored votes cause they are stored in a binary format that's hard to access.

What you can do is add that functionality by yoursel like modify the vote() method of the _Poll object to replace the prior vote with the new vote if the name is exactly the same. 


die eigene Certificate Authority mit XCA

Saturday, February 18. 2012

 Für eine Gruppe Rechnern in einem Intranet sollen für https Zertifikate erstellt werden. Alle Systeme sind unter mehr als einer Domain erreichbar, die Zertifikate sollen jeweils für alle Namen gültig sein. 'Echte', also von einer in den Browsern vorinstallierten CA signierte Zertifikate scheiden aus Kostengründen aus, Um nicht für jeden einzelnen Rechner eine Ausnahme in den Browsern speichern zu müssen setze ich eine eigen CA auf und signiere die einzelnen Zertifikate mit diesem CA-Zertifikat. Es reicht dann, dieses eine Zertifikat in den browsern zu importieren und alle damit signierten Zertifikate werden grün.

Man kann das natuerlich 'händisch' mit openssl allein machen, aber die Verwaltung wird leicht unübersichtlich. Ich habe XCA genommen, ein 'x509 Certification Authority management tool based on QT4', dass ich auf debian squeeze / KDE mit apt-get install xca installierte.

XCA hat Reiter für Schlüssel, Unterschriftsanfragen, Zertifikate, Rücknahmelisten und Vorlagen. Diese Vorlagen sind XCA-spezifisch, man kann sie neu erstellen aber auch bestehende Zertifikate oder Unterschriftsanfrage in eine Vorlage exportieren. Das ist in der Praxis eine ziemliche Hilfe und erspart Abtippen, für eine neues Request wählt man dann einfach im Reiter Herkunft unten das passende Template und traegt dessen Werte mit Übernehmen ein, anschliessend ändert man nur das, was wirklich neu muss.

Bei der Erstellung des CA-Zertifikates muss man darauf achten, im Reiter Erweiterungen in den Grundbeschränkungen als Typ Zertifikats Authorität einzustellen, Kritisch markieren, im Reiter Key Usage müssen links Certificate Sign und CRL Sign markiert sein, im Reiter Netscape markiert man SSL CA, S/MIME CA und Object Signing CA.

Bei den Zertifikaten für mehr als einen Domainnamen ist das entscheidende Feld im Reiter Erweiterungen die Zeile subject alternative name, hier auf Bearbeiten klicken und in dem Formular links oben DNS und rechts daneben den ersten Namen, mit Hinzufügen eintragen. Das wiederholt man nun der Reihe nach für jeden Namen, für den das Zertifikat gelten soll, auch für den schon auf dem vorigen reiter eingetragenen common name. Es ist wohl so, dass, wenn das Feld subject alternative name im Zertifikat gesetzt ist, nur die dort eingetragenen Werte gelten. Bei Key Usage muss man noch darauf achten, dass im rechten Feld auch TLS Web Server Authentication markiert ist, sonst bekommt man (in FireFox, der da auskunftsfreudiger ist als etwa Chrome) den Fehler SEC_ERROR_INADEQUATE_CERT_TYPE."The rule is that IF a server cert contains an extended Key Usage extension, then it MUST include the extended usage for server authentication."

bekommt man den Fehler sec_error_unknown_issuer zu sehen, muss man an die erzeugten Zertifikate das Zertifikat der signierenden CA anhängen, für server, die alles in einer datei wollen (so Courier) etwa per 

cat domain.tld.{key,crt} my-own-CA.crt >domain.tld.pem

 Bei Webmin zb geht beides, man kann eine wie oben erzeugte combo als keyfile in /etc/webmin/miniserv.conf eintragen, oder dort nur den key selbst und die Zertifikate als certfile= und extracas=

(Page 1 of 1, totaling 2 entries)