why are you guys developing your own Authentication?
what I mean is there's apache which does basic/digest auth (over ssl)
so why not use apache or saslauthd or imap auth (and let it handle authorization) egroupware does it that way and generates a user if succesfully authorized against an imap server
then do something like generate a user in a default group (customizable which of course)
or display some error message and tell that the account hasn't been activated
or force the admin to create all accounts in advance (one has to do so now anyway)
These are the advantages I see:
The disantvantages I see:
- You won't have to care about authentication any more
- Your codebase will be smaller
- If you decide to change something in the background you will still provide a stable auth interface to your customers (switching from ldap to sql IMHO stinks)
- the auth modules from apache (and probably cyrus, and a bunch of other software) are well tested and proven to be stable
- the 0.8x users will have some way of upgrading (the sql data at least but a well designed authentication layout will not just swallow that switch from ldap to sql and with encrypted passwords generation of users from ldap to OX isn't that easy....)
- You need to rewrite some part of your app
- Now within hyperion it will be a switch again (but you could provide the above as an alternative)
- ....the basic auth dialog in apache isn't really nice, but that is something you can circumvent....
We build our own authentication so that hyperion can be plugged into an existing authentication system of some of our customers. Though I agree it would be a smart move to maybe provide the option of using some existing authentication solution. This would have to be done without impacting the protocol between the GUI (our primary client) and the server though, which could prove tough. Definitely worth investigating, though.