- Development - lists.drupal.org

[drupal-devel] Bug#316362: marked as done (security problem with drupal)
by owner＠bugs.debian.org 01 Jul '05

01 Jul '05

Your message dated Fri, 01 Jul 2005 12:02:27 -0400 with message-id <E1DoNyF-0001pM-00(a)newraff.debian.org> and subject line Bug#316362: fixed in drupal 4.5.4-1 has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) -------------------------------------- Received: (at submit) by bugs.debian.org; 30 Jun 2005 12:34:00 +0000 >From villain(a)ems.ru Thu Jun 30 05:34:00 2005 Return-path: <villain(a)ems.ru> Received: from router.ems.ru (relay-suttk.ems.ru) [62.165.34.129] by spohr.debian.org with esmtp (Exim 3.35 1 (Debian)) id 1DnyEy-0004zm-00; Thu, 30 Jun 2005 05:34:00 -0700 Received: from mail.ems.ru (localhost [127.0.0.1]) by mail.ems.ru (postfix) with ESMTP id 125C31AA68A for <submit(a)bugs.debian.org>; Thu, 30 Jun 2005 18:33:59 +0600 (YEKST) Received: from support.office.ems.chel.su (unknown [195.54.20.1]) by mail.ems.ru (postfix) with ESMTP for <submit(a)bugs.debian.org>; Thu, 30 Jun 2005 18:33:59 +0600 (YEKST) Received: by support.office.ems.chel.su (Postfix, from userid 1000) id C0EA22C56D; Thu, 30 Jun 2005 18:33:55 +0600 (YEKST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: Aleksey I Zavilohin <villain(a)ems.ru> To: Debian Bug Tracking System <submit(a)bugs.debian.org> Subject: security problem with drupal X-Mailer: reportbug 3.8 Date: Thu, 30 Jun 2005 18:33:55 +0600 Message-Id: <20050630123355.C0EA22C56D(a)support.office.ems.chel.su> X-Virus-Scanned: ClamAV using ClamSMTP Delivered-To: submit(a)bugs.debian.org X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02 (1.212-2003-09-23-exp) on spohr.debian.org X-Spam-Status: No, hits=-8.0 required=4.0 tests=BAYES_00,HAS_PACKAGE autolearn=no version=2.60-bugs.debian.org_2005_01_02 X-Spam-Level: Package: drupal Version: 4.5.3-2 Severity: grave Justification: user security hole See http://drupal.org/files/sa-2005-002/advisory.txt ---------------------------------------------------------------------------- Drupal security advisory DRUPAL-SA-2005-002 ---------------------------------------------------------------------------- Advisory ID: DRUPAL-SA-2005-002 Date: 2005-jun-29 Security risk: highly critical Impact: system access Where: from remote Vulnerability: arbitrary PHP code execution ---------------------------------------------------------------------------- Description ----------- Kuba Zygmunt discovered a flaw in the input validation routines of Drupal's filter mechanism. An attacker could execute arbitrary PHP code on a target site when public comments or postings are allowed. Versions affected ----------------- Drupal 4.5.0, 4.5.1, 4.5.2, 4.5.3 Drupal 4.6.0, 4.6.1 Solution -------- Either disable public comments and postings, or upgrade to the latest Drupal version: - If you cannot upgrade immediately, you can secure your site by disabling public postings and comments. Log in as an administrator, go to "administer >> access control" and make sure that untrusted roles don't have the permissions to submit or edit content. - If you are running Drupal 4.5.x, then upgrade to Drupal 4.5.4. - If you are running Drupal 4.6.x, then upgrade to Drupal 4.6.2. Contact ------- The security contact for Drupal can be reached at security(a)drupal.org or using the form at http://drupal.org/contact. -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.8-2-686 Locale: LANG=ru_RU.KOI8-R, LC_CTYPE=ru_RU.KOI8-R (charmap=KOI8-R) Versions of packages drupal depends on: ii apache 1.3.33-6 versatile, high-performance HTTP s ii debconf 1.4.30.13 Debian configuration management sy ii makepasswd 1.10-2 Generate and encrypt passwords ii mysql-client-4.1 [mysql-clie 4.1.11a-4 mysql database client binaries ii php4-cli 4:4.3.10-15 command-line interpreter for the p ii php4-mysql 4:4.3.10-15 MySQL module for php4 ii postfix [mail-transport-agen 2.1.5-9 A high-performance mail transport ii wwwconfig-common 0.0.43 Debian web auto configuration -- debconf information excluded --------------------------------------- Received: (at 316362-close) by bugs.debian.org; 1 Jul 2005 16:08:05 +0000 >From katie(a)ftp-master.debian.org Fri Jul 01 09:08:05 2005 Return-path: <katie(a)ftp-master.debian.org> Received: from newraff.debian.org [208.185.25.31] (mail) by spohr.debian.org with esmtp (Exim 3.35 1 (Debian)) id 1DoO3g-0006Tk-00; Fri, 01 Jul 2005 09:08:05 -0700 Received: from katie by newraff.debian.org with local (Exim 3.35 1 (Debian)) id 1DoNyF-0001pM-00; Fri, 01 Jul 2005 12:02:27 -0400 From: Hilko Bengen <bengen(a)debian.org> To: 316362-close(a)bugs.debian.org X-Katie: $Revision: 1.56 $ Subject: Bug#316362: fixed in drupal 4.5.4-1 Message-Id: <E1DoNyF-0001pM-00(a)newraff.debian.org> Sender: Archive Administrator <katie(a)ftp-master.debian.org> Date: Fri, 01 Jul 2005 12:02:27 -0400 Delivered-To: 316362-close(a)bugs.debian.org X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02 (1.212-2003-09-23-exp) on spohr.debian.org X-Spam-Status: No, hits=-6.0 required=4.0 tests=BAYES_00,HAS_BUG_NUMBER autolearn=no version=2.60-bugs.debian.org_2005_01_02 X-Spam-Level: Source: drupal Source-Version: 4.5.4-1 We believe that the bug you reported is fixed in the latest version of drupal, which is due to be installed in the Debian FTP archive: drupal_4.5.4-1.diff.gz to pool/main/d/drupal/drupal_4.5.4-1.diff.gz drupal_4.5.4-1.dsc to pool/main/d/drupal/drupal_4.5.4-1.dsc drupal_4.5.4-1_all.deb to pool/main/d/drupal/drupal_4.5.4-1_all.deb drupal_4.5.4.orig.tar.gz to pool/main/d/drupal/drupal_4.5.4.orig.tar.gz A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 316362(a)bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Hilko Bengen <bengen(a)debian.org> (supplier of updated drupal package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmaster(a)debian.org) -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Format: 1.7 Date: Fri, 1 Jul 2005 17:27:59 +0200 Source: drupal Binary: drupal Architecture: source all Version: 4.5.4-1 Distribution: unstable Urgency: high Maintainer: Hilko Bengen <bengen(a)debian.org> Changed-By: Hilko Bengen <bengen(a)debian.org> Description: drupal - fully-featured content management/discussion engine Closes: 313449 313702 315869 316362 Changes: drupal (4.5.4-1) unstable; urgency=HIGH . * New upstream version (Closes: #316362) - Fixes two serious security bugs (see http://drupal.org/files/sa-2005-002/advisory.txt and http://drupal.org/files/sa-2005-003/advisory.txt) * README.Debian now mentions that the site-wide configuration files are to be found in /etc/drupal (Closes: #313449) * [Jens Seidel <jensseidel(a)users.sf.net>] Corrected minor typos in German Debconf translation (Closes: #313702) * [Miroslav Kure <kurem(a)upcase.inf.upol.cz>] Added Czech Debconf translation (Closes: #315869) Files: a8c9a11230369f6fad46e91b8b1d4306 609 web extra drupal_4.5.4-1.dsc 53f8c8a65a02b5328945d6bade47691c 472270 web extra drupal_4.5.4.orig.tar.gz 70a127c9abf132e95c93fe3776e7828c 42560 web extra drupal_4.5.4-1.diff.gz 4578b3442f901b012409d1e5a72b1206 488206 web extra drupal_4.5.4-1_all.deb -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFCxWeSUCgnLz/SlGgRArJBAKDWDC56uEeIWdb8E5fFJhTl6gLvlQCeL3HC 4Rz2eHTwqaMKSP6e0RPxMm4= =WEB1 -----END PGP SIGNATURE-----

