OneGov GEVER Dossier Template Utility

OneGov GEVER verfügt über ein sehr mächtiges RESTful API, welches automatisierte Zugriffe auf Inhaltstypen wie Ordnungspositionen, Dossiers oder Dokumente erlaubt. Somit können einfach grosse Serien gleichartiger Dossiers mit minimalen Benutzerinteraktionen erstellt werden.
Das ist im Hinblick von realitätsnahen Simulationen von eCH-0160 Ablieferungen interessant, da vielfach zuwenig Dossiers vorhanden sind, die den strengen Aussonderungsvorgaben genügen.

Das OneGov GEVER Dossier Template Utility (ODTU) ermöglicht es, von einem beliebigen Client aus, ein Template zu erstellen und daraus Serien von Dossiers in einem OneGov GEVER Host zu produzieren.

Es handelt sich um eine eigenständige, JAVA basierte Konsolen-Anwendung die lediglich eine HTTPS Verbindung zu einem OneGov GEVER Host benötigt. ODTU läuft unter der Apache License V2.0 und kann somit frei genutzt und weiterentwickelt werden.

Download
ODTU steht entweder als Source oder in kompilierter Form zur Verfügung:

Wie wird das Programm aufgerufen?
Die Anwendung wird aus einer Shell heraus mit folgendem Befehl aufgerufen:

$ java -jar odtu-1.0.3.jar

Sollen Debug Informationen ausgegeben resp. in die Log Datei geschrieben werden, muss die Anwendung mit der Option -v resp. –verbose aufgerufen werden:

$ java -jar odtu-1.0.3.jar --verbose

In beiden Fällen werden die Rückmeldungen in die Datei odtu.log in das jeweilige Benutzerverzeichnis geschrieben.

Dossier Erstellungsprozess
Die Dossiers werden durch den folgenden, lokalen Prozess erstellt – und je nach gewähltem Status auch abgeschlossen – und anschliessend via RESTful API nach OneGov GEVER geschrieben:

Prozess-Schritte
Der Dossier Erstellungsprozess besteht aus 7 resp. 8 Schritten, die streng sequentiell durchlaufen werden. Die Konsoleneingaben werden jeweils validiert und solange abgefragt, bis sie syntaktisch und semantisch korrekt sind.

Schritt 1/8
Die Verbindungsangaben (url, resource, username und password) zum OneGov GEVER Host werden abgefragt und geprüft.

[1/8] Collecting connection values
Enter URL to a valid OneGov GEVER client...
Enter username (OneGov GEVER)...
Enter password (OneGov GEVER)...
[OK] connection could be established
[OK] Target container @type...
[OK] Target container allows dossier(s)...
[OK] The target container allready contains...

Kann ODTU erfolgreich eine Verbindung zu einem validen Zielcontainer (Ordnungsposition) aufbauen, wird der nächste Prozessschritt durchlaufen.

Schritt 2/8
Nun werden Angaben zur Session (Serie) abgefragt: Zuerst den Sessionnamen, wobei ODTU einen Zeitstempel in Millisekunden anbietet. Der Sessionname wird später als Präfix zum Dossiertitel verwendet. Anschliessend wird die Anzahl der zu erstellenden Dossiers erfragt. Erwartet wird ein ganzzahliger Wert zwischen 1 und 500:

[2/8] Collecting session values
Enter session name [Session 201711923248]...
Enter number of dossiers beeing created...
[OK] 1 is a valid number whithin the range...

Sind die Eingaben valide, wird der nächste Prozessschritt durchlaufen.

Schritt 3/8
Hier werden die pflichtigen Metadaten eines Dossier abfragt. Dazu gehören der Dossiertitel, die Beschreibung, das Erstellungsdatum und das Abschlussdatum sowie der Dossierstatus. Als Verantwortlicher wird der Login Name verwendet.

[3/8] Collecting dossier values
Enter dossier title (template)...
Enter description (template)...
Enter dossier start date (template)...
Enter dossier end date (template)...
Enter dossier state (open/closed)...

Sollen die Dossier(s) geschlossen werden, besteht der Prozess aus acht, ansonsten nur aus sieben Schritten.

Sind die Angaben korrekt, wird der vierte Schritt durchlaufen.

