May 2005 - Development - lists.drupal.org

[drupal-devel] [bug] Incorrect units for upload messages
by drumm 23 May '05

23 May '05

Issue status update for http://drupal.org/node/23213 Project: Drupal Version: 4.6.0 Component: upload.module Category: bug reports Priority: normal Assigned to: drumm Reported by: drumm Updated by: drumm Status: patch Attachment: http://drupal.org/files/issues/upload.module_4.diff (2.02 KB) The upload module stores these two particular variables as a number of megabytes so we need to multiply by 1024^2 as happens elsewhere for these messages. Seeing that something exceeeds a 1 byte quota is a bit disconcerting when you have 1 MB. I made the patch against HEAD, but the problem does exist in 4.6.x. drumm

2 4

[drupal-devel] [task] small db files cleanup
by killes 23 May '05

23 May '05

Issue status update for http://drupal.org/node/23465 Project: Drupal Version: cvs Component: database system Category: tasks Priority: normal Assigned to: killes(a)www.drop.org Reported by: killes(a)www.drop.org Updated by: killes(a)www.drop.org Status: patch Attachment: http://drupal.org/files/issues/db-query-range.patch (1.3 KB) ok, here is a really small patch that wants to get into core. Don't laugh. killes(a)www.drop.org

2 2

[drupal-devel] [feature] AJAX Google Suggest feature for Folksonomy Module
by killes 23 May '05

23 May '05

Issue status update for http://drupal.org/node/21116 Project: Drupal Version: cvs Component: taxonomy.module Category: feature requests Priority: normal -Assigned to: Anonymous +Assigned to: killes(a)www.drop.org Reported by: factoryjoe Updated by: killes(a)www.drop.org -Status: active +Status: patch Attachment: http://drupal.org/files/issues/taxonomy_autocomplete.patch (2.41 KB) Ok, somebody please try this patch. You'll need to apply the ajax patch first. killes(a)www.drop.org Previous comments: ------------------------------------------------------------------------ April 22, 2005 - 20:20 : factoryjoe When adding folksonomy terms to a node, drawing from existing terms would be a useful feature. There are two options worth considering: An initially hidden flat list of the most used 150 tags that you can click to add to your text input (see my demo [1]) A Google-suggest [2] like feature for pulling out of /all available/ tags [1] http://factorycity.net/demos/drupal/node_creation/ [2] http://www.google.com/webhp?complete=1&hl=en ------------------------------------------------------------------------ April 22, 2005 - 21:05 : factoryjoe This was intended for Morbus' freetagging code, which doesn't have a separate project. Thus, I'm moving it to the drupal project. ------------------------------------------------------------------------ May 21, 2005 - 01:03 : killes(a)www.drop.org I think that should be easy once Thox' Ajax code has hit core. See: http://drupal.org/node/22471

1 0

Re: [drupal-devel] creating drupal-doc teams
by Charlie Lowe 23 May '05

23 May '05

Andre wrote: > Sure. (sorry for the late response - its virtually impossible to keep on > top of all the discussions on devel and docs - even just to read them > let alone getting around to respond). > > Would anyone be interested in doing a brainstorming session on a full > list of features and/or uses of drupal? From there I would like to boil > that list down to some real benefits of the product and come up with > ways to market the product based on those. > > I will be doing my own brainstorming and share the results somewhere > (perhaps the wiki or a forum on drupal). > > If anyone is interested - e-mail me at: andre at andremolnar dot com > (not my mcsparkerton address as the message might get lost in the > dev/docs list postings). Great. I'll add you to the marketing group list.

1 0

[drupal-devel] [feature] Temlpate settings user info should include avatar
by Bèr Kessels 23 May '05

23 May '05

Issue status update for http://drupal.org/node/23452 Project: Drupal Version: cvs Component: theme system Category: feature requests Priority: normal Assigned to: Anonymous Reported by: Bèr Kessels Updated by: Bèr Kessels Status: patch Attachment: http://drupal.org/files/issues/phptemplate_user_info_include_avatar.patch (1.17 KB) This patch moves the avatar settings to withing the check for "user info" on a node tpe. If you have user info sitched off, for e.g. stories, and have avatars switched on, a story will not show Pested By Fo on Bar, but will still show the avatar. This patch changes the behavious to show an avatar only if: * avatars are switched on AND * the active node type has post info switched on. Bèr Kessels

1 0