1 0

[drupal-devel] Wordpress' new "post edit screen"
by Dries Buytaert 01 Jul '05

01 Jul '05

The next version of WordPress, WP 1.6, will have the following "post edit screen": http://asymptomatic.net/wp/images/2005/June/wp16.gif (animated) http://asymptomatic.net/wp/images/2005/June/wp16write.jpg -- Dries Buytaert :: http://www.buytaert.net/

8 11

[drupal-devel] [bug] The anonymous user account can be edited
by Chris Johnson 01 Jul '05

01 Jul '05

Issue status update for http://drupal.org/node/25605 Project: Drupal Version: 4.6.1 Component: user system Category: bug reports Priority: critical Assigned to: Robin Monks Reported by: nysus Updated by: Chris Johnson Status: patch I've always thought that the administrator should be able to edit uid == 0 (the anonymous user) and that ALL of drupal should use the username provided by the administrator in that record as the name of the anonymous user to display (with a default to t('anonymous')). Likewise for anything else about the anonymous user that might ever be displayed. Handling of the anonymous user has been schizophrenic. I patched it once, but then development moved things around in the 'variable' usage of anonymous so much that my patch no longer applied and making it work again would have taken a large amount of work, so I never re-developed it. But it's still the right way to do it: http://drupal.org/node/5639 Chris Johnson Previous comments: ------------------------------------------------------------------------ June 23, 2005 - 07:06 : nysus Any user, anonymous or otherwise, can go to /user/0/edit and edit the account of the anonymous user. ------------------------------------------------------------------------ June 24, 2005 - 05:20 : Robin Monks I'll take care of this one :-) CONFIRMED on WinXP/Xitami CVS Robin ------------------------------------------------------------------------ June 24, 2005 - 05:41 : Robin Monks Attachment: http://drupal.org/files/issues/annon.user.edit.fix (1.92 KB) Here is the patch. It removes the /edit and /delete operation from user 0. Tested to work on CVS HEAD. Robin ------------------------------------------------------------------------ June 24, 2005 - 10:32 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/user-edit-fix.patch (999 bytes) The patch didn't apply on head. I also like my solution better. ;) ------------------------------------------------------------------------ June 27, 2005 - 13:17 : Dries killes: your patch looks broken. Shouldn't $user->uid be arg(1)? ------------------------------------------------------------------------ June 27, 2005 - 13:31 : killes(a)www.drop.org One of us is confused, but who? I don't think that $user->uid has to be == arg(1). it is a global var. ------------------------------------------------------------------------ June 28, 2005 - 05:31 : Robin Monks Anyways, my patch still applies (chx had concerns earlier, but the patch was made correctly and seems to be OK). And it's been tested to work. I also like the fact that mine covers the entire user, and not just the edit portion. Robin ------------------------------------------------------------------------ June 30, 2005 - 22:39 : mfb With killes' patch I was still able to fill out the edit form at user/0/edit , user/0./edit or user/0.0/edit to create a new user. +1 for Robin's patch, which needs to be converted from DOS to UNIX format. ------------------------------------------------------------------------ July 1, 2005 - 05:25 : Jose A Reyero Attachment: http://drupal.org/files/issues/user_anonymous_noedit.patch (701 bytes) I've tried both patches, both seem to apply, both work, with the only difference that Killes's still allows Administrator to edit anonymous account. But both patches fail to protect custom profile fields (If you create custom profile fields, any user still can access categories of profile fields for user 0). So I propose this one, which removes all operations for user 0.