Schritt 4/8
Anschliessend wird das Verzeichnis festgelegt, in dem ODTU die Dateien, die in die Dossiers geschrieben werden sollen, abholt. Ist das Verzeichnis leer, so bleiben auch die erstellten Dossier leer. Befinden sich dagegen in dem angegebenen Verzeichnis Dateien, so werden diese anhand einer White List geprüft. ODTU berücksichtigt gegenwärtig MS Office, OpenOffice und PDF Dateien (Genau: .pdf,.doc,.docx,.xls,.xlsx,.ppt,.pptx,.odt,.ods,.odp). Befinden sich in dem Verzeichnis Dateien anderer Typen, so bleiben sie nachträglich unberücksichtigt.

[4/8] Reading files to copy into the dossiers
Enter input directory [/home/USER]: 
[OK] '/home/USER' is absolute
[OK] '/home/USER' is valid
[OK] '/home/USER' is a valid directory
[OK] '/home/USER' is accessible

Found (7) files of one of the following types...
/home/USER/Simple OO Calc File.ods
/home/USER/Simple OO Writer File.odt
/home/USER/Simple MS Word File.docx
/home/USER/Simple OO Impress File.odp
/home/USER/Simple OO Writer File (Kopie).odt
/home/USER/Simple PDF File.pdf
/home/USER/Simple MS Excel File.xlsx

An dieser Stelle sollte besondere Vorsicht geboten sein, denn die identifizierten Dateien werden in jedes neu zu erstellende Dossier geschrieben.

Nach diesem Schritt sind alle Informationen, die für die Dossiererstellung werden, spezifiert.

Schritt 5/8
Schliesslich werden die zu verwendenden Angaben noch einmal aufgeführt:

[5/8] Dossier template summary
1 dossier(s) will be assembled and written...
The following template will be used...
***
Title:      Session 201711923248: Dossier Title
Decription: Description
Start:      2005-01-01
End:        2005-12-31
State:      closed
***
The 7 files from /home/USER will be written...
KEEP IN MIND: THE ASSEMBLING PROCESS CANT BE...
Do you really want to proceed? If so type yes...

Der Prozess wird nur dann fortgesetzt, wenn explizit ‚yes‘ eingegeben wird. Alle anderen Eingaben führen zum Prozessende…

Schritt 6/8
Jetzt werden die spezifizierten Dateien base64 kodiert und zu OneGov GEVER Dokumente aufbereitet, wobei als Dokumentname der Dateiname, als Dokumentdatum das Anfangsdatum des Dossier-Templates verwendet wird. Der entsprechende Mime Typ wird von ODTU zur Laufzeit ermittelt.

[6/8] Building documents
[1/7] Creating document 'Simple OO Calc File'
[2/7] Creating document 'Simple OO Writer File'
[3/7] Creating document 'Simple MS Word File'
[4/7] Creating document 'Simple OO Impress File'
[5/7] Creating document 'Simple OO Writer File...
[6/7] Creating document 'Simple PDF File'
[7/7] Creating document 'Simple MS Excel File'

Die erstellten Dokumente werden im Speicher vorgehalten und nachträglich in jedes neue Dossier hineingeschrieben.

Schritt 7/8
Jetzt folgt die Erstellung und Abspeicherung der Dossiers:

[7/8] Building dossiers
[1/1] Building Dossier 'Session 201711923248...
https://demo.onegovgever.ch/ordnungssystem/...

Sollen die Dossiers offen bleiben, so endet der Prozess hier.

Schritt 8/8 (optional)
Für den Fall, dass die bereits erstellten und nach OneGov GEVER geschriebenen Dossiers geschlossen werden sollen, folgt dieser Schritt zusätzlich:

[8/8] Resolving built dossiers
State of dossier template is set to close...
https://demo.onegovgever.ch/ordnungssystem/...
[1/1] Resolving dossier 'https://demo.onegov...

Ist der Prozess erfolgreich abgelaufen, so gibt ODTU eine Postambel mit einem entsprechenden Vermerk und einem Hinweis auf die Log Datei heraus:

* OneGov GEVER Dossier Template Utility (ODTU)..
1 dossier(s) have been written to 'https://demo...
For further information see '/home/USER/odtu.log'

In OneGov GEVER sind die erstellten Dossiers in gewohnter Art und Weise verfügbar:

GitLab (LAMP) using an external reverse proxy

GitLab is an interesting alternative to the github, particularly if you want to take control over the system providing your repositories. GitLab operates quite well behind nginx. However a sufficient nginx session timeout can be important.

