Clipperz Community Edition

At the moment the PHP code is still missing some check to avoid data
corruption that could happen if a user changes her data from two concurrent
sessions.

There is already some work done to provide an optimistic-locking on the
data that would avoid any problem, but I was not able to implement the
update query leveraging this lock info.

Other that this, all the other missing features (with regard to the Java
backend) are relevant mostly to performance.

Just read that the online version is a Java app and the PHP is still new.

I'll have a look at coming up with a patch in the next week or so. It's
as simple as going

if(isset($array['key'])) //do something.

It doesn't really make me concerned though as ClipperZ has the whole
zero-knowledge thing going on, so even if there were a horrendous security
vulnerability on the server side (which on cursory examination doesn't seem
to be the case, in fact, the software engineering that has gone into this
is very impressive) all the data is still safe.

Phil,

I am _NOT_ a PHP coder by any standard. I have been able to pack the PHP
community.edition backend striping out anything but the very core feature.

The aim of the PHP backend is to allow anybody to run/test/improve the
Clipperz application on their own computer, but it is definitely not a
production grade software.

Any suggestion on how to improve the the code, better if provided as a
patch, is really welcome.

I've discovered that this happens when display_errors is set to "on" in
php.ini

Looking at firebug when the login happens I'm getting some undefined index
warnings. True, display_errors shouldn't be on in a production
environment, but it's a little sloppy not to do an isset() before
attempting to access an array member.

Does this happen with any username/password combination, or just with some
special values?

At what point of the registration does the procedure halt?
At what point does the next try to login using the just registered
credentials halt?