[drupal-devel] creating drupal-doc teams
by Charlie Lowe 23 May '05

23 May '05

Currently, it seems we have lots of interest in taking Drupal documentation in new and interesting directions. To facilitate this, I'd like to see if we can't form some documentation teams. Much like I asked if Djun and Bryan would be in charge of reorganizing the About section of the handbook, I'd like us to form other two person teams for any major area that we have expressed interest in developing. Here are just a few examples of some areas I could imagine Documentation teams for * Restructuring/reorganizing each of the new handbook sections as defined on the V2 page: http://drupal.org/handbook/v2 For example, the About the handbook section. We need a couple of people to be in charge of our authoring guidelines and best practices for creating Drupal handbook documentation. (Anisa spearheaded the style guide revision; perhaps we could coax her and one other person to handle the About the handbook section?) * Best practices for configuring and building Druapl sites (Roland has already volunteered for this one :) Is there another?) * Initiatives for improving the collaborative book and other technological solutions to improve Drupal documentation usability, integration, and creation. (Djun has already been working on this. Perhaps he'd like to be one of the team members. We'd only need one other volunteer then.) * Marketing materials (Andre? You seem to have lots of marketing ideas :) * Etc. The documentation team would be responsible for most decisions regarding their project (in some cases there might be some overlap between other documentation teams, so they'd have to coordinate). Initially, I would hope that each documentation team would run a proposal by the drupal-docs list so that all of us could offer feedback in the construction of their individual project so that a good compromise of the important opposing interests (if any) can be reached. Otherwise, let us know when new documentation is posted (maybe this will be automated) so that we can offer feedback and suggestions. Or when the documentation team members are having trouble solving an issue between themselves, contact the list for assistance in resolution. In the case of any who volunteer for restructuring/revising the handbook sections, if they would like, they could also continue on as the offical book maintainers for those new books. If anyone has ideas for other documentation team areas, please respond to this post via the drupal-docs list. I've mentioned a few people here, but I'm sure there are a lot more. If anyone would like to volunteer to be a documentation team member for a specific project, feel free to post to the drupal-docs list or contact me privately. Once the documentation teams have been created, I'll create a page in the About handbook section so that people know who's in charge of individual projects. I hope this works well for everyone. Putting people in charge of specific areas seems to me the best way for us to get the things we want accomplished. Charlie

7 8

[drupal-devel] [bug] Users with 'maintain books' or 'edit own book pages' permission cannot delete book pages
by rivena 23 May '05

23 May '05

