I would refer you to not play with username (userid/principal name) and because you have this requirement i will suggest to add one more property to user node (/home/users) say user_login_name which will have same value as username (rep:principalName) while first time registration.
Now you have to do small tweak in your login module, every time when user will login you would expect value for "user_login_name" and once user click on login button before submitting for authorization you have to query to repository system to get actual username (rep:principalName) from repository and then use actual username for login. It means "login_user_name" will be just for display but back side you will be running same logic by small code tweak.
Now about changes to login_user_name can be easily placed as everytime you will be allowing user to update "login_user_name" not "username" but you must have to take care of one thing that there will be no duplicate "login_user_name" in system. For that you can write a listener which will be fired at the time of form submit or may be you can also do through client side script validation (you have to some research for feasibility at client side - may be "ecma" script can help).
For even listener plz refer - http://blogs.adobe.com/contentmanagement/2012/08/27/how-to-prevent-users-from-entering-dup licate-vanity-urls/
For more information or any issue in listener let me know.
Thanks Pawan, your proposal to do this is in line with how we already thought of doing this. Had hoped there would be an easier way. The difficulty is that when you have 2 publisher instances you need to handle the case where potentially 2 users access the 2 different publish instances and request the same username in their form. The publish instances will be unaware of of each other's request. So this needs to be handled at the author level. But how to feed back the information to the site visitor if the reqistration was unsucccesful. Because the business requirement is that the user can browse straight after having registered, no activation email is sent out, no confirmation need to be given.
So this is what i think and suggest.
1. Users that you are planning to manage are actually your application users not the CQ system users so i am not sure why you want it be stored/manage from author node instead publish because there you can store/manage user (application user) as well only you have to assign them propert ACL.
2. One more thing you have to take care of is synchronous reques processing and that you can do in any java code (either write service or servlet)
And it supports to your requirement as well because your requirement does not require moderating of registered users.
I hope it will help you to make decision. for more information let me know.\
Thanks for your reply. We need to manage them at author level because we have multiple publish instances running. The Author has to be the master.
Yep, am aware of synchronous request processing. But this still won't resolve the issue if two users at two (different) pub instances request the same username simultanuously. A rare event, I'm sure, very unlikely to happen because in our case username will be email address, but nevertheless a possibility, considering replication is not instantanuous and we want to give the users direct access after clicking the registration submit button. One way to resolve this would be to let the users click on a activation email, or to let them see a "processing screen" while all this happens in the background. But since we've noticed replication can be slow at times we suspect this delay can be more than a few minutes at peak times. And the business does not want that.