The following article describes a working configuration on two separate servers: GitLab on the backend server with self signed SSL certificates and nginx on the frontend server with a fully qualified servername and externally signed SSL certificates:

This tutorial focuses on the critical configuration steps and skip all the general settings like firewall rules, advanced security settings of nginx an so forth.

Nginx has to shift from pure HTTP to HTTPS. Furthermore it should not run into endless redirections which is a very common problem and for which a lot of reasons can be found.

Install Gitlab
To install GitLab on Debian based Linux system follow the description below. First you need to install some prerequisites:

$ sudo apt-get install curl 
$ sudo apt-get install openssh-server 
$ sudo apt-get install ca-certificates 
$ sudo apt-get install postfix

The postfix installer will ask you the type of installation. Choose Internet Site.

Next you need to add the GitLab repository:

$ sudo curl -sS https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh | bash

Now Gitlab itself is beeing installed

$ sudo apt-get install gitlab

To finish the installation configure GitLab using the following command:

$ sudo gitlab-ctl reconfigure

Now you have a running instance of Gitlab: http://INTERNAL_SERVER_NAME/

There are some configuration steps within the browser. This tuturial skips those steps because there are self-explanatory.

Next Gitlab is prepared to use SSL.

$ sudo apt-get install gitlab

Generate self signed SSL certificates
Let’s continue with the SSL configuration on the backend. Start with the generation of the private RSA key:

$ openssl genrsa -des3 
                 -passout pass:x 
                 -out server.key 1024

Copy the key:

$ cp server.key server.key.out

Remove the passphrase:

$ openssl rsa -passin pass:x 
              -in server.key.out  
              -out server.key

Remove the temporary key:

$ rm server.key.out

Create CSR (Certificate Signing Request):

$ openssl req -new 
              -key server.key 
              -out server.csr

Create the self signed certificate:

$ openssl x509 -req 
               -days 365 
               -in server.csr 
               -signkey server.key 
               -out server.crt

Copy the keys to apache:

$ sudo cp server.crt /etc/ssl/certs/ssl.crt
$ sudo cp server.key /etc/ssl/private/ssl.key

Configure apache
The following commands enable SSL and rewriting support:

$ sudo a2enmod ssl
$ sudo a2enmod rewrite 
$ sudo a2ensite default-ssl
$ sudo service apache2 restart

Be sure that the AllowOverride directive is set correctly in the httpd.config file:

<Directory />
    Options FollowSymLinks
    AllowOverride All
</Directory>

respectively

<Directory /var/www/html>
    # ... other directives...
    AllowOverride All
</Directory></code>

Nginx configuration
Now the frontend called ex.com needs to be configured. To do so, edit or create a nginx configuration file:

$ sudo vi /etc/ngingx/sites-available/nginx.conf

First add security headers:

add_header X-Frame-Options "SAMEORIGIN";
add_header Strict-Transport-Security 
    "max-age=15768000; includeSubDomains";
add_header X-XSS-Protection "1; mode=block";
add_header X-Content-Type-Options "nosniff";
add_header Content-Security-Policy-Report-Only 
    "default-src 'self'; img-src *; 
    style-src 'self' 'unsafe-inline'; 
    script-src 'self' 'unsafe-inline' 
    'unsafe-eval'";

Create a rule, which shifts the HTTP requests to HTTPS:

# Shifts http requests to https
server {
    server_name ex.com www.ex.com;
    return 301 https://ex.com$request_uri;
}

The servername example.com stands for any servername which has a DNS entry and can be resolved.

Finally the https rule is to be defined. To do so you need to have two parameters:

  • Reference to the externally signed SSL certificate and key

Enter the following snipped to nginx.conf as well:

# Processes the https requests
server {
    server_name git.ex.com;
    listen 443 ssl;
    ssl_certificate /etc/nginx/ssl/CERTIFICATE_NAME;
    ssl_certificate_key /etc/nginx/ssl/PRIVATE_KEY;
    ssl_ciphers "ECDHE-RSA-AES256-GCM-SHA384:
                 ECDHE-RSA-AES128-GCM-SHA256:
                 ECDHE-RSA-AES256-SHA384:
                 ECDHE-RSA-AES128-SHA256:
                 ECDHE-RSA-AES256-SHA:
                 ECDHE-RSA-AES128-SHA:
                 ECDHE-RSA-DES-CBC3-SHA:
                 AES256-GCM-SHA384:
                 AES128-GCM-SHA256:
                 AES256-SHA256:
                 AES128-SHA256:
                 AES256-SHA:
                 AES128-SHA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4"; 
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;   
    ssl_prefer_server_ciphers on;   
    ssl_session_cache shared:SSL:10m;   
    ssl_session_timeout 5m;

    access_log  /var/log/nginx/internet_git_access.log;
    error_log   /var/log/nginx/internet_git_error.log;

    location / {
        client_max_body_size 0;
        gzip off;
        proxy_read_timeout      300;     
        proxy_connect_timeout   300;     
        proxy_redirect          off;
        proxy_http_version 1.1;     
        proxy_set_header  Host $http_host;
        proxy_set_header  X-Real-IP $remote_addr;     
        proxy_set_header    X-Forwarded-Ssl     on;     
        proxy_set_header    X-Forwarded-For     $proxy_add_x_forwarded_for;     
        proxy_set_header    X-Forwarded-Proto   $scheme;
        proxy_pass https://INTERNAL_SERVER_NAME;
    }

}

Save nginx.conf and change to the following directory:

$ cd /etc/nginx/sites-enabled

Create the following soft link

$ sudo su -
$ ln -s /etc/ngingx/sites-available/nginx.conf

To terminate the nginx configuration just restart it:

$ sudo service nginx restart

Finishing the installation
Open a browser and enter the URL http://example.com resp. https://example.com.
Again I hope that this article was useful. Feel free to leave a comment!

WordPress (LAMP) using an external reverse proxy (nginx)

WordPress is a very popular and easy to use CMS. But if you want to use nginx as an external reverse proxy with SSL support, the configuration becomes a little more complicated.

The following example describes a working configuration running on two separate servers: WordPress on the backend server with self signed SSL certificates and nginx on the frontend server with a fully qualified servername and externally signed SSL certificates:

This tutorial focuses on the critical configuration steps and skip all the general settings like firewall rules, advanced security settings of nginx an so forth.

Nginx has to shift from pure HTTP to HTTPS. Furthermore it should not run into endless redirections which is a very common problem and for which a lot of reasons can be found. Hence wordpress should provide readable and reliable permalinks.

Install wordpress
Let’s start with the backend server. Install all necessary LAMP packages such as:

$ sudo  apt-get install apache2 mysql-client
mysql-server php5 php5-mysql php5-curl php5-gd

Log in to your database:

$ mysql -u root -p

Create the database and user:

mysql> CREATE DATABASE DB_NAME; 
mysql> CREATE USER DB_USER@localhost 
       IDENTIFIED BY 'DB_PASSWORD';

mysql> GRANT ALL PRIVILEGES ON DB_NAME.* 
       TO DB_USER@localhost;

mysql> FLUSH PRIVILEGES; 
mysql> EXIT

Restart apache and mysql

$ sudo service apache2 restart 
$ sudo service mysql restart

Get the wordpress‘ binaries:

$ cd /tmp 
$ wget -c http://wordpress.org/latest.zip 
$ sudo unzip -q latest.zip -d /var/www/html/

Important: Install wordpress into a subdirectory – called WP_DIR – within apache’s root. For debian/ubuntu based Linux distributions this looks typically like:

/var/www/html/WP_DIR

Installing wordpress into a subdirectory prevents nginx from infinite redirecting loops. So keep the subdirectory’s name in mind. It will be used later.

Finish the worpress installation:

$ cd /var/www/html
$ sudo mv wordpress WP_DIR
$ sudo chown -R www-data.www-data WP_DIR
$ sudo chmod -R 755 WP_DIR
$ cd WP_DIR 
$ sudo mkdir -p wp-content/uploads
$ sudo chown -R www-data.www-data
wp-content/uploads

Prepare the wordpress configuration;

$ cd /var/www/html/WP_DIR
$ cp wp-config-sample.php wp-config.php

Open the configuration file:

$ vi wp-config.php

Register the database by replacing the bold parameters with values you have choosen above:

define('DB_NAME', 'DB_NAME');
define('DB_USER', 'DB_USER');
define('DB_PASSWORD', 'DB_PASSWORD');

Restart apache and mysql again:

$ sudo service apache2 restart 
$ sudo service mysql restart

