How a rate button can actually improve your mobile app rating

When I decided to redesign my Android Spirit Level this summer, I was wondering wether or not I should add a "Rate" button to invite users to rate the Bubble Level application.

What I was expecting was more feature requests and a better user feadback. I was also concern about how such a button could annoy users... In the long term, would it lead to a better user rating or a lower user rating ? Here is the answer :

Evolution of the app overall rating

Since the update of late august that added the rate button in the app, overall rating of the app increased faster than before... User feedback was also better because of the easy way to provide it when you see something wrong, something missing or something to improove. In the contrary, number of rates per month does not increase as expected :

Rates per month per value and average rating

I'm not sure wether or not this stat reflect rate that get updated by users... But to provide you with more stats, the rate button has a click to rate rate ;-) of 1 generated rate out of 16 clicks... which is quite low but sufficient to increase the overall rating of the app.

Certificat based client authentication with apache server

This post describe how to create and use a custom certification authority to generate client certificate that will later be used to authenticate users against apache mod_ssl and pass the credential to the underlying server that processes the client requests : Tomcat, JBOSS or anything else... Apache mod_ssl will be configured to use client certificat based strong authentication that only accept requests that comes from clients presenting a certificat signed by a trusted authority.

Creating the certificates

Certification authority

The first step is to generate our own certification authority certificate. This will be done using standard openssl command to generate a RSA key stored under ca.key. This key will be used to generate a self signed certificate under ca.crt :

ca.key

The RSA key of our own authority

ca.crt

The self signed certificate associated with our authority

ca.public.key

The public key of our authority

	openssl genrsa -out ca.key 2048
	openssl req -new -key ./ca.key -out ./ca.csr
	openssl x509 -req -days 365 -in ./ca.csr -out ./ca.crt -signkey ./ca.key
	openssl x509 -in ca.crt -text
	openssl rsa -in ca.key -passin pass:XXXX -pubout -out ca.public.key

view raw ca cert hosted with ❤ by GitHub

Server certificate

The server certificate will be used by the server and presented to the client. It will be signed by the certification authority certificate created above. During the certificate signing request, we'll be asked for a Distinguished Name (DN) or Common Name (CN). The value of that field MUST match the ServerName used in the Apache httpd.conf configuration file. The generation of an unprotected key will allow apache to start without the prompt of a passphrase... which might be useful in some cases.

	openssl genrsa -des3 -out server.key 2048
	openssl req -new -key ./server.key -out server.csr
	openssl x509 -req -in ./server.csr -CA ./ca.crt -CAkey ./ca.key -CAcreateserial -out ./server.crt -days 365
	openssl pkcs12 -export -in server.crt -inkey server.key -out server.p12 -name "server certificate"
	openssl pkcs12 -info -in server.p12
	openssl rsa -in server.key -passin pass:XXXX -pubout -out server.public.key
	openssl rsa -in server.key -out server.nopassphrase.key

view raw server cert hosted with ❤ by GitHub

Client certificate

The client certificate is generated like the server certificate. Each client will have its own certificate that uniquely identifies him. It will be signed by the same certification authority. during the creation of the X.509 client certificat, you'll be prompted for Subject informations. Those informations will be used as credentials to authenticate the user on the underlying server that actually processes the request.

	openssl genrsa -des3 -out client.key 2048
	openssl req -new -key ./client.key -out client.csr
	openssl x509 -req -in ./client.csr -CA ./ca.crt -CAkey ./ca.key -CAcreateserial -out ./client.crt -days 365
	openssl pkcs12 -export -in client.crt -inkey client.key -out client.p12 -name "client certificate"
	openssl pkcs12 -info -in client.p12
	openssl rsa -in client.key -passin pass:XXXX -pubout -out client.public.key

view raw client cert hosted with ❤ by GitHub

Apache server configuration

The Apache server will be configured to only accept requests that comes from clients presenting a client certificate that is signed by our own certification authority. This is done in the httpd.conf by using those directives in the dedicated SSL VirtualHost :

	# Doit correspondre au DN du certificat server
	ServerName domain
	# Encryption et certificat serveur
	SSLEngine On
	SSLCertificateFile conf/certs/server.crt
	SSLCertificateKeyFile conf/certs/server.nopassphrase.key
	# Impose la présentation d'un certificat client
	SSLVerifyClient require
	SSLVerifyDepth 2
	# Certificat de l'autorité de certification reconnue pour les clients
	SSLCACertificateFile conf/certs/ca.crt

view raw httpd.conf hosted with ❤ by GitHub

SSLVerifyClient

The require value force the client to provide its own X.509 certificate during the SSL handshake.

SSLVerifyDepth

Specifies the minimum depth that will be scanned by the server to check for trusted certification authority in the client certificate. A value of 0 will only allow self signed certificates. A value of 1 will accept both self signed certificates and certificates signed by an authority known by the server. In our case, we will use a value of 2 that will only accept certificates signed by an authority known by the server.

SSLCACertificateFile

Specifies the trusted certification authorities.

Thus, only the requests signed by our clients will be authorized.