1 0

[drupal-devel] [bug] Bootstrap patch fixes
by walkah 01 Jul '05

01 Jul '05

Issue status update for http://drupal.org/node/25600 Project: Drupal Version: cvs Component: base system Category: bug reports Priority: critical Assigned to: chx Reported by: kubaZygmunt Updated by: walkah Status: patch just to follow up.. chx's patch in #7 only fixes XMLRPC servers... anything that uses XML-RPC client (i.e. drupal_auth or ping) will still be busted. walkah Previous comments: ------------------------------------------------------------------------ June 23, 2005 - 06:28 : kubaZygmunt Attachment: http://drupal.org/files/issues/bootstrap.diff (422 bytes) I've found that new cvs version doesn't get properly db_prefix. In bootstrap.inc (function _drupal_bootstrap($phase) ) I added another global variable $db_prefix, and then it goes . I don't know if my solution is good because on my local site I can't see any blocks and on my internet site I have some caching and I can't see anything :) ------------------------------------------------------------------------ June 23, 2005 - 07:45 : kubaZygmunt Above I've put my patch ------------------------------------------------------------------------ June 23, 2005 - 07:56 : Jaza Attachment: http://drupal.org/files/issues/db_prefix_global.patch (582 bytes) Also noticed this bug, when trying to install a fresh CVS snapshot. Attached is my patch against CVS HEAD (same as kubaZygmunt's, basically). ------------------------------------------------------------------------ June 23, 2005 - 08:10 : chx Yes, this is a bug, if you look at the bootstrap patch, there were versions when I thought variables in settings.php should be written as $GLOBALS['something'] but then introduced global $something . Forgot when that something is db_prefix . ------------------------------------------------------------------------ June 28, 2005 - 00:26 : Jaza Can this patch be applied to HEAD please? This is not something that should be left sitting around in the issues list. Chx has identified that it was a simple honest mistake on his part, and has indicated that the submitted patch(es) will fix the mistake. Until this patch is applied, anyone who tries to install HEAD using db prefixes will get a fatal error. It doesn't get much more critical than that :-p. ------------------------------------------------------------------------ June 30, 2005 - 09:56 : Bart Jansens Attachment: http://drupal.org/files/issues/20050630.bootstrap-prefix-update.patch (1.21 KB) There is another related problem, it is no longer possible to override variables in settings.php. And update.php no longer works. Updated patch attached. ------------------------------------------------------------------------ June 30, 2005 - 10:04 : chx Attachment: http://drupal.org/files/issues/20050630.bootstrap-patch.patch (2.92 KB) Oh, and XML-RPC client is broken too. I talked with walkah and we found it the best to move xmlrpc.inc to modules which use them. ------------------------------------------------------------------------ June 30, 2005 - 10:09 : chx Attachment: http://drupal.org/files/issues/20050630.1.bootstrap-patch.patch (3.34 KB) some more xml-rpc fixes. ------------------------------------------------------------------------ June 30, 2005 - 10:20 : Steven Making XML-RPC a conditional include was discussed a while ago, and decided against due to problems with the class persistency. Why is this now possible? ------------------------------------------------------------------------ June 30, 2005 - 12:36 : walkah basically - it's not. the problem is, well, the xmlrpc.inc is not very well written. It requires / depends on several global variables, etc. which leads to a fair bit of the scoping issues. If you look at what PEAR has done with this (since their XML-RPC module is based on the same original code)... you'll notice lots of $GLOBALS['...'] usage (see http://cvs.php.net/co.php/pear/XML_RPC/RPC.php) . Basically, I think we have 3 options: 1) keep banging on this old code to make it work. 2) switch libraries to either PEAR::XML-RPC or something like incutio's (http://scripts.incutio.com/xmlrpc/) 3) re-write our own custom xml-rpc library personally, I'd +1 #2 - since #1 is ugly, and #3 I personally don't have time for, and I'd rather see our developer resources going to more interesting things. that said, i know there are those with strong feelings against 3rd party libraries... but this needs to get fixed quickly. blogapi and drupal dist_auth are both currently broken in HEAD. (isn't there anyone else here that tests XML-RPC stuff??)

8 12

[drupal-devel] [bug] don't show blocks if they have no content
by Jose A Reyero 01 Jul '05

01 Jul '05

