Finishing the registration backend
Define what it is
The registration backend is the system the Designer talks to upon a registration or login attempt. We want the registration process to occur after the download, and after the install, not before. In doing so, we want to reduce usage friction. Ultimately, the user would agree to the license, download the Designer, install it, then register (or lose the ability to deploy processes on a remote EC2 server)
What I did
Hugues and I settled on the protocol to use, or rather the format of the request / response. We could have written a wsdl (web services description language), but I felt that was overshooting our needs.
The script I wrote is composed of two parts, one that creates a temporary account, with email information only, and sends a verification email with a link to the second part. This one allows the user to pick a password and provide us with information about himself.
It all interfaces with Salesforce: a lead gets created on temporary registration, and updated when the extra information is provided.
What still needs to be done
There are probably some security holes in there, but that is not our concern for now. Time is better spent on creating value, than preventing destruction of it, at this point in time. We need extensive QA to make sure it works on different platforms with corrupted/non-valid data; after that, we should go production.
The system is currently not isolated from Joomla: it is customized. This prevents us from upgrading as Joomla does, but that wasn’t a shared concern. Isolation can be done in a couple of hours.