postfixadmin-tracker Mailing List for PostfixAdmin (Page 39)
Brought to you by:
christian_boltz,
gingerdog
Menu
▾
▴
postfixadmin-tracker — Postfix Admin tracker notification - READ ONLY!
You can subscribe to this list here.
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(5) |
Oct
(67) |
Nov
(83) |
Dec
(47) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2008 |
Jan
(57) |
Feb
(15) |
Mar
(21) |
Apr
(38) |
May
(27) |
Jun
(38) |
Jul
(35) |
Aug
(50) |
Sep
(8) |
Oct
(9) |
Nov
(59) |
Dec
(59) |
| 2009 |
Jan
(27) |
Feb
(42) |
Mar
(63) |
Apr
(46) |
May
(26) |
Jun
(25) |
Jul
(40) |
Aug
(19) |
Sep
(17) |
Oct
(35) |
Nov
(26) |
Dec
(21) |
| 2010 |
Jan
(11) |
Feb
(19) |
Mar
(40) |
Apr
(25) |
May
(23) |
Jun
(17) |
Jul
(10) |
Aug
(18) |
Sep
(21) |
Oct
(12) |
Nov
(10) |
Dec
(22) |
| 2011 |
Jan
(30) |
Feb
(23) |
Mar
(23) |
Apr
(38) |
May
(32) |
Jun
(19) |
Jul
(20) |
Aug
(36) |
Sep
(11) |
Oct
(28) |
Nov
(4) |
Dec
(4) |
| 2012 |
Jan
(6) |
Feb
(3) |
Mar
(16) |
Apr
(28) |
May
(29) |
Jun
(10) |
Jul
(2) |
Aug
(3) |
Sep
|
Oct
(13) |
Nov
(1) |
Dec
(1) |
| 2013 |
Jan
(11) |
Feb
(7) |
Mar
(29) |
Apr
(2) |
May
(3) |
Jun
(15) |
Jul
(8) |
Aug
(5) |
Sep
(5) |
Oct
(4) |
Nov
(27) |
Dec
(81) |
| 2014 |
Jan
(12) |
Feb
(13) |
Mar
(5) |
Apr
|
May
(41) |
Jun
(16) |
Jul
(7) |
Aug
(10) |
Sep
(24) |
Oct
(50) |
Nov
|
Dec
(2) |
| 2015 |
Jan
(5) |
Feb
(2) |
Mar
(7) |
Apr
(20) |
May
(1) |
Jun
(3) |
Jul
(12) |
Aug
(1) |
Sep
(17) |
Oct
(5) |
Nov
(20) |
Dec
(10) |
| 2016 |
Jan
(10) |
Feb
(11) |
Mar
(22) |
Apr
(30) |
May
(33) |
Jun
(3) |
Jul
|
Aug
(12) |
Sep
(20) |
Oct
(11) |
Nov
(15) |
Dec
(8) |
| 2017 |
Jan
(1) |
Feb
(11) |
Mar
(10) |
Apr
|
May
(3) |
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
(1) |
Nov
|
Dec
(3) |
| 2018 |
Jan
(2) |
Feb
|
Mar
(1) |
Apr
|
May
(4) |
Jun
(2) |
Jul
(4) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2019 |
Jan
|
Feb
|
Mar
|
Apr
(3) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2021 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: SourceForge.net <no...@so...> - 2009-03-18 18:56:18
|
Bugs item #2605817, was opened at 2009-02-16 14:50 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=2605817&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: Vacation Group: None >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: Henrique Bueno (henriquebueno) Assigned to: Nobody/Anonymous (nobody) Summary: problem to send auto-reply - function do_mail Initial Comment: the var $orig_to sometimes was wrong value, ex: $orig_to= KF5X00$E00913775B96D4FF419472648EEE6670@multidominios instead of $orig_to=lop...@te... Solution: do_mail ($orig_to, $orig_from, $row[0], $row[1]); alter to do_mail ($email, $orig_from, $row[0], $row[1]); on line 163 ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 2009-03-18 18:55 Message: This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). ---------------------------------------------------------------------- Comment By: Christian Boltz (christian_boltz) Date: 2009-02-19 11:04 Message: I grepped the current SVN version for do_mail and found nothing. Searching in older versions brings up the old MySQL-only vacation.pl, which had a function named do_mail. Henrique, you are most probably using an old version. Please upgrade to the latest version of Postfixadmin (2.3 beta or SVN) and test again. Does this fix your problem? ---------------------------------------------------------------------- Comment By: GingerDog (gingerdog) Date: 2009-02-18 20:35 Message: Hi, Which file is this in reference to? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=2605817&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2009-03-14 10:21:13
|
Patches item #2607332, was opened at 2009-02-17 00:43 Message generated for change (Comment added) made by trendypack You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937966&aid=2607332&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: cmuelle8 (trendypack) Assigned to: Nobody/Anonymous (nobody) Summary: add dovecotpw encrypt support option for dovecot users Initial Comment: Hi, please apply the following patch to functions.inc.php. Background: I don't want to store the pws plain. Auth mechanisms supported in dovecot: plain login cram-md5 digest-md5 (crypt-md5 is not supported as an auth mechanism, look at http://wiki.dovecot.org/Authentication/Mechanisms and ). I'm aware that using PLAIN or LOGIN over SSL is a viable option (in this case dovecot does PLAIN to MD5-CRYPT and compares). However, in a non-ssl scenario PLAIN and LOGIN are a bad option and disabled by default in dovecot. Using CRAM-MD5 or DIGEST-MD5 is possible, but then the passwords have to be in CRAM-MD5 format as well (since dovecot can't do CRAM-MD5 to MD5-CRYPT, obviously). The patch below makes this an option for dovecot users. A hint in config.inc.php will probably also be needed (along the comment lines for the other authentication methods). Greetings, cmuelle8 --- functions.inc.php.orig 2009-02-17 00:06:37.000000000 +0100 +++ functions.inc.php.cram-md5 2009-02-17 00:00:23.000000000 +0100 @@ -1126,6 +1126,11 @@ $password = md5($pw); } + if ($CONF['encrypt'] == 'cram-md5') { + $password = shell_exec("dovecotpw -s CRAM-MD5 -p $pw"); + $password = trim(str_replace('{CRAM-MD5}', '', $password)); + } + if ($CONF['encrypt'] == 'system') { if (ereg ("\$1\$", $pw_db)) { $split_salt = preg_split ('/\$/', $pw_db); ---------------------------------------------------------------------- >Comment By: cmuelle8 (trendypack) Date: 2009-03-14 11:20 Message: Not removing {$method} means that every app using this db field must understand this prefix - I removed it, cause I feared that it would get me into trouble setting up dovecot+postfix somewhere in the process. After all, what you suggest might work if you only use the dovecot auth stuff (and postfixadmin if we program it that way) to access the field, but I have not even checked, if all of dovecot understands the prefix added by dovecotpw (which you would think, but I'm just not sure). Personally I think it's a source of error, permiting multiple methods in that field + it restricts you to software that understands this prefix. Greetings and thx for fixing it up to your own suggestions.. cmuelle8 ---------------------------------------------------------------------- Comment By: Christian Boltz (christian_boltz) Date: 2009-03-14 00:35 Message: I just commited a modified version of your patch to SVN (r580), with most issues I listed solved. Changes compared to your patch: - fixed b) (error checking) by checking the encryption result against "^{$method}" - fixed c) by checking for ^dovecot: - Note: If someone sets $CONF['encrypt'] = "dovecot" instead of "dovecot:xy", it will result in the message "unknown/invalid $CONF[encrypt] setting", not "invalid dovecot encryption method" - fixed d) by checking that $method only contains [A-Z0-9-] - having a list of methods supported by dovecot would be better, but I don't have such a list ;-) - fixed e) - see $CONF['dovecotpw'] - $method is converted to uppercase since dovecotpw always returns the method uppercase - initializie $prefix for tempfile (was undefined) The only thing I did not (yet) change is a) (tempfile usage) for which I added a TODO comment. (@GingerDog: This part is not blocking the release.) One question came up while working on this: Why do you remove the {$method} part from the encrypted password? IMHO keeping it would be an advantage, because it would allow switching the encryption method without the need to change/reencrypt existing passwords. ---------------------------------------------------------------------- Comment By: GingerDog (gingerdog) Date: 2009-03-08 20:50 Message: Hi, Any chance of an updated patch then? ---------------------------------------------------------------------- Comment By: Christian Boltz (christian_boltz) Date: 2009-02-25 23:17 Message: Unfortunately "works for me" doesn't mean it is good - at least from my POV. But maybe I'm too strict ;-) The patch looks much better than the previous one, but I still have some things that should be improved: a) tempfile for the password Basically a good idea, but please switch to the tmpfile() PHP function - in comparison to tempnam() it has some advantages: - no need to specify the path - might be relevant on systems with open_basedir, where /tmp is outside the allowed path. (In this case $TMPDIR has to be set as environment variable, but this is easier to do (via apache config) than a hardcoded path.) - the tempfile is automatically deleted After re-reading the code and some PHP documentation, I think that proc_open (allows two-way communication with external processes) might be the best solution. You can even catch STDERR on a separate pipe to check for error messages. See http://www.php.net/manual/en/function.proc-open.php for description and an example. (With proc_open, no tempfile will be needed.) b) error checking The only error checking you do is not to use the pipe to dovecotpw if it can't be opened. If opening the pipe works, you blindly read the encrypted password from the temp file (or whatever the file contains ;-) Please check that the output looks like an encrypted password - shouldn't be too hard since it has to contain "{$method}" at the beginning. Untested: if ( !preg_match("/^{$method}/", $password) { die("can't encrypt password with dovecotpw") } I don't really like the die() method, but the pacrypt function doesn't offer a better way to error out currently :-( Additionally the calling functions expect pacrypt to "always work" - which was not a real problem up to now because it used only PHP-internal functions. c) if (strstr($CONF['encrypt'], 'dovecot:')) -> Please ensure that the $CONF parameter _begins_ with "dovecot:" - for example by using preg_match("/^dovecot:/", $CONF['encrypt']) Besides that, I like the idea of using "method:detail" - @GingerDog: This might also be an option for authlib / $CONF['authlib_default_flavour']. d) check/validate what becomes $method Even if $method comes from $CONF['encrypt'] , it may still contain an invalid value (like "dovecot:foobar") or evil characters ("dovecot:md5';rm -rf /"). There are several ways how this can be secured. I'll start with the best one. - check against an array of allowed password encryption methods. This is the most secure method, but has the disadvantage that it needs a code modification in case dovecot starts to support a new encryption method - check $method against a regular expression. preg_match("/[a-zA-Z0-9-]+/", $method) should do if I get the dovecot documentation right. - at least use escapeshellarg($method) if you really don't want to validate $method e) path to dovecotpw I'm quite sure "dovecotpw must be in $PATH" will cause some problems - for example the openSUSE package has dovecotpw in /usr/sbin - and therefore not in the webserver's $PATH. The only solution for this is a $CONF['dovecotpw'] = "/path/to/dovecotpw" parameter. (If this is not set or empty, you can still default to just "dovecotpw".) Maybe it can be included in $CONF['encrypt'] - something like "dovecot:MD5:/usr/sbin/dovecotpw" would work. However, things will become complicated when we add another 5 parameters to this string *g* BTW: Feel free to include the needed config.inc.php changes in your patch. The comment should mention the most common CRYPT-METHODs for dovecot. ---------------------------------------------------------------------- Comment By: cmuelle8 (trendypack) Date: 2009-02-25 17:07 Message: Absolutely, it works for me. Please make sure you add # dovecot:CRYPT-METHOD => use dovecotpw -s 'CRYPT-METHOD' (needs to be in PATH) or something more descriptive to config.inc.php though - the patch only modifies the functions file. Greetings, Christian ---------------------------------------------------------------------- Comment By: GingerDog (gingerdog) Date: 2009-02-24 21:33 Message: Christian - are you happy with this now? Can it be merged? ---------------------------------------------------------------------- Comment By: cmuelle8 (trendypack) Date: 2009-02-18 09:24 Message: File Added: postfixadmin.functions.patch ---------------------------------------------------------------------- Comment By: cmuelle8 (trendypack) Date: 2009-02-18 07:58 Message: alright, here's a revised patch.. hopefully this will do - as this is not the default in config.inc.php anyway, a note along the other encrypt methods will probably do: # dovecot:CRYPT-METHOD => use dovecotpw -s 'CRYPT-METHOD' (needs to be in PATH) best wishes, cmuelle8 (Christian Müller) File Added: postfixadmin.functions.patch ---------------------------------------------------------------------- Comment By: Christian Boltz (christian_boltz) Date: 2009-02-17 23:54 Message: Thanks for your patch! However, I see some problems with it: a) the password should be quoted/escaped/whatever before using it in the command line. You'll understand what I mean when somebody uses "topsecret ; rm -rf /" as his password *g* Hint: use escapeshellarg($pw) b) I don't really like that an external program is called with the password as parameter (which will be visilble for a short time in the process list). c) no error checking (what happens if dovecotpw is not installed or not in $PATH?) As you can see: things aren't that easy once you start calling external programs ;-) Unfortunately dovecotpw isn't easy to "emulate" in PHP, so calling dovecotpw might be the easiest option, even with the described disadvantages. For some information about "emulating" dovecotpw, see http://markmail.org/message/ug4mfvulgsajg3wk#query:dovecotpw%20php+page:1+mid:snbusk5sempgouyb+state:results http://www.scconsult.com/bill/crampass.pl http://www.dovecot.org/list/dovecot/2007-March/020889.html ---------------------------------------------------------------------- Comment By: cmuelle8 (trendypack) Date: 2009-02-17 02:02 Message: File Added: postfixadmin.functions.patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937966&aid=2607332&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2009-03-13 23:50:30
|
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-14 00:50 Message: @libertytrek: come on - it isn't that difficult ;-) Please see https://sourceforge.net/tracker2/?func=detail&aid=2686611&group_id=191583&atid=937967 for details (that's a feature request I just opened for your issue). ---------------------------------------------------------------------- Comment By: Charles (libertytrek) Date: 2009-03-13 12:00 Message: @christian_boltz: if I were a programmer, I'd be happy to - and would have contributed other things long before now... but,you really don't want to see a patch from me... unless you have a really twisted sense of humor. ;) Also, sorry for the double-post, not sure how that happened... ---------------------------------------------------------------------- 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 |
|
From: SourceForge.net <no...@so...> - 2009-03-13 23:48:42
|
Feature Requests item #2686611, was opened at 2009-03-14 00:48 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937967&aid=2686611&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: Christian Boltz (christian_boltz) Assigned to: Nobody/Anonymous (nobody) Summary: allow disabling changing password / forwarding for users Initial Comment: Comment from libertytrek in https://sourceforge.net/tracker2/?func=detail&atid=937966&aid=2678293&group_id=191583 ---------------------------------------------------------------------- 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... ---------------------------------------------------------------------- @libertytrek: come on - it isn't that difficult ;-) There are two methods to disable code sections based on a $CONF variable: a) if you want to disable a small section (for example the menu entry), wrap it in an if block: if (boolconf('users_password_control')) { ... code printing the menu item ... } b) to disable the whole file, add the following section at the beginning if( !boolconf('users_password_control') ) { header("Location: " . $CONF['postfix_admin_url'] . "/users/main.php"); exit(0); } And yes, I really want to see a patch from you. Even if it isn't perfect, it makes it easier for me than doing all the needed changes myself. At least I see which code sections need to be changed ;-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937967&aid=2686611&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2009-03-13 23:36:21
|
Patches item #2607332, was opened at 2009-02-17 00:43 Message generated for change (Comment added) made by christian_boltz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937966&aid=2607332&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: cmuelle8 (trendypack) Assigned to: Nobody/Anonymous (nobody) Summary: add dovecotpw encrypt support option for dovecot users Initial Comment: Hi, please apply the following patch to functions.inc.php. Background: I don't want to store the pws plain. Auth mechanisms supported in dovecot: plain login cram-md5 digest-md5 (crypt-md5 is not supported as an auth mechanism, look at http://wiki.dovecot.org/Authentication/Mechanisms and ). I'm aware that using PLAIN or LOGIN over SSL is a viable option (in this case dovecot does PLAIN to MD5-CRYPT and compares). However, in a non-ssl scenario PLAIN and LOGIN are a bad option and disabled by default in dovecot. Using CRAM-MD5 or DIGEST-MD5 is possible, but then the passwords have to be in CRAM-MD5 format as well (since dovecot can't do CRAM-MD5 to MD5-CRYPT, obviously). The patch below makes this an option for dovecot users. A hint in config.inc.php will probably also be needed (along the comment lines for the other authentication methods). Greetings, cmuelle8 --- functions.inc.php.orig 2009-02-17 00:06:37.000000000 +0100 +++ functions.inc.php.cram-md5 2009-02-17 00:00:23.000000000 +0100 @@ -1126,6 +1126,11 @@ $password = md5($pw); } + if ($CONF['encrypt'] == 'cram-md5') { + $password = shell_exec("dovecotpw -s CRAM-MD5 -p $pw"); + $password = trim(str_replace('{CRAM-MD5}', '', $password)); + } + if ($CONF['encrypt'] == 'system') { if (ereg ("\$1\$", $pw_db)) { $split_salt = preg_split ('/\$/', $pw_db); ---------------------------------------------------------------------- >Comment By: Christian Boltz (christian_boltz) Date: 2009-03-14 00:35 Message: I just commited a modified version of your patch to SVN (r580), with most issues I listed solved. Changes compared to your patch: - fixed b) (error checking) by checking the encryption result against "^{$method}" - fixed c) by checking for ^dovecot: - Note: If someone sets $CONF['encrypt'] = "dovecot" instead of "dovecot:xy", it will result in the message "unknown/invalid $CONF[encrypt] setting", not "invalid dovecot encryption method" - fixed d) by checking that $method only contains [A-Z0-9-] - having a list of methods supported by dovecot would be better, but I don't have such a list ;-) - fixed e) - see $CONF['dovecotpw'] - $method is converted to uppercase since dovecotpw always returns the method uppercase - initializie $prefix for tempfile (was undefined) The only thing I did not (yet) change is a) (tempfile usage) for which I added a TODO comment. (@GingerDog: This part is not blocking the release.) One question came up while working on this: Why do you remove the {$method} part from the encrypted password? IMHO keeping it would be an advantage, because it would allow switching the encryption method without the need to change/reencrypt existing passwords. ---------------------------------------------------------------------- Comment By: GingerDog (gingerdog) Date: 2009-03-08 20:50 Message: Hi, Any chance of an updated patch then? ---------------------------------------------------------------------- Comment By: Christian Boltz (christian_boltz) Date: 2009-02-25 23:17 Message: Unfortunately "works for me" doesn't mean it is good - at least from my POV. But maybe I'm too strict ;-) The patch looks much better than the previous one, but I still have some things that should be improved: a) tempfile for the password Basically a good idea, but please switch to the tmpfile() PHP function - in comparison to tempnam() it has some advantages: - no need to specify the path - might be relevant on systems with open_basedir, where /tmp is outside the allowed path. (In this case $TMPDIR has to be set as environment variable, but this is easier to do (via apache config) than a hardcoded path.) - the tempfile is automatically deleted After re-reading the code and some PHP documentation, I think that proc_open (allows two-way communication with external processes) might be the best solution. You can even catch STDERR on a separate pipe to check for error messages. See http://www.php.net/manual/en/function.proc-open.php for description and an example. (With proc_open, no tempfile will be needed.) b) error checking The only error checking you do is not to use the pipe to dovecotpw if it can't be opened. If opening the pipe works, you blindly read the encrypted password from the temp file (or whatever the file contains ;-) Please check that the output looks like an encrypted password - shouldn't be too hard since it has to contain "{$method}" at the beginning. Untested: if ( !preg_match("/^{$method}/", $password) { die("can't encrypt password with dovecotpw") } I don't really like the die() method, but the pacrypt function doesn't offer a better way to error out currently :-( Additionally the calling functions expect pacrypt to "always work" - which was not a real problem up to now because it used only PHP-internal functions. c) if (strstr($CONF['encrypt'], 'dovecot:')) -> Please ensure that the $CONF parameter _begins_ with "dovecot:" - for example by using preg_match("/^dovecot:/", $CONF['encrypt']) Besides that, I like the idea of using "method:detail" - @GingerDog: This might also be an option for authlib / $CONF['authlib_default_flavour']. d) check/validate what becomes $method Even if $method comes from $CONF['encrypt'] , it may still contain an invalid value (like "dovecot:foobar") or evil characters ("dovecot:md5';rm -rf /"). There are several ways how this can be secured. I'll start with the best one. - check against an array of allowed password encryption methods. This is the most secure method, but has the disadvantage that it needs a code modification in case dovecot starts to support a new encryption method - check $method against a regular expression. preg_match("/[a-zA-Z0-9-]+/", $method) should do if I get the dovecot documentation right. - at least use escapeshellarg($method) if you really don't want to validate $method e) path to dovecotpw I'm quite sure "dovecotpw must be in $PATH" will cause some problems - for example the openSUSE package has dovecotpw in /usr/sbin - and therefore not in the webserver's $PATH. The only solution for this is a $CONF['dovecotpw'] = "/path/to/dovecotpw" parameter. (If this is not set or empty, you can still default to just "dovecotpw".) Maybe it can be included in $CONF['encrypt'] - something like "dovecot:MD5:/usr/sbin/dovecotpw" would work. However, things will become complicated when we add another 5 parameters to this string *g* BTW: Feel free to include the needed config.inc.php changes in your patch. The comment should mention the most common CRYPT-METHODs for dovecot. ---------------------------------------------------------------------- Comment By: cmuelle8 (trendypack) Date: 2009-02-25 17:07 Message: Absolutely, it works for me. Please make sure you add # dovecot:CRYPT-METHOD => use dovecotpw -s 'CRYPT-METHOD' (needs to be in PATH) or something more descriptive to config.inc.php though - the patch only modifies the functions file. Greetings, Christian ---------------------------------------------------------------------- Comment By: GingerDog (gingerdog) Date: 2009-02-24 21:33 Message: Christian - are you happy with this now? Can it be merged? ---------------------------------------------------------------------- Comment By: cmuelle8 (trendypack) Date: 2009-02-18 09:24 Message: File Added: postfixadmin.functions.patch ---------------------------------------------------------------------- Comment By: cmuelle8 (trendypack) Date: 2009-02-18 07:58 Message: alright, here's a revised patch.. hopefully this will do - as this is not the default in config.inc.php anyway, a note along the other encrypt methods will probably do: # dovecot:CRYPT-METHOD => use dovecotpw -s 'CRYPT-METHOD' (needs to be in PATH) best wishes, cmuelle8 (Christian Müller) File Added: postfixadmin.functions.patch ---------------------------------------------------------------------- Comment By: Christian Boltz (christian_boltz) Date: 2009-02-17 23:54 Message: Thanks for your patch! However, I see some problems with it: a) the password should be quoted/escaped/whatever before using it in the command line. You'll understand what I mean when somebody uses "topsecret ; rm -rf /" as his password *g* Hint: use escapeshellarg($pw) b) I don't really like that an external program is called with the password as parameter (which will be visilble for a short time in the process list). c) no error checking (what happens if dovecotpw is not installed or not in $PATH?) As you can see: things aren't that easy once you start calling external programs ;-) Unfortunately dovecotpw isn't easy to "emulate" in PHP, so calling dovecotpw might be the easiest option, even with the described disadvantages. For some information about "emulating" dovecotpw, see http://markmail.org/message/ug4mfvulgsajg3wk#query:dovecotpw%20php+page:1+mid:snbusk5sempgouyb+state:results http://www.scconsult.com/bill/crampass.pl http://www.dovecot.org/list/dovecot/2007-March/020889.html ---------------------------------------------------------------------- Comment By: cmuelle8 (trendypack) Date: 2009-02-17 02:02 Message: File Added: postfixadmin.functions.patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937966&aid=2607332&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2009-03-13 19:51:18
|
Feature Requests item #2214522, was opened at 2008-11-01 19:34 Message generated for change (Comment added) made by gingerdog You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937967&aid=2214522&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: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Christian Boltz (christian_boltz) Assigned to: Nobody/Anonymous (nobody) Summary: configuration in /etc/mail/postfixadmin for all scripts Initial Comment: Having to edit a script just to change a path or the database login details isn't the best solution. Instead, all scripts should have a configfile in /etc/mail/postfixadmin/ All scripts should still contain useful default values which are used if the config file doesn't exist. This affects: - vacation.pl (done) - postfixadmin-domain-postdeletion.sh, postfixadmin-mailbox-postcreation.sh, postfixadmin-mailbox-postdeletion.sh (basedir, trashbase, PATH) - fetchmail.pl I'm thinking about config.local.php as an exception - if we move it to /etc, the webserver needs read permissions there - which I'd like to avoid. (And it's not unusual for web apps to have a configfile in the same directory as all PHP files.) ---------------------------------------------------------------------- >Comment By: GingerDog (gingerdog) Date: 2009-03-13 19:51 Message: (The .deb Postfixadmin package already does put config.inc.php in /etc/postfixadmin and creates a symlink ... if my memory serves me correctly) ---------------------------------------------------------------------- Comment By: GingerDog (gingerdog) Date: 2008-11-03 08:40 Message: I'm fairly sure Debian has a /etc/squirrelmail (for example) that contains the actual .php script. They then have a symlink in e.g /usr/share/squirrelmail/ pointing to the file in /etc/ To me, this is the best option, as people tend to backup /etc with e.g. tar -zcf etc.tar.gz /etc and assume they've caught all config files. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937967&aid=2214522&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2009-03-13 19:50:19
|
Feature Requests item #2686461, was opened at 2009-03-13 19:49 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937967&aid=2686461&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: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: GingerDog (gingerdog) Assigned to: Nobody/Anonymous (nobody) Summary: Custom Fields support for mailbox table Initial Comment: See https://sourceforge.net/forum/message.php?msg_id=6779222 In brief: Add support for a number of fields to the mailbox table which will allow sysadmins to customise postfixadmin to their needs - e.g. to enable webmail or remote pop3/imap access access on a per user basis etc etc. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937967&aid=2686461&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2009-03-13 11:01:06
|
Patches item #2678293, was opened at 2009-03-10 06:44 Message generated for change (Comment added) made by libertytrek 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: Charles (libertytrek) Date: 2009-03-13 07:00 Message: @christian_boltz: if I were a programmer, I'd be happy to - and would have contributed other things long before now... but,you really don't want to see a patch from me... unless you have a really twisted sense of humor. ;) Also, sorry for the double-post, not sure how that happened... ---------------------------------------------------------------------- Comment By: Christian Boltz (christian_boltz) Date: 2009-03-12 18: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 07: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 07: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 07: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 06: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 04: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 18: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 05: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 07: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 07: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 |
|
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 |
|
From: SourceForge.net <no...@so...> - 2009-03-12 11:35:28
|
Patches item #2678293, was opened at 2009-03-10 11:44 Message generated for change (Comment added) made by fabiobon 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: 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 |
|
From: SourceForge.net <no...@so...> - 2009-03-12 11:20:47
|
Patches item #2678293, was opened at 2009-03-10 06:44 Message generated for change (Comment added) made by libertytrek 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: Charles (libertytrek) Date: 2009-03-12 07: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 07: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 06: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 04: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 18: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 05: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 07: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 07: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 |
|
From: SourceForge.net <no...@so...> - 2009-03-12 11:15:36
|
Patches item #2678293, was opened at 2009-03-10 06:44 Message generated for change (Comment added) made by libertytrek 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: Charles (libertytrek) Date: 2009-03-12 07: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 06: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 04: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 18: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 05: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 07: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 07: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 |
|
From: SourceForge.net <no...@so...> - 2009-03-12 10:07:00
|
Patches item #2678293, was opened at 2009-03-10 11:44 Message generated for change (Comment added) made by fabiobon 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: 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 |
|
From: SourceForge.net <no...@so...> - 2009-03-12 08:44:37
|
Feature Requests item #2684081, was opened at 2009-03-11 22:41 Message generated for change (Comment added) made by gingerdog You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937967&aid=2684081&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: Christian Boltz (christian_boltz) Assigned to: Nobody/Anonymous (nobody) Summary: one function for sending mail Initial Comment: from https://sourceforge.net/tracker2/?func=detail&atid=937964&aid=2682897&group_id=191583 I think there should be the only function for mail sending that can be used in broadcast-message.php, sendmail.php, create-mailbox.php. Also I think that base64 encoding of message body in broadcast-message.php isn't necessary - plain text would be better. ---------------------------------------------------------------------- >Comment By: GingerDog (gingerdog) Date: 2009-03-12 08:44 Message: I'd rather we used e.g. PEAR::Mail or Zend_Mail or SwiftMailer (delete/add as appropriate) and not try talking SMTP or deal with encoding issues. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937967&aid=2684081&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2009-03-12 08:42:09
|
Patches item #2678293, was opened at 2009-03-10 10:44 Message generated for change (Comment added) made by gingerdog 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: GingerDog (gingerdog) Date: 2009-03-12 08: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 22: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 09: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 11: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 11: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 |
|
From: SourceForge.net <no...@so...> - 2009-03-11 23:11:36
|
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-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 |
|
From: SourceForge.net <no...@so...> - 2009-03-11 22:42:15
|
Bugs item #2682897, was opened at 2009-03-11 15:42 Message generated for change (Settings changed) made by christian_boltz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=2682897&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: Languages Group: v 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Dystopian (dystopian) Assigned to: Nobody/Anonymous (nobody) Summary: Incorrect subject encoding in sendmail.php Initial Comment: If subject of a message is in Russian (I don't know about other languages) the function encode_header() works incorrectly, so subject in the inbox is broken. I checked in Thunderbird, Roundcube and Opera. I used standard php encoding function mb_encode_mimeheader() which is used in broadcast-message.php. Here's the patch: 47,48c47,48 < < $fHeaders .= "Subject: " . encode_header(safepost('fSubject')) . "\n"; --- > mb_internal_encoding("UTF-8"); > $fHeaders .= "Subject: " . mb_encode_mimeheader( safepost('fSubject'), 'UTF-8', 'Q') . "\n"; I think there should be the only function for mail sending that can be used in broadcast-message.php, sendmail.php, create-mailbox.php. Also I think that base64 encoding of message body in broadcast-message.php isn't necessary - plain text would be better. ---------------------------------------------------------------------- Comment By: Christian Boltz (christian_boltz) Date: 2009-03-11 23:41 Message: The encoding is fixed in SVN r573 - thanks for your report. I agree that sending mail could (and should) be handled in a common function - I opened https://sourceforge.net/tracker2/?func=detail&aid=2684081&group_id=191583&atid=937967 for it. ---------------------------------------------------------------------- Comment By: Dystopian (dystopian) Date: 2009-03-11 15:44 Message: File Added: bug.png ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=2682897&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2009-03-11 22:42:02
|
Bugs item #2682897, was opened at 2009-03-11 15:42 Message generated for change (Comment added) made by christian_boltz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=2682897&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: Languages Group: v 2.3 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Dystopian (dystopian) Assigned to: Nobody/Anonymous (nobody) Summary: Incorrect subject encoding in sendmail.php Initial Comment: If subject of a message is in Russian (I don't know about other languages) the function encode_header() works incorrectly, so subject in the inbox is broken. I checked in Thunderbird, Roundcube and Opera. I used standard php encoding function mb_encode_mimeheader() which is used in broadcast-message.php. Here's the patch: 47,48c47,48 < < $fHeaders .= "Subject: " . encode_header(safepost('fSubject')) . "\n"; --- > mb_internal_encoding("UTF-8"); > $fHeaders .= "Subject: " . mb_encode_mimeheader( safepost('fSubject'), 'UTF-8', 'Q') . "\n"; I think there should be the only function for mail sending that can be used in broadcast-message.php, sendmail.php, create-mailbox.php. Also I think that base64 encoding of message body in broadcast-message.php isn't necessary - plain text would be better. ---------------------------------------------------------------------- >Comment By: Christian Boltz (christian_boltz) Date: 2009-03-11 23:41 Message: The encoding is fixed in SVN r573 - thanks for your report. I agree that sending mail could (and should) be handled in a common function - I opened https://sourceforge.net/tracker2/?func=detail&aid=2684081&group_id=191583&atid=937967 for it. ---------------------------------------------------------------------- Comment By: Dystopian (dystopian) Date: 2009-03-11 15:44 Message: File Added: bug.png ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=2682897&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2009-03-11 22:41:43
|
Feature Requests item #2684081, was opened at 2009-03-11 23:41 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937967&aid=2684081&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: Christian Boltz (christian_boltz) Assigned to: Nobody/Anonymous (nobody) Summary: one function for sending mail Initial Comment: from https://sourceforge.net/tracker2/?func=detail&atid=937964&aid=2682897&group_id=191583 I think there should be the only function for mail sending that can be used in broadcast-message.php, sendmail.php, create-mailbox.php. Also I think that base64 encoding of message body in broadcast-message.php isn't necessary - plain text would be better. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937967&aid=2684081&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2009-03-11 14:45:09
|
Bugs item #2682897, was opened at 2009-03-11 17:42 Message generated for change (Comment added) made by dystopian You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=2682897&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: Languages Group: v 2.3 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Dystopian (dystopian) Assigned to: Nobody/Anonymous (nobody) Summary: Incorrect subject encoding in sendmail.php Initial Comment: If subject of a message is in Russian (I don't know about other languages) the function encode_header() works incorrectly, so subject in the inbox is broken. I checked in Thunderbird, Roundcube and Opera. I used standard php encoding function mb_encode_mimeheader() which is used in broadcast-message.php. Here's the patch: 47,48c47,48 < < $fHeaders .= "Subject: " . encode_header(safepost('fSubject')) . "\n"; --- > mb_internal_encoding("UTF-8"); > $fHeaders .= "Subject: " . mb_encode_mimeheader( safepost('fSubject'), 'UTF-8', 'Q') . "\n"; I think there should be the only function for mail sending that can be used in broadcast-message.php, sendmail.php, create-mailbox.php. Also I think that base64 encoding of message body in broadcast-message.php isn't necessary - plain text would be better. ---------------------------------------------------------------------- >Comment By: Dystopian (dystopian) Date: 2009-03-11 17:44 Message: File Added: bug.png ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=2682897&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2009-03-11 14:42:49
|
Bugs item #2682897, was opened at 2009-03-11 17:42 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=2682897&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: Languages Group: v 2.3 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Dystopian (dystopian) Assigned to: Nobody/Anonymous (nobody) Summary: Incorrect subject encoding in sendmail.php Initial Comment: If subject of a message is in Russian (I don't know about other languages) the function encode_header() works incorrectly, so subject in the inbox is broken. I checked in Thunderbird, Roundcube and Opera. I used standard php encoding function mb_encode_mimeheader() which is used in broadcast-message.php. Here's the patch: 47,48c47,48 < < $fHeaders .= "Subject: " . encode_header(safepost('fSubject')) . "\n"; --- > mb_internal_encoding("UTF-8"); > $fHeaders .= "Subject: " . mb_encode_mimeheader( safepost('fSubject'), 'UTF-8', 'Q') . "\n"; I think there should be the only function for mail sending that can be used in broadcast-message.php, sendmail.php, create-mailbox.php. Also I think that base64 encoding of message body in broadcast-message.php isn't necessary - plain text would be better. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=2682897&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2009-03-11 09:06:57
|
Patches item #2678293, was opened at 2009-03-10 11:44 Message generated for change (Comment added) made by fabiobon 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: 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 |
|
From: SourceForge.net <no...@so...> - 2009-03-10 12:11:12
|
Patches item #2678293, was opened at 2009-03-10 10:44 Message generated for change (Comment added) made by gingerdog 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: GingerDog (gingerdog) Date: 2009-03-10 11: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 11: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 |
|
From: SourceForge.net <no...@so...> - 2009-03-10 11:24:00
|
Patches item #2678293, was opened at 2009-03-10 10:44 Message generated for change (Comment added) made by gingerdog 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: GingerDog (gingerdog) Date: 2009-03-10 11: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 |
|
From: SourceForge.net <no...@so...> - 2009-03-10 10:44:45
|
Patches item #2678293, was opened at 2009-03-10 11:44 Message generated for change (Tracker Item Submitted) made by Item Submitter 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937966&aid=2678293&group_id=191583 |
700 messages has been excluded from this view by a project administrator.