Issue status update for http://drupal.org/node/7897 Project: Drupal Version: cvs Component: base system Category: bug reports Priority: normal Assigned to: Robin Monks Reported by: ax Updated by: Jose A Reyero Status: patch +1 Tried the patch, it works Jose A Reyero Previous comments: ------------------------------------------------------------------------ May 19, 2004 - 19:06 : ax Attachment: http://drupal.org/files/issues/no.blocks.without.content.patch (5.06 KB) blog, forum, and statistics.module show their blocks even if they have no contents. this looks quite dull, eg. +----------------------+ | Forum topics | | | | Active forum topics: | | | | New forum topics: | | | | more | +----------------------+ +----------------------+ | Popular content | | | | Today's: | | | | All time: | | | | Last viewed: | | | +----------------------+ and isn't what the rest of the drupal blocks do (not showing up if there is no content). this patch fixes this. additional improvements: * removed the "more" links from blog and forum.module and replaced them with block titles linking to the respective module page. rationales: + "more" means there are more blog entries/forum topics than those linked from the blocks. this, however, wasn't always the case. + it is common user expectation that the title of a "content excerpt" links to the complete content. examples: node titles on the homepage, links in admin tables, tracker, etc. + it saves screen estate * fixed the forum link description ('Read the latest forum topics.' > 'Go to the forums.') * added a link from the 'Popular content' block title to the 'Most popular content' page (statistics). this wasn't accessible before. please review and apply. ------------------------------------------------------------------------ May 20, 2004 - 15:23 : Dries I haven't tested the patch yet but it would be nice if more block titles were links (eg. the title of the archive block could link to the main archive page). ------------------------------------------------------------------------ May 31, 2004 - 23:24 : ax want me to make all block titles link to the respective module page? ------------------------------------------------------------------------ June 2, 2004 - 19:56 : Dries I'd like to discuss this at the very least. :-) ------------------------------------------------------------------------ June 2, 2004 - 20:47 : Boris Mann I don't want clickable block titles! This is a theming issue, and I don't think it should be in by default. What is wrong with the "more" link? Empty blocks not displaying content (i.e. block doesn't show at all) is OK for some blocks, not OK for others. This would ideally be a configuration option: "display even if empty" and a checkbox. I've always wanted "Active" and "New" forum topics a) either split into two blocks or b) made it configurable to display one or the other or both. ------------------------------------------------------------------------ June 2, 2004 - 20:51 : Goba Targets for block title links could be provided by modules, but it is after all the decision of modules to print out block titles using those links. ------------------------------------------------------------------------ June 3, 2004 - 12:26 : Kjartan Once upon a time blocks defind a link along with the subject and content. I think we should re-introduce it, and have it replace the more link that some blocks add. This way themes can choose how and where they put the link (title, text, icon, etc). ------------------------------------------------------------------------ June 3, 2004 - 13:53 : moshe weitzman we already pass the 'more' link separate from the content. this is about how the core themes should present that 'more' link ------------------------------------------------------------------------ June 3, 2004 - 13:58 : Kjartan >From my quick look at blocks in HEAD this is not true for the aggregator or blog blocks, they have specific div & CSS class around them yes, but they are not 100% controlable in the theme. ------------------------------------------------------------------------ June 3, 2004 - 18:18 : Boris Mann " Once upon a time blocks defind a link along with the subject and content. I think we should re-introduce it, and have it replace the more link that some blocks add. This way themes can choose how and where they put the link (title, text, icon, etc). " +10!! Yes, make more block stuff themeable. This is a great solution, since you could also add a "link" field to custom blocks that would display in the same way. Ideally, both the text (e.g. "more", "check this out", "extra stuff", etc. etc.) and the link would be configurable, and the theme would take care of how this is displayed. ------------------------------------------------------------------------ June 17, 2004 - 19:52 : Dries I'm marking this patch 'active' as we agreed to disagree with the suggested patch/approach. Please resubmit or split your patch in smaller chunks. Thanks. ------------------------------------------------------------------------ June 13, 2005 - 13:28 : Robin Monks Attachment: http://drupal.org/files/issues/no.block.display.on.no.content.patch (3 KB) This patch fixes the actual goal of the bug "don't show blocks if they have no content". This is basically ax's patch broken up and updated to HEAD. This patches forum.module and stats. It's been tested to work on CVS HEAD. I'll take responsibility for upcoming changes to this patch. Robin ------------------------------------------------------------------------ June 13, 2005 - 13:55 : Robin Monks Attachment: http://drupal.org/files/issues/no.block.display.on.no.content_0.patch (3.16 KB) Chx recommended moving the returns into their relative ifs. This also works on HEAD. Robin ------------------------------------------------------------------------ June 13, 2005 - 13:57 : Robin Monks Attachment: http://drupal.org/files/issues/no.block.display.on.no.content_1.patch (3.17 KB) ...wrong patch version... Robin ------------------------------------------------------------------------ July 1, 2005 - 08:51 : mfb Looks good, +1

1 0

[drupal-devel] [bug] request_uri() broken if in subdir
by killes 01 Jul '05

01 Jul '05

