s�ndag 25. april 2004, 19:43, skrev Andreas Schuldei: > So what would you think? What *should* happen? right now i > envision the process like this: > > fileimport with weak passwords and double and existing usernames > leads back to the column selection page, with the weak passwords > and the boguous usernames marked in the table and a button saying > "ok, those are bogus, create better ones for me in the process"
This is an generic problem that repeats itself whenever users with password is created. There is a major design change from WLUS 1.2-25 until 1.2.28. Thats the auto-generating password algorithm with checking for weak passwords. This really turn some of the functionality upside down, and trigger some need for escape methods for the user. All this was brought to the light when introducing a major change in the password-generating function. The general idea is to strict up the passwords, and take the choice away from the ICT-manager. This is general a good idea, that is to enforce stricter procedure to make passwords. But some of the design in the user-interface tells an other story. The GUI is wide open to make your own choices when it comes to user-names, password and so on -- when doing file-import -- or when creating common password, when creating one or more users from the GUI. There is an short path, a long path to solve this, and get rid of the ambiguity. It's also a third. That is to let the system pick a auto-password for every user. The GUI don't support that, because of the suggested Common Password-functionality. 1. The short path is to accept what the GUI tells the users 110%. When the user says override the built in password-generation algorithm, just do that. Then you also has to override the "generate better password in stead"-algorithm. This also overrides the pre-configured setting in the config-panel for WLUS. 2. The longer path is a way to second guess the user. This is what Andreas suggests, to return to the "start" position, and give the ICT-admin better and stricter password(s) to choose from. The program suggests what the users should select when the password is to weak. The GUI suggest to the user a stronger passwords to use, and what the user-name should look like. This has to be consistent in the GUI, both when generating users from file or from the "make one-or-more users"-functionality in the GUI. 3. The third path was almost the functionality I observed in 1.2-27 of WLUS. There is no way of overriding the password-generating algorithm. It just auto-generated passwords even if the GUI told the opposite story. A regular user will immediately reject the third point (3.) of programing the GUI. This is because of opposite functionality, the GUI tells one story, but second guess the users choice by default. This is not good, and is an invitation to make the user angry at the program. If this program-functionality is chosen, the "Common Password" choice shold be removed. Also the password-from-file should be removed as an option. The first choice (1.) is the obvious choice. That is what the GUI tells the users, and that is what the users should get. The second choice (2.) is probably the best way. This is the idea from Andreas where the user get a feedback with possibilities to choose from when creating new users. Then the ICT-admin can select stricter password and other users names thats already taken. The problem with the second alternative is that it should be done more consistent. This because of three requests. 4.1 The first ones was from Ralf that wants to edit the naming rules. If I have understood this right, he wants to have a password-config-look-alike thing with hierarchy file-system, or prefix on some of the class-names. To get a class-folder can also be done today with creating a "user" with the name on the school-class, where every pupil in that class is in the school-class-folders group. So in a way this is solved with thinking a bit different and UNIX-like with using group-functionality (gid) as they should be used. 4.2 The other one is the tightening of the passwords. This is in a way coupled to what is pre-configured in the config-WLUS-panel in Webmin. If the ICT-manager has suggests to weak passwords, the GUI presents new and stronger passwords. The GUI could also present the password that is to be replaced. 4.3 When doing 4.2 this should be consistent everywhere, both when creating new users directly from the GUI, or from the file. This is, as Andreas suggested, an extra step: > note that this is some more coding (which i started already) and a > somewhat bigger change. not sure how intrusive it will be. All this "in consequence of" strict password-generating, and the "Common Password from GUI/Preselected password from file". So the brute force here is to go for alternative 1. Doing exactly what the GUI tells, with overriding the auto-password-generating when ICT-admin select "Common Password/Preselected password from file". The other way is to lett the GUI suggest tighter password when the ICT-admin has selected to weak ones :-). This is, as Andreas pointed out, more programming. How to prioritise? The easiest way is to select option 1. It's mostly 5 days to release the WLUS for major use. If the option 2. is almost finished, it's easy to debug from a usability point of view. I think Andreas know whats we are up against with testing this now. What do you think? - K
