[ postfixadmin-Patches-2678293 ] [PATCH] Allow login to normal user
Brought to you by:
christian_boltz,
gingerdog
Menu
▾
▴
[ postfixadmin-Patches-2678293 ] [PATCH] Allow login to normal user
|
From: SourceForge.net <no...@so...> - 2009-03-12 22:02:38
|
Patches item #2678293, was opened at 2009-03-10 11:44 Message generated for change (Comment added) made by christian_boltz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937966&aid=2678293&group_id=191583 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core Group: SVN (please specify revision!) Status: Open Resolution: None Priority: 5 Private: No Submitted By: Fabio Bonelli (fabiobon) Assigned to: Nobody/Anonymous (nobody) Summary: [PATCH] Allow login to normal user Initial Comment: Hi there, This patch adds the possibility for a normal user to log in and modify his password. Against r572. ---------------------------------------------------------------------- >Comment By: Christian Boltz (christian_boltz) Date: 2009-03-12 23:02 Message: @libertytrek: if you submit a patch which introduces $CONF['users_password_control'] and $CONF['users_forward_control'] to disable these parts of users/, I'll probably accept it. [Please open a new tracker item for such a patch.] Ironically the existing code already allows to disable vacation config for users ($CONF['vacation_control']) which is the only part you don't want to disable ;-) ---------------------------------------------------------------------- Comment By: Fabio Bonelli (fabiobon) Date: 2009-03-12 12:35 Message: @libertytrek: The patch doesn't enforce anywhere the ability for users to change theirs password: your local changes will behave just the same as before. ---------------------------------------------------------------------- Comment By: Charles (libertytrek) Date: 2009-03-12 12:20 Message: I actually much prefer to keep user login totally separate... Call me old fashioned, but I just like it that way. Please don't 'unify' them... I actually don't WANT the users to be able to change their passwords for one server I manage... passwords are assigned and periodically changed... I had to modify the users template to remove the code allowing them to change their passwords AND the code allowing them to create forwarders (this was being heavily abused)... but I did want them to still be able to manage their vacation message... ---------------------------------------------------------------------- Comment By: Charles (libertytrek) Date: 2009-03-12 12:15 Message: I actually much prefer to keep user login totally separate... Call me old fashioned, but I just like it that way. Please don't 'unify' them... I actually don't WANT the users to be able to change their passwords for one server I manage... passwords are assigned and periodically changed... I had to modify the users template to remove the code allowing them to change their passwords AND the code allowing them to create forwarders (this was being heavily abused)... but I did want them to still be able to manage their vacation message... ---------------------------------------------------------------------- Comment By: Fabio Bonelli (fabiobon) Date: 2009-03-12 11:06 Message: @christian: Thank you for the insights about how language-update.sh works. That's good to know. BTW, are conflicting logins for admins really a problem? An admin (hopefully) knows to be one and will use it's admin password. Additionally, if the admin username exists and the password is wrong, we don't try looking inside $table_mailbox, we give the right error message. There is just no ambiguity. He couldn't access its unprivileged account, but who cares? He can edit the same stuff as admin anyway. @gingerdog: I think it would bring a little usability improvement. The second patch keeps /users intact, it removes users/login.php. ---------------------------------------------------------------------- Comment By: GingerDog (gingerdog) Date: 2009-03-12 09:41 Message: @cboltz: err... refactoring (to abuse the word) /users and adding an xmlrpc interface for email plugins (E.g. Squirrelmail/Roundcube). Should be finished in the next day or two - I've done everything /apart/ from the vacation facing stuff which is ~50% complete. This probably shouldn't be something that enters so late in 2.3beta, but as I seem to be the unofficial release manager, I figure I can abuse the process :) With regards to the patch - I don't really see the point in it. There is already /users.... if we merge it, what do we do with /users? ---------------------------------------------------------------------- Comment By: Christian Boltz (christian_boltz) Date: 2009-03-11 23:31 Message: For the records: language-update.sh intentionally doesn't remove strings automatically. Instead, it has a "--remove" paramter. If you think a string is obsolete, just mark it in en.lang with a comment like "# XXX no longer used" (the XXX marker is important because I grep for it ;-) and I'll remove it from the translation files. Before doing so, I'll grep the whole code for the string to be sure it is really no longer used. Your idea to merge the users/ login and the main login is interesting. The only problem might be conflicting login data for admins and mailboxes, but this is solvable (maybe by allowing [not necessarily enforcing] admin usernames that are not mail adresses?) BTW: I had a quick look at your patch and didn't find any (obvious) errors. The only thing I'm not sure is if we should integrate it in 2.3 (which would mean a major UI change between beta and final) or if we should integrate it after the release. @GingerDog: What's your opinion about this? And what exactly are you working on currently? ;-) ---------------------------------------------------------------------- Comment By: Fabio Bonelli (fabiobon) Date: 2009-03-11 10:06 Message: Err, as we have a custom style applied to login.php I didn't notice that. It's useful to unify logins, though, in order to give customer the same URL. Here you are the patch. I'm not sure whether just removing stuff from en.lang is the correct thing to do when translations become obsolete. It seems language-update.sh doesn't deal with it. ---------------------------------------------------------------------- Comment By: GingerDog (gingerdog) Date: 2009-03-10 12:24 Message: (for what it's worth I'm working on refactoring the user-facing code to make it easier to integrate with e.g. mail clients like squirrelmail etc.... this should be finished in the next few days...) ---------------------------------------------------------------------- Comment By: GingerDog (gingerdog) Date: 2009-03-10 12:23 Message: Sorry; how is this any different from accessing 'users/login.php' and subsequent pages? Is it not obvious enough that /users/login.php is available? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937966&aid=2678293&group_id=191583 |