Issue status update for http://drupal.org/node/10917 Project: Drupal Version: cvs Component: base system Category: bug reports Priority: normal Assigned to: Robin Monks Reported by: killes(a)www.drop.org Updated by: killes(a)www.drop.org Status: patch Another manifestation of this bug: http://drupal.org/node/26163 killes(a)www.drop.org Previous comments: ------------------------------------------------------------------------ September 17, 2004 - 21:05 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/requi.patch (678 bytes) We asumme the $_SERVER[REQUEST_URI] would contain only the url from the point of Drupal's directory on. This is true only iff you run from the root of your site. If you are in a subdir, the function request_uri() will be unusable if we want to construct a valid url from $base_url and request_uri() (what we do in a number of places). The attached patch fixes this by using basename(). ------------------------------------------------------------------------ September 17, 2004 - 21:45 : killes(a)www.drop.org The patch doesn't suffice if your access only the base_url of your Drupal site in a subdir. Putting on hold. ------------------------------------------------------------------------ September 17, 2004 - 23:39 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/request.patch (761 bytes) ok, I think I got it. The distinction between apache and non-apache servers went away to keep it simple. ------------------------------------------------------------------------ September 18, 2004 - 02:19 : killes(a)www.drop.org Apparently the action in forms depends on the bug that I found, ie it needs request_uri to contain the full url (from documentroot on). ------------------------------------------------------------------------ September 18, 2004 - 02:53 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/request_0.patch (2.46 KB) This new patch fixes the problem with forms. request_uri() also does not start with a leading slash anymore. Ask Steven for why this is good. http://acko.net/dumpx/relative.html is apparently a clue I don't get. ------------------------------------------------------------------------ September 18, 2004 - 03:04 : Steven Explanation: People are going to stick relative_uri() into links. These links are resolved relative to the $base_url which is put into the <head> tag. However, if a link URI starts with a / then it is relative to the root of the site, even if the base tag uses a path with a subdirectory. Example: <html> <base href="http://www.test.com/subdir1/"> <body> test [1] test [2] </body> </html> The first link resolves to http://www.test.com/subdir2, the second resolves to http://www.test.com/subdir1/subdir2. Thus, it is more meaningful to not have a leading slash, as this will avoid possible bugs with subdirs (which often do not get caught because the tester uses a site without a subdir) and hints at the callee that this is a relative URI too. [1] http://drupal.org//subdir2 [2] http://drupal.org/subdir2 ------------------------------------------------------------------------ March 13, 2005 - 20:38 : Chris Johnson Patch no longer applies completely to bootstrap.inc: Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |Index: includes/bootstrap.inc |=================================================================== |RCS file: /cvs/drupal/drupal/includes/bootstrap.inc,v |retrieving revision 1.28 |diff -u -F^f -r1.28 bootstrap.inc |--- includes/bootstrap.inc 16 Sep 2004 07:17:54 -0000 1.28 |+++ includes/bootstrap.inc 18 Sep 2004 00:52:12 -0000 -------------------------- Patching file bootstrap.inc using Plan A... Hunk #1 succeeded at 273 (offset 83 lines). Hunk #2 succeeded at 292 (offset 83 lines). Hunk #3 failed at 446. 1 out of 3 hunks failed--saving rejects to bootstrap.inc.rej Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |Index: includes/common.inc |=================================================================== |RCS file: /cvs/drupal/drupal/includes/common.inc,v |retrieving revision 1.390 |diff -u -F^f -r1.390 common.inc |--- includes/common.inc 16 Sep 2004 16:12:21 -0000 1.390 |+++ includes/common.inc 18 Sep 2004 00:52:12 -0000 -------------------------- Patching file common.inc using Plan A... Hunk #1 succeeded at 988 (offset -90 lines). done ------------------------------------------------------------------------ June 14, 2005 - 13:21 : Robin Monks Attachment: http://drupal.org/files/issues/request_uri.broken.if.in.subdir.patch (2.6 KB) Here is that patch re-rolled for latest CVS HEAD. Since killes hasn't been active in this bug lately, I hope he won't mind my reassigning this to myself. Robin ------------------------------------------------------------------------ June 14, 2005 - 13:22 : Robin Monks I've also tested this to work on CVS HEAD. Robin ------------------------------------------------------------------------ June 14, 2005 - 15:33 : moshe weitzman did you test this on non apache servers? the comment that you removed is crystal clear about a need for 2 different cases. it is OK to 'make it simpler' as long as you don't remove compatibility with other web servers. I am primarily concerned with IIS. ------------------------------------------------------------------------ June 14, 2005 - 16:42 : Robin Monks I took great care to ensure I didn't remove any support needed for other servers. I also tested this patch to work on Xitami on Win32. Robin ------------------------------------------------------------------------ June 14, 2005 - 19:09 : Robin Monks I spent some more time testing, and this broke some (perhaps all) configuration forms. It appears the / is needed after all. Perhaps killes will have better luck understanding this, the / is needed IMHO. Robin

1 0

[drupal-devel] [bug] Statistic information about node reads is shown to unprivileged users
by Jose A Reyero 01 Jul '05

01 Jul '05

Issue status update for http://drupal.org/node/22565 Project: Drupal Version: cvs Component: statistics.module Category: bug reports Priority: normal Assigned to: Robin Monks Reported by: massabob Updated by: Jose A Reyero Status: patch +1 I tested the patch, works fine, and I'm always for "more options" ;-) Jose A Reyero Previous comments: ------------------------------------------------------------------------ May 11, 2005 - 08:51 : massabob Information about '%count reads' in node's footer is shown to unprivileged users. I suggest that function statistics_link in statistics.module should be corrected in this way: // Original function statistics_link($type, $node = 0, $main = 0) { global $id; $links = array(); if ($type != 'comment' && variable_get('statistics_display_counter', 0)) { $statistics = statistics_get($node->nid); if ($statistics) { $links[] = format_plural($statistics['totalcount'], '1 read', '%count reads'); } } return $links; } // Fixed function statistics_link($type, $node = 0, $main = 0) { global $id; $links = array(); if ($type != 'comment' && variable_get('statistics_display_counter', 0) && user_access('display statistics')) { $statistics = statistics_get($node->nid); if ($statistics) { $links[] = format_plural($statistics['totalcount'], '1 read', '%count reads'); } } return $links; } The only change is in "&& user_access('display statistics')" on line 98. ------------------------------------------------------------------------ May 27, 2005 - 02:44 : RobRoy Should read user_access('access statistics') not user_access('display statistics'). ------------------------------------------------------------------------ May 27, 2005 - 12:19 : Robin Monks Attachment: http://drupal.org/files/issues/user.access.stats.patch (730 bytes) And here that is in patch form. Robin ------------------------------------------------------------------------ June 1, 2005 - 05:09 : Steven I'm not sure about this patch: often, read counts are shown directly on the site. But if the permission for viewing the counts is the same as the permission for accessing the administrator's detailed logs, then you wouldn't give that to everyone. There is already an option to choose whether counts are displayed. Perhaps we could change that to "No" "For priviledged users" "For everyone". In last case it acts like it is now, it the second case it requires "access statistics" permission. What do you think? ------------------------------------------------------------------------ June 1, 2005 - 15:13 : Robin Monks Sounds good to me. I'll try to code something up for this. Robin ------------------------------------------------------------------------ June 9, 2005 - 14:55 : Robin Monks Attachment: http://drupal.org/files/issues/authstats.patch (2.26 KB) Here is the patch. Uses a switch to choose between signed in users, all users, users with permissions or noone. Robin ------------------------------------------------------------------------ June 9, 2005 - 15:08 : Robin Monks I tested this patch with various settings on my local install and it worked fine. Robin ------------------------------------------------------------------------ June 9, 2005 - 17:30 : Bèr Kessels Is there a reason why you check for $user->uid? Whaen someone has "access statistics" set to anonymous users, your check for $user->uid will override taht settings. Not good IMO. <?php $group .= form_radios(t('Display counter values'), 'statistics_display_counter', variable_get('statistics_display_counter', 0), array('1' => t('For all users'), '2' => t('For authenticated users'), '3' => t('For priviledged users'), '0' => t('Disabled')), t('Display how many times given content has been viewed.')); ?> is very inconsistent. please use *only* the permissions page to set permissions, and do not create new permissions-alike settings in any configuration pages. I would say a simple check for user_access('access statistics') will do the trick ------------------------------------------------------------------------ June 9, 2005 - 17:32 : Bèr Kessels sorry, i meant to say user_access('access statistics counter'), not user_access('access statistics'). We already have "access statistics'" an additional "access statistics counter" for showing users the counter should work Ber ------------------------------------------------------------------------ June 9, 2005 - 17:49 : Robin Monks Attachment: http://drupal.org/files/issues/statistics.module (23.1 KB) OK, here is a patch to that end... Robin ------------------------------------------------------------------------ June 9, 2005 - 18:00 : Robin Monks Attachment: http://drupal.org/files/issues/authstats_0.patch (1 KB) Um, let's just pretend I didn't just upload the entire stats module. OK? OK! Robin ------------------------------------------------------------------------ June 9, 2005 - 18:05 : Robin Monks Attachment: http://drupal.org/files/issues/authstats_1.patch (1.06 KB) Hotfix. Robin ------------------------------------------------------------------------ June 9, 2005 - 18:11 : Robin Monks Attachment: http://drupal.org/files/issues/authstats_2.patch (1.11 KB) Hopefuly the final version. Thanks to chx and berkes for pulling it apart ;-) Robin ------------------------------------------------------------------------ June 9, 2005 - 18:21 : Bèr Kessels +1 for this patch. it adds functionality, but does not add clutter nor any config options. ------------------------------------------------------------------------ June 10, 2005 - 03:39 : frjo +1 I have implemented the patch authstats_2.patch on my site running Drupal 4.6.1 and it works well. ------------------------------------------------------------------------ July 1, 2005 - 09:10 : mfb +1

1 0

[drupal-devel] [bug] The anonymous user account can be edited
by Jose A Reyero 01 Jul '05

01 Jul '05

Issue status update for http://drupal.org/node/25605 Project: Drupal Version: 4.6.1 Component: user system Category: bug reports Priority: critical Assigned to: Robin Monks Reported by: nysus Updated by: Jose A Reyero Status: patch Attachment: http://drupal.org/files/issues/user_anonymous_noedit.patch (701 bytes) I've tried both patches, both seem to apply, both work, with the only difference that Killes's still allows Administrator to edit anonymous account. But both patches fail to protect custom profile fields (If you create custom profile fields, any user still can access categories of profile fields for user 0). So I propose this one, which removes all operations for user 0. Jose A Reyero Previous comments: ------------------------------------------------------------------------ June 23, 2005 - 14:06 : nysus Any user, anonymous or otherwise, can go to /user/0/edit and edit the account of the anonymous user. ------------------------------------------------------------------------ June 24, 2005 - 12:20 : Robin Monks I'll take care of this one :-) CONFIRMED on WinXP/Xitami CVS Robin ------------------------------------------------------------------------ June 24, 2005 - 12:41 : Robin Monks Attachment: http://drupal.org/files/issues/annon.user.edit.fix (1.92 KB) Here is the patch. It removes the /edit and /delete operation from user 0. Tested to work on CVS HEAD. Robin ------------------------------------------------------------------------ June 24, 2005 - 17:32 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/user-edit-fix.patch (999 bytes) The patch didn't apply on head. I also like my solution better. ;) ------------------------------------------------------------------------ June 27, 2005 - 20:17 : Dries killes: your patch looks broken. Shouldn't $user->uid be arg(1)? ------------------------------------------------------------------------ June 27, 2005 - 20:31 : killes(a)www.drop.org One of us is confused, but who? I don't think that $user->uid has to be == arg(1). it is a global var. ------------------------------------------------------------------------ June 28, 2005 - 12:31 : Robin Monks Anyways, my patch still applies (chx had concerns earlier, but the patch was made correctly and seems to be OK). And it's been tested to work. I also like the fact that mine covers the entire user, and not just the edit portion. Robin ------------------------------------------------------------------------ July 1, 2005 - 05:39 : mfb With killes' patch I was still able to fill out the edit form at user/0/edit , user/0./edit or user/0.0/edit to create a new user. +1 for Robin's patch, which needs to be converted from DOS to UNIX format.

1 0

[drupal-devel] [bug] Statistic information about node reads is shown to unprivileged users
by mfb 01 Jul '05

01 Jul '05

Issue status update for http://drupal.org/node/22565 Project: Drupal Version: cvs Component: statistics.module Category: bug reports Priority: normal Assigned to: Robin Monks Reported by: massabob Updated by: mfb Status: patch +1 mfb Previous comments: ------------------------------------------------------------------------ May 11, 2005 - 00:51 : massabob Information about '%count reads' in node's footer is shown to unprivileged users. I suggest that function statistics_link in statistics.module should be corrected in this way: // Original function statistics_link($type, $node = 0, $main = 0) { global $id; $links = array(); if ($type != 'comment' && variable_get('statistics_display_counter', 0)) { $statistics = statistics_get($node->nid); if ($statistics) { $links[] = format_plural($statistics['totalcount'], '1 read', '%count reads'); } } return $links; } // Fixed function statistics_link($type, $node = 0, $main = 0) { global $id; $links = array(); if ($type != 'comment' && variable_get('statistics_display_counter', 0) && user_access('display statistics')) { $statistics = statistics_get($node->nid); if ($statistics) { $links[] = format_plural($statistics['totalcount'], '1 read', '%count reads'); } } return $links; } The only change is in "&& user_access('display statistics')" on line 98. ------------------------------------------------------------------------ May 26, 2005 - 18:44 : RobRoy Should read user_access('access statistics') not user_access('display statistics'). ------------------------------------------------------------------------ May 27, 2005 - 04:19 : Robin Monks Attachment: http://drupal.org/files/issues/user.access.stats.patch (730 bytes) And here that is in patch form. Robin ------------------------------------------------------------------------ May 31, 2005 - 21:09 : Steven I'm not sure about this patch: often, read counts are shown directly on the site. But if the permission for viewing the counts is the same as the permission for accessing the administrator's detailed logs, then you wouldn't give that to everyone. There is already an option to choose whether counts are displayed. Perhaps we could change that to "No" "For priviledged users" "For everyone". In last case it acts like it is now, it the second case it requires "access statistics" permission. What do you think? ------------------------------------------------------------------------ June 1, 2005 - 07:13 : Robin Monks Sounds good to me. I'll try to code something up for this. Robin ------------------------------------------------------------------------ June 9, 2005 - 06:55 : Robin Monks Attachment: http://drupal.org/files/issues/authstats.patch (2.26 KB) Here is the patch. Uses a switch to choose between signed in users, all users, users with permissions or noone. Robin ------------------------------------------------------------------------ June 9, 2005 - 07:08 : Robin Monks I tested this patch with various settings on my local install and it worked fine. Robin ------------------------------------------------------------------------ June 9, 2005 - 09:30 : Bèr Kessels Is there a reason why you check for $user->uid? Whaen someone has "access statistics" set to anonymous users, your check for $user->uid will override taht settings. Not good IMO. <?php $group .= form_radios(t('Display counter values'), 'statistics_display_counter', variable_get('statistics_display_counter', 0), array('1' => t('For all users'), '2' => t('For authenticated users'), '3' => t('For priviledged users'), '0' => t('Disabled')), t('Display how many times given content has been viewed.')); ?> is very inconsistent. please use *only* the permissions page to set permissions, and do not create new permissions-alike settings in any configuration pages. I would say a simple check for user_access('access statistics') will do the trick ------------------------------------------------------------------------ June 9, 2005 - 09:32 : Bèr Kessels sorry, i meant to say user_access('access statistics counter'), not user_access('access statistics'). We already have "access statistics'" an additional "access statistics counter" for showing users the counter should work Ber ------------------------------------------------------------------------ June 9, 2005 - 09:49 : Robin Monks Attachment: http://drupal.org/files/issues/statistics.module (23.1 KB) OK, here is a patch to that end... Robin ------------------------------------------------------------------------ June 9, 2005 - 10:00 : Robin Monks Attachment: http://drupal.org/files/issues/authstats_0.patch (1 KB) Um, let's just pretend I didn't just upload the entire stats module. OK? OK! Robin ------------------------------------------------------------------------ June 9, 2005 - 10:05 : Robin Monks Attachment: http://drupal.org/files/issues/authstats_1.patch (1.06 KB) Hotfix. Robin ------------------------------------------------------------------------ June 9, 2005 - 10:11 : Robin Monks Attachment: http://drupal.org/files/issues/authstats_2.patch (1.11 KB) Hopefuly the final version. Thanks to chx and berkes for pulling it apart ;-) Robin ------------------------------------------------------------------------ June 9, 2005 - 10:21 : Bèr Kessels +1 for this patch. it adds functionality, but does not add clutter nor any config options. ------------------------------------------------------------------------ June 9, 2005 - 19:39 : frjo +1 I have implemented the patch authstats_2.patch on my site running Drupal 4.6.1 and it works well.

1 0

[drupal-devel] [bug] don't show blocks if they have no content
by mfb 01 Jul '05

01 Jul '05

Issue status update for http://drupal.org/node/7897 Project: Drupal Version: cvs Component: base system Category: bug reports Priority: normal Assigned to: Robin Monks Reported by: ax Updated by: mfb Status: patch Looks good, +1 mfb Previous comments: ------------------------------------------------------------------------ May 19, 2004 - 11:06 : ax Attachment: http://drupal.org/files/issues/no.blocks.without.content.patch (5.06 KB) blog, forum, and statistics.module show their blocks even if they have no contents. this looks quite dull, eg. +----------------------+ | Forum topics | | | | Active forum topics: | | | | New forum topics: | | | | more | +----------------------+ +----------------------+ | Popular content | | | | Today's: | | | | All time: | | | | Last viewed: | | | +----------------------+ and isn't what the rest of the drupal blocks do (not showing up if there is no content). this patch fixes this. additional improvements: * removed the "more" links from blog and forum.module and replaced them with block titles linking to the respective module page. rationales: + "more" means there are more blog entries/forum topics than those linked from the blocks. this, however, wasn't always the case. + it is common user expectation that the title of a "content excerpt" links to the complete content. examples: node titles on the homepage, links in admin tables, tracker, etc. + it saves screen estate * fixed the forum link description ('Read the latest forum topics.' > 'Go to the forums.') * added a link from the 'Popular content' block title to the 'Most popular content' page (statistics). this wasn't accessible before. please review and apply. ------------------------------------------------------------------------ May 20, 2004 - 07:23 : Dries I haven't tested the patch yet but it would be nice if more block titles were links (eg. the title of the archive block could link to the main archive page). ------------------------------------------------------------------------ May 31, 2004 - 15:24 : ax want me to make all block titles link to the respective module page? ------------------------------------------------------------------------ June 2, 2004 - 11:56 : Dries I'd like to discuss this at the very least. :-) ------------------------------------------------------------------------ June 2, 2004 - 12:47 : Boris Mann I don't want clickable block titles! This is a theming issue, and I don't think it should be in by default. What is wrong with the "more" link? Empty blocks not displaying content (i.e. block doesn't show at all) is OK for some blocks, not OK for others. This would ideally be a configuration option: "display even if empty" and a checkbox. I've always wanted "Active" and "New" forum topics a) either split into two blocks or b) made it configurable to display one or the other or both. ------------------------------------------------------------------------ June 2, 2004 - 12:51 : Goba Targets for block title links could be provided by modules, but it is after all the decision of modules to print out block titles using those links. ------------------------------------------------------------------------ June 3, 2004 - 04:26 : Kjartan Once upon a time blocks defind a link along with the subject and content. I think we should re-introduce it, and have it replace the more link that some blocks add. This way themes can choose how and where they put the link (title, text, icon, etc). ------------------------------------------------------------------------ June 3, 2004 - 05:53 : moshe weitzman we already pass the 'more' link separate from the content. this is about how the core themes should present that 'more' link ------------------------------------------------------------------------ June 3, 2004 - 05:58 : Kjartan >From my quick look at blocks in HEAD this is not true for the aggregator or blog blocks, they have specific div & CSS class around them yes, but they are not 100% controlable in the theme. ------------------------------------------------------------------------ June 3, 2004 - 10:18 : Boris Mann " Once upon a time blocks defind a link along with the subject and content. I think we should re-introduce it, and have it replace the more link that some blocks add. This way themes can choose how and where they put the link (title, text, icon, etc). " +10!! Yes, make more block stuff themeable. This is a great solution, since you could also add a "link" field to custom blocks that would display in the same way. Ideally, both the text (e.g. "more", "check this out", "extra stuff", etc. etc.) and the link would be configurable, and the theme would take care of how this is displayed. ------------------------------------------------------------------------ June 17, 2004 - 11:52 : Dries I'm marking this patch 'active' as we agreed to disagree with the suggested patch/approach. Please resubmit or split your patch in smaller chunks. Thanks. ------------------------------------------------------------------------ June 13, 2005 - 05:28 : Robin Monks Attachment: http://drupal.org/files/issues/no.block.display.on.no.content.patch (3 KB) This patch fixes the actual goal of the bug "don't show blocks if they have no content". This is basically ax's patch broken up and updated to HEAD. This patches forum.module and stats. It's been tested to work on CVS HEAD. I'll take responsibility for upcoming changes to this patch. Robin ------------------------------------------------------------------------ June 13, 2005 - 05:55 : Robin Monks Attachment: http://drupal.org/files/issues/no.block.display.on.no.content_0.patch (3.16 KB) Chx recommended moving the returns into their relative ifs. This also works on HEAD. Robin ------------------------------------------------------------------------ June 13, 2005 - 05:57 : Robin Monks Attachment: http://drupal.org/files/issues/no.block.display.on.no.content_1.patch (3.17 KB) ...wrong patch version... Robin

1 0