Issue status update for http://drupal.org/node/21559 Project: Drupal Version: cvs Component: book.module Category: bug reports Priority: normal Assigned to: Anonymous Reported by: clydefrog Updated by: rivena Status: patch I've been looking at the book module permissions recently, and did a bit of testing. I wanted to know what was the minimum permissions needed to create a new book. I assumed based on this discussion, and a similar discussion on the drupal support list that this was 'maintain books' and 'administer nodes'. I ran into a problem, then added 'access nodes' to this. So now my user has no other permissions other than 'maintain books', 'administer nodes' and 'access nodes'. You'd think this is more than sufficient to do something simple like create a new book, but in fact, with just these permissions, you do not have access to create a book page. You can edit other pages, and move them into a new book. Once you have create pages permission, you appear to finally have all the permissions needed, edit own pages is not needed. So, since, the point of this patch was that not having delete permission was odd, might I suggest adding create permission to maintain books? ;p Anisa. rivena Previous comments: ------------------------------------------------------------------------ April 29, 2005 - 13:32 : clydefrog Attachment: http://drupal.org/files/issues/delete_own_book_pages.patch (626 bytes) AFAICT, only 'administer nodes' permission allows deletion of book pages. This patch allows users with 'maintain books' or 'edit own book pages' permission to delete book pages. The logic doesn't check if the node has updates pending. Should it? ------------------------------------------------------------------------ April 29, 2005 - 23:10 : clydefrog It's a patch, duh. ------------------------------------------------------------------------ April 29, 2005 - 23:21 : rivena If maintain books is a permission that overlaps other permissions, it should say so. For example, /maintain books (create, edit, and delete all book pages)/. While I agree that someone who has been given maintainer status should be able to delete pages, I wonder if 'delete own pages' should be made into a seperate permission. I could see a situation where I would not want someone to be able to delete their own pages. Do these permissions affect things that are not book pages but have been put into books? Anisa. It's /Golden Week/! ------------------------------------------------------------------------ April 30, 2005 - 12:43 : clydefrog I think it's clear that "maintain books" implies the ability to edit and delete book pages. No other node module provides a "delete own " permission, so it would be inconsistent for book.module to provide it. Can you provide some examples to justify the inconsistency? These permissions do not affect nodes which aren't book pages but are in a book. Those nodes are controlled by their respective type-specific permissions, but only users with "maintain books" permission can add or remove those nodes from books. I believe this is the correct behavior. ------------------------------------------------------------------------ April 30, 2005 - 20:03 : rivena Hmm... But, you just said that until this patch, it *didn't* include the delete pages permission. Right? So, now you are changing it's behavior, but leaving the wording the same. How will people know? Or does it not matter, because you presume they didn't really know it didn't include delete in the first place? I don't know that I can defend my idea of having a seperate delete own pages permission against a standard of consistency. If all the other edit own permissions include the delete pages permission, then I have no quibbles. :) Except it would be more userfriendly if I knew what the permissions meant before I granted them to someone, without having to look at the code. But I do realize that is completely out of the scope of the patch. :) Where do all these little changes *go*, anyway? The changelog just says things like... refractored the search module. Anisa. ------------------------------------------------------------------------ May 1, 2005 - 01:04 : clydefrog I believe that "maintain books" permission implies the ability to delete book pages, so this patch fixes that bug. Other node modules include deletion in the "edit own" permission. For example, page.module: <?php if ($op == 'update' || $op == 'delete') { if (user_access('edit own pages') && ($user->uid == $node->uid)) { return TRUE; } } ?> I agree that it would be better if permissions were clearer about what they implied. There was a discussion started by killes [1] a while ago: "One problem with Drupal is the way it handles user permissions. The permissions are attached to the user object but nobody really knows what they do. To find out what a particular permission allows you to do, you often need to have a look at the code. " I don't know if it ever lead to any code. I think the changelog is meant to list the changes since the previous version without too much technical detail. If you want to see every last change, take a look at the cvs messages [2]. [1] http://lists.drupal.org/archives/drupal-devel/2005-04/msg00704.html [2] http://drupal.org/project/cvs/3060

1 0

[drupal-devel] [bug] file_check_location is not working on Windows 2000
by Uncas 23 May '05

23 May '05

Issue status update for http://drupal.org/node/10885 Project: Drupal Version: cvs Component: file system Category: bug reports Priority: critical Assigned to: Anonymous Reported by: ccourtne Updated by: Uncas Status: patch Still applies for me on 4.6. I don't know how to build patches, so I just solved the problem by replacing line 168 of file.inc as suggested originally. Uncas Previous comments: ------------------------------------------------------------------------ September 16, 2004 - 13:46 : ccourtne Currently file_check_location is always returning false when passed a file as the $source path. If a directory is passed in $soruce file_check_location works. I've tracked this down to realpath returning an empty string when passed a relative path which points to a file. This probably goes unnoticed if you are using the file.api's to construct relative paths to the druapl file directory since check_location failing just causes the durpal file directory to get added which is what you wanted in the first place. Replacing this line $source = realpath(dirname($source)); with this $source = realpath(dirname($source)); fixes it on my windows box using PHP 4.3.8. I don't have things set up to do patches on my windows boxes here at work yet. I'll submit a formal patch tonight. ------------------------------------------------------------------------ September 16, 2004 - 13:47 : ccourtne Dag nabit. Replace $source = realpath($source); with $source = realpath(dirname($source)); Craig ------------------------------------------------------------------------ September 16, 2004 - 13:56 : Anonymous Attachment: http://drupal.org/files/issues/file-inc-file_check_location.patch (639 bytes) The sooner there are patches, the better it is... I tested this approach on my server and it works. Steef ------------------------------------------------------------------------ September 17, 2004 - 01:34 : ccourtne Attachment: http://drupal.org/files/issues/checklocation.patch (666 bytes) Here is the patch. ------------------------------------------------------------------------ February 23, 2005 - 00:30 : dan90(a)drupal.org This also fixed my file upload problems with some nonstandard paths under Linux/apache, php 4.3.4 drupal 4.5.2. maybe we should remove mention of windows 2000? ------------------------------------------------------------------------ March 1, 2005 - 17:32 : killes(a)www.drop.org Still applies. ------------------------------------------------------------------------ April 18, 2005 - 11:10 : ec Is this patch still to be use with actual Drupal 4.6.0 ? Thanks. eric ------------------------------------------------------------------------ May 7, 2005 - 10:35 : Wes Cowley I hand applied the patch to my Linux based installation and it solved the problem I was having with filemanager/attachment. I assume it would fix the same problem I had with upload.module since the symptoms were identical. ------------------------------------------------------------------------ May 7, 2005 - 10:36 : Wes Cowley Meant to add, that was a 4.6.0 Linux installaion that this patch cleared up. ------------------------------------------------------------------------ May 14, 2005 - 07:59 : larryjhs Thanks, still, I'm a bit of a php newbie -- where do I put the patch -- into which bit of script? If it's not too obvious, tell me and I won't try! But if it's obvious, please give me the location L ------------------------------------------------------------------------ May 14, 2005 - 08:19 : ec This patch seem still to apply to 4.6 (I'm using it on my linux box too and it solve my problem with upload.module) it apply on "file.inc" that you will find in includes directory on top of your drupal root. Put the patch in the same directory as file.inc go in this directory too and apply the patch like this "patch -p0 < the_patch_to_apply" where patch is the command on *nix box. If you're not confortable you can either edit the file.inc by hand and make the change yourself, in the patch file, line beginning with "-" is the one to remove, line beginning with "+" is the one to add, other lines are the context so you're sure to find the right line. Hope this help. Regards. ------------------------------------------------------------------------ May 14, 2005 - 08:23 : ec BTW, IMHO this patch should be committed ASAP as it's solve the problem with upload.module that can't handle private directory outside drupal root. Tested on my sites ans work (for now ;-) like a charm. Regards. ------------------------------------------------------------------------ May 15, 2005 - 11:51 : Dries Don't we use file_create_path for that (it appends the 'files'-bit)? ------------------------------------------------------------------------ May 15, 2005 - 20:19 : ec On my linux box, I make an other test with the latest stock release of file.inc. I setup files directectory, with "private" check, outside drupal root and drupal complains The directory does not exist (I know this directory exists and is working because I'm using it !). It only works with the patch below. Sorry, I'm not confortable enought to answer your question Dries, but sure this patch is the only I found to have a real private directory working. Regards, eric. PS : I don't why but got an error each time I want to upload a file here ??? so here is the text against the latest release of file.inc i.e 1.39.2.2 --- ./file.inc 2005-05-15 21:52:40.758531811 +0200 +++ ./file_mod_ec.inc 2005-05-15 22:03:41.869608738 +0200 @@ -169,7 +169,7 @@ * @return 0 for invalid path or the real path of the source. */ function file_check_location($source, $directory = 0) { - $source = realpath($source); + $source = realpath(dirname($source)); $directory = realpath($directory); if ($directory && strpos($source, $directory) !== 0) { return 0; >/code> ------------------------------------------------------------------------ May 21, 2005 - 05:00 : Rick Cogley The patch fixed uploads for me as well on 4.6.0. ------------------------------------------------------------------------ May 21, 2005 - 09:57 : Dries This patch no longer applies against HEAD or DRUPAL-4-6. Could someone try reproducing this problemwith the latest version in either branch, and provide an updated patch. (I think the problem still needs fixing but I'm not sure and can't reproduce the problem.)

1 0

[drupal-devel] [task] theme_user_list is useless for advanced themeing. Patch changes that.
by adrinux 23 May '05

23 May '05

Issue status update for http://drupal.org/node/23383 Project: Drupal Version: 4.6.0 Component: theme system Category: tasks Priority: normal Assigned to: Anonymous Reported by: Bèr Kessels Updated by: adrinux Status: patch +1 Looks good to me adrinux Previous comments: ------------------------------------------------------------------------ May 22, 2005 - 16:18 : Bèr Kessels Attachment: http://drupal.org/files/issues/user_module_theme_list.patch (1.88 KB) Since the function currently only receives a string of HTML there is no way to add inormation to a user list. You cannot do a user_load to add additional information, like the avatar. Pattern matching the UID from the url in the html is not an option, since a username could be aliassed, thus in order to get the UID you need a lot of quite heavy code. This patch changes the passed argument into an array of user objects. By default the objects need only to contain the name and UID. This patch also cleans up the online user list block, which had some inconsistent code. After his patch you can have fancy users lists like on my development ste: http://84.244.1.246 ------------------------------------------------------------------------ May 22, 2005 - 17:22 : Bèr Kessels forgot status patch ------------------------------------------------------------------------ May 22, 2005 - 22:16 : factoryjoe I will +1 if this simply means that the user array is passed on for theming, which I think it does. In which case, this is consistent w/ nodes and comments, so I think it's good.

1 0

[drupal-devel] Fwd: [WEB SECURITY] CAPTCHA vulnerabilities - multiple vendors
by Mark Quinn 23 May '05

23 May '05

vulnerability found in drupal captcha implementation. ---------- Forwarded message ---------- From: systemcracker(a)gmail.com <systemcracker(a)gmail.com> Date: May 22, 2005 10:34 PM Subject: [WEB SECURITY] CAPTCHA vulnerabilities - multiple vendors To: webappsec <webappsec(a)securityfocus.com>, websecurity(a)webappsec.org Hi there. While developing a CAPTCHA script in PHP, I found a serious problem with my own script that also affects a *large* number of commercial and free CAPTCHA applications. Most CAPTCHAs don't destroy the session when the correct phrase is entered, this enables attackers to re-use a session-id for a known captcha string, thus allowing multiple form submittals. A list of all the scripts I could get my hands on, with details of whether they're vulnerable or not, is given below (taken from http://en.wikipedia.org/wiki/Captcha) Here's the lowdown: manual steps: connect to captcha page record session ID and captcha plaintext automated steps: send session ID and captcha plaintext a number of times, changing the user data, eg: POST /vuln_script.php HTTP/1.0 Cookie: PHPSESSID=329847239847238947; ^^^ this is the session id of the page you looked at manually Content-Length: 49 Connection: close; name=bob&email=bob(a)fish.com&captcha=the_plaintext ^^^ this includes the captcha string for the page you looked at manually the other user data can change on each request you can then automate hundreds, if not thousands of requests, until the session expires, at which point you just repeat the manual steps and then reconnect with a new session id and captcha text. This is -easy- to fix, here's the vulnerable pseudocode: if form_submitted and captcha_stored!="" and captcha_sent=captcha_stored then process_form(); endif: fixed psuedocode: if form_submitted and captcha_stored!="" and captcha_sent=captcha_stored then captcha_stored=""; process_form(); endif: - it's a one line fix! tested scripts: ------------------------------------------------- http://www.humanverify.com/genDemo.asp vulnerable (this product has 239 registered users) ------------------------------------------------- http://drupal.org/project/captcha - demo at http://arnab.drupaldevs.org/user/register vulnerable ------------------------------------------------- http://higginsforpresident.net/projects/tacs/demo/ vulnerable ------------------------------------------------- http://phpbtree.com/captcha/index.php vulnerable ------------------------------------------------- http://www.lanapsoft.com/products.html, demo at http://www.captchaservice.com/ vulnerable. ------------------------------------------------- http://www.codeproject.com/aspnet/CaptchaImage.asp vulnerable; haven't tested but looking at code, seems to be: if (this.CodeNumberTextBox.Text == this.Session["CaptchaImageText"].ToString()) { // Display an informational message. this.MessageLabel.CssClass = "info"; this.MessageLabel.Text = "Correct!"; } doesn't clear session so could reconnect and give same word. ------------------------------------------------- http://james.seng.cc/archives/000145.html possibly vulnerable; can't get the form to submit even normally! ------------------------------------------------- http://www.puremango.co.uk/cm_freecap_113.php (my own script) version 1.3 not vulnerable, version 1.2 and below vulnerable ------------------------------------------------- http://php.webmaster-kit.com/audit.html not vulnerable ------------------------------------------------- "only as secure as the weakest link in the chain" springs to mind. I also managed to automate requests to www.captcha.net<http://www.captcha.net>'s demos, but having examined the implementation of their system on google, I think it's only the -demo- that's vulnerable. (I assume google's system is the one from the CAPTCHA project; it looks very similar) If anyone wants me to look over their scripts, buzz me and I'll be more than willing to see if you're vulnerable, and give advice on how to fix. -- Computing tools, PHP code, online tools and more at http://www.puremango.co.uk --------------------------------------------------------------------- The Web Security Mailing List http://www.webappsec.org/lists/websecurity/ The Web Security Mailing List Archives http://www.webappsec.org/lists/websecurity/archive/

1 0