Generate self signed SSL certificates
Let’s continue with the SSL configuration on the backend. Start with the generation of the private RSA key:

$ openssl genrsa -des3 
                 -passout pass:x 
                 -out server.key 1024

Copy the key:

$ cp server.key server.key.out

Remove the passphrase:

$ openssl rsa -passin pass:x 
              -in server.key.out  
              -out server.key

Remove the temporary key:

$ rm server.key.out

Create CSR (Certificate Signing Request):

$ openssl req -new 
              -key server.key 
              -out server.csr

Create the self signed certificate:

$ openssl x509 -req 
               -days 365 
               -in server.csr 
               -signkey server.key 
               -out server.crt

Copy the keys to apache:

$ sudo cp server.crt /etc/ssl/certs/ssl.crt
$ sudo cp server.key /etc/ssl/private/ssl.key

Configure apache
The following commands enable SSL and rewriting support:

$ sudo a2enmod ssl
$ sudo a2enmod rewrite 
$ sudo a2ensite default-ssl
$ sudo service apache2 restart

Be sure that the AllowOverride directive is set correctly in the httpd.config file:

<Directory />
    Options FollowSymLinks
    AllowOverride All
</Directory>

respectively

<Directory /var/www/html>
    # ... other directives...
    AllowOverride All
</Directory></code>

WordPress SSL/nginx configuration
Open the wordpress configuration file:
$ sudo vi wp-config.php

Append the following lines (Remember: the WP_DIR is now used):

if ($_SERVER['HTTP_X_FORWARDED_PROTO'] == 
    'https')
    $_SERVER['HTTPS']='on';
 
if (isset($_SERVER['HTTP_X_FORWARDED_HOST'])) {
    $_SERVER['HTTP_HOST'] = 
        $_SERVER['HTTP_X_FORWARDED_HOST'];
}
 
$_SERVER['REQUEST_URI'] = 
    str_replace("/wp-admin/", 
        "/WP_DIR/wp-admin/",  
            $_SERVER['REQUEST_URI']);

$_SERVER['REQUEST_URI'] = 
    "/WP_DIR".$_SERVER['REQUEST_URI'];
 
define( 'WP_SITEURL', '/WP_DIR' );
define( 'WP_HOME', '/WP_DIR' );
define(‘FORCE_SSL_ADMIN’, true);

Nginx configuration
Now the frontend called ex.com needs to be configured. To do so, create a nginx configuration file:

$ sudo vi /etc/ngingx/sites-available/nginx.conf

First add security headers:

add_header X-Frame-Options "SAMEORIGIN";
add_header Strict-Transport-Security 
    "max-age=15768000; includeSubDomains";
add_header X-XSS-Protection "1; mode=block";
add_header X-Content-Type-Options "nosniff";
add_header Content-Security-Policy-Report-Only 
    "default-src 'self'; img-src *; 
    style-src 'self' 'unsafe-inline'; 
    script-src 'self' 'unsafe-inline' 
    'unsafe-eval'";

Create a rule, which shifts the HTTP requests to HTTPS:

server {
    server_name ex.com www.ex.com;
    return 301 https://ex.com$request_uri;
}

The servername example.com stands for any servername which has a DNS entry and can be resolved.

Finally the https rule is to be defined. To do so you need to have two parameters:

  • The wordpress install directory WP_DIR
  • Reference to the externally signed SSL certificate and key

Enter the following snipped to nginx.conf as well:

server {
    server ex.com;
    listen 443 ssl;
    ssl_certificate
        /etc/nginx/ssl/CERTIFICATE_NAME;
    ssl_certificate_key 
        /etc/nginx/ssl/PRIVATE_KEY;

    location / {
        return 301
        https://ex.com/WP_DIR$request_uri;
    }

    location /WP_DIR/ {
        proxy_pass https://backend_server;
        proxy_set_header
            X-Forwarded-Host $host;
        proxy_set_header
            X-Forwarded-Proto $scheme;
    }
}

Save nginx.conf and change to the following directory:

$ cd /etc/nginx/sites-enabled

Create the following soft link

$ sudo su -
$ ln -s /etc/ngingx/sites-available/nginx.conf

To terminate the nginx configuration just restart it:

$ sudo service nginx restart

Putting all together
Open a browser and enter the URL http://example.com resp. https://example.com. You should now be able to finish the browser based wordpress configuration.
I hope that this article was useful. Feel free to leave a comment!