August 2005 - Development - lists.drupal.org

[drupal-devel] [bug] Change default for files directory
by killes 20 Aug '05

20 Aug '05

Issue status update for http://drupal.org/node/23467 Project: Drupal Version: cvs Component: file system Category: bug reports 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/file-default.patch (4.98 KB) Currently the defautl for the file storage directory is /files. This is a problrem if you should later decide to setup more than one site from the same source code. The attached page changes the default to be /sites/default/files (defautl is replaced by the site url if the default directory is renamed). killes(a)www.drop.org

6 9

[drupal-devel] [feature] create system option to prevent users from changing the theme
by robertDouglass 20 Aug '05

20 Aug '05

Issue status update for http://drupal.org/node/26302 Post a follow up: http://drupal.org/project/comments/add/26302 Project: Drupal Version: 4.6.0 Component: system.module Category: feature requests Priority: normal Assigned to: Torenware Reported by: Torenware Updated by: robertDouglass Status: patch (code needs work) I'd like to propose a different solution; create a "can select own theme" permission for users. I agree that there are cases where some people should be able to choose their theme and others shouldn't. Personally, I don't make many sites where you get to "skin" the site just for fun. More likely, I use theme selection for development purposes (I develop the next version of a site's theme and can switch back and forth, and so can the developer, but nobody else). If we had a permission that could be given to roles, then og group administrators could be given this permission, if I'm not mistaken. Would this fit the bill, Torenware? robertDouglass Previous comments: ------------------------------------------------------------------------ Mon, 04 Jul 2005 01:50:45 +0000 : Torenware Attachment: http://drupal.org/files/issues/add-user-themable-option.diff (1.86 KB) >From the forum thread How To Prevent Users From Changing The Theme. I asked: " I'm working on a module that uses organic groups. I want to allow different groups to choose different themes, but I don't want individual users to have that capability. I'm assuming that this is easy to do, but I can't find a setting. Can anybody point me in the right direction? Thanks, Rob " At sepeck's suggestion, I'm submitting a patch to do this. It's against 4.6.0, and modifies theme.inc and system.module. It creates a variable 'configurable_user_themes' which defaults to "enabled" (4.6.0's current behavior), and if activated, makes system.module remove the UI for selected a theme, and also causes theme.inc to ignore any setting for $user->theme if it exists. ------------------------------------------------------------------------ Mon, 04 Jul 2005 01:54:40 +0000 : Torenware Attachment: http://drupal.org/files/issues/add-user-themable-option_0.diff (1.86 KB) Didn't set this to "patch" initially, so I'm including the patch again. Not sure what the procedure is just yet. ------------------------------------------------------------------------ Mon, 04 Jul 2005 05:07:44 +0000 : TDobes -1 -- sorry, but I feel that we should use a different method for this sort of thing. Any theme that is checked in the admin-> themes screen should be selectable by users. Modules should get their list of available themes from list_themes(), which provides a list of all available themes, not just those that are selected for use by users. ------------------------------------------------------------------------ Mon, 04 Jul 2005 09:21:57 +0000 : Bèr Kessels I think we should simply rename the "enabled" into "selecatble". Or any better term. For the only thing tha checkbox does is enable it for users to select. It does not enable or disable the theme at all. ------------------------------------------------------------------------ Mon, 04 Jul 2005 18:56:53 +0000 : Torenware A couple of comments: To TDobbs: for most applications, you're right. But for some applications where it's important to the site that user experience is well tested, letting individual users set the theme is something of a nightmare; a problem with the theme is perceived as a problem with the site. So for /those/ sites (such as the one I'm currently working on), letting the user set the theme was APITA. Still, for a community site, I agree that the current behavior is fine. So I made the current behavior the default. To Bèr Kessels: Let me see if I understand what you mean. Currently, I've coded the UI to say in its English default: User theme settings Configurable Themes: * Disabled * Enabled Enable or disable user-configurable themes. When enabled, users can set their own theme to override the site's default theme. Would you prefer: User theme settings Selectable Themes: * Disabled * Enabled Enable or disable user-selectable themes. When enabled, users can select their own theme to override the site's default theme. I don't really want to lose the "Disable"/"Enable" part, because if you look at the current UI in 4.6, all similar settings are done that way. So using a checkbox would be inconsistent with the rest of the page. How's that? Rob ------------------------------------------------------------------------ Mon, 04 Jul 2005 21:31:14 +0000 : Bèr Kessels Attachment: http://drupal.org/files/issues/theme.png (17.19 KB) you indeed misunderstood me. We have a "enable theme" checkbox in the theme overview. That checkbos *does not enable anything* it only gives users the opportunity to select that theme. Please se the screeny (sorry, Dutch locale enabled) for what I mean. Th e second comumn. That chackbox. Just investigte its use. You will its complete and utter cruft, that checkbox. Ber ------------------------------------------------------------------------ Mon, 04 Jul 2005 23:20:55 +0000 : Torenware Ber, I have a site that may well use themes set at the group level, so unactivating the theme via admin/theme is not a great solution for me. The problem with your solution is that if a theme is deactivated, it is not available for anyone. I need multiple themes available, but need to make the rather confusing UI that appears in user/n/edit to go away. Your options will not do that. ------------------------------------------------------------------------ Mon, 04 Jul 2005 23:28:27 +0000 : Torenware Ber, /Please se the screeny (sorry, Dutch locale enabled) for what I mean. Th e second comumn. That chackbox. Just investigte its use. You will its complete and utter cruft, that checkbox./ I'm not following you. Could you please explain a bit more? Thanks, Rob ------------------------------------------------------------------------ Mon, 04 Jul 2005 23:37:13 +0000 : TDobes /I have a site that may well use themes set at the group level, so unactivating the theme via admin/theme is not a great solution for me./ Sure it is! Deactivating themes in admin->theme removes them *ONLY* from the list of themes available for users to select. It should not remove them from the list of available themes for modules to use (via. the $custom_theme variable). If themes are disappearing from the modules' lists, these are bugs in the modules and should be reported elsewhere. I was under the impression that you were writing your own module, which is why I suggested you use the list_themes function. This function returns all available themes, not just those that are selected in admin->themes. Ber has mentioned that the term "enabled" is poorly chosen and should be replaced with something else, such as "user-selectable". I agree with him. /The problem with your solution is that if a theme is deactivated, it is not available for anyone./ This is completely false. It is not available to be chosen in the "my account" screen, but it is still very readily available for use by modules through the $custom_theme variable. /I need multiple themes available, but need to make the rather confusing UI that appears in user/n/edit to go away. Your options will not do that./ Yes they do. How are you determining the list of available themes in your module? If the themes are disappearing when you deselect them from admin->themes, then your module is working improperly. ------------------------------------------------------------------------ Mon, 04 Jul 2005 23:59:25 +0000 : Torenware OK, if I'm understanding you, then indeed the UI in admin/themes is bad done enough to fool a native English speaker. What y'all from Europe make of some of the terms, I can't even guess :-) I'll see if the UI disappears if all of the items are "deactivated" makes the UI go away (and doesn't break Organic Groups...). But it sounds like the real "bug" is in the documentation. This string: / Select which themes are available to your users and specify the default theme. To configure site-wide display settings, click the "configure" task above. Alternately, to override these settings in a specific theme, click the "configure" link for the corresponding theme. / needs changing. Perhaps something like "Choose a default theme for your site, and select which themes your users can choose to override the default." For the record: I do not have a clue what "Alternately, to override these settings in a specific theme, click the "configure" link for the corresponding theme.". If someone will tell me what that means, maybe some of us can translate it into English :-) Then someone can translate it into whatever else we need to support. ------------------------------------------------------------------------ Sat, 20 Aug 2005 05:22:53 +0000 : TDobes Please see the patch I've attached to this issue [1], which renames "enabled" to "user-selectable"... this should hopefully clear up a lot of confusion. [1] http://drupal.org/node/29002

1 0

[drupal-devel] [feature] create system option to prevent users from changing the theme
by TDobes 20 Aug '05

20 Aug '05

Issue status update for http://drupal.org/node/26302 Post a follow up: http://drupal.org/project/comments/add/26302 Project: Drupal Version: 4.6.0 Component: system.module Category: feature requests Priority: normal Assigned to: Torenware Reported by: Torenware Updated by: TDobes -Status: patch (code needs review) +Status: patch (code needs work) Please see the patch I've attached to this issue [1], which renames "enabled" to "user-selectable"... this should hopefully clear up a lot of confusion. [1] http://drupal.org/node/29002 TDobes Previous comments: ------------------------------------------------------------------------ Mon, 04 Jul 2005 01:50:45 +0000 : Torenware Attachment: http://drupal.org/files/issues/add-user-themable-option.diff (1.86 KB) >From the forum thread How To Prevent Users From Changing The Theme. I asked: " I'm working on a module that uses organic groups. I want to allow different groups to choose different themes, but I don't want individual users to have that capability. I'm assuming that this is easy to do, but I can't find a setting. Can anybody point me in the right direction? Thanks, Rob " At sepeck's suggestion, I'm submitting a patch to do this. It's against 4.6.0, and modifies theme.inc and system.module. It creates a variable 'configurable_user_themes' which defaults to "enabled" (4.6.0's current behavior), and if activated, makes system.module remove the UI for selected a theme, and also causes theme.inc to ignore any setting for $user->theme if it exists. ------------------------------------------------------------------------ Mon, 04 Jul 2005 01:54:40 +0000 : Torenware Attachment: http://drupal.org/files/issues/add-user-themable-option_0.diff (1.86 KB) Didn't set this to "patch" initially, so I'm including the patch again. Not sure what the procedure is just yet. ------------------------------------------------------------------------ Mon, 04 Jul 2005 05:07:44 +0000 : TDobes -1 -- sorry, but I feel that we should use a different method for this sort of thing. Any theme that is checked in the admin-> themes screen should be selectable by users. Modules should get their list of available themes from list_themes(), which provides a list of all available themes, not just those that are selected for use by users. ------------------------------------------------------------------------ Mon, 04 Jul 2005 09:21:57 +0000 : Bèr Kessels I think we should simply rename the "enabled" into "selecatble". Or any better term. For the only thing tha checkbox does is enable it for users to select. It does not enable or disable the theme at all. ------------------------------------------------------------------------ Mon, 04 Jul 2005 18:56:53 +0000 : Torenware A couple of comments: To TDobbs: for most applications, you're right. But for some applications where it's important to the site that user experience is well tested, letting individual users set the theme is something of a nightmare; a problem with the theme is perceived as a problem with the site. So for /those/ sites (such as the one I'm currently working on), letting the user set the theme was APITA. Still, for a community site, I agree that the current behavior is fine. So I made the current behavior the default. To Bèr Kessels: Let me see if I understand what you mean. Currently, I've coded the UI to say in its English default: User theme settings Configurable Themes: * Disabled * Enabled Enable or disable user-configurable themes. When enabled, users can set their own theme to override the site's default theme. Would you prefer: User theme settings Selectable Themes: * Disabled * Enabled Enable or disable user-selectable themes. When enabled, users can select their own theme to override the site's default theme. I don't really want to lose the "Disable"/"Enable" part, because if you look at the current UI in 4.6, all similar settings are done that way. So using a checkbox would be inconsistent with the rest of the page. How's that? Rob ------------------------------------------------------------------------ Mon, 04 Jul 2005 21:31:14 +0000 : Bèr Kessels Attachment: http://drupal.org/files/issues/theme.png (17.19 KB) you indeed misunderstood me. We have a "enable theme" checkbox in the theme overview. That checkbos *does not enable anything* it only gives users the opportunity to select that theme. Please se the screeny (sorry, Dutch locale enabled) for what I mean. Th e second comumn. That chackbox. Just investigte its use. You will its complete and utter cruft, that checkbox. Ber ------------------------------------------------------------------------ Mon, 04 Jul 2005 23:20:55 +0000 : Torenware Ber, I have a site that may well use themes set at the group level, so unactivating the theme via admin/theme is not a great solution for me. The problem with your solution is that if a theme is deactivated, it is not available for anyone. I need multiple themes available, but need to make the rather confusing UI that appears in user/n/edit to go away. Your options will not do that. ------------------------------------------------------------------------ Mon, 04 Jul 2005 23:28:27 +0000 : Torenware Ber, /Please se the screeny (sorry, Dutch locale enabled) for what I mean. Th e second comumn. That chackbox. Just investigte its use. You will its complete and utter cruft, that checkbox./ I'm not following you. Could you please explain a bit more? Thanks, Rob ------------------------------------------------------------------------ Mon, 04 Jul 2005 23:37:13 +0000 : TDobes /I have a site that may well use themes set at the group level, so unactivating the theme via admin/theme is not a great solution for me./ Sure it is! Deactivating themes in admin->theme removes them *ONLY* from the list of themes available for users to select. It should not remove them from the list of available themes for modules to use (via. the $custom_theme variable). If themes are disappearing from the modules' lists, these are bugs in the modules and should be reported elsewhere. I was under the impression that you were writing your own module, which is why I suggested you use the list_themes function. This function returns all available themes, not just those that are selected in admin->themes. Ber has mentioned that the term "enabled" is poorly chosen and should be replaced with something else, such as "user-selectable". I agree with him. /The problem with your solution is that if a theme is deactivated, it is not available for anyone./ This is completely false. It is not available to be chosen in the "my account" screen, but it is still very readily available for use by modules through the $custom_theme variable. /I need multiple themes available, but need to make the rather confusing UI that appears in user/n/edit to go away. Your options will not do that./ Yes they do. How are you determining the list of available themes in your module? If the themes are disappearing when you deselect them from admin->themes, then your module is working improperly. ------------------------------------------------------------------------ Mon, 04 Jul 2005 23:59:25 +0000 : Torenware OK, if I'm understanding you, then indeed the UI in admin/themes is bad done enough to fool a native English speaker. What y'all from Europe make of some of the terms, I can't even guess :-) I'll see if the UI disappears if all of the items are "deactivated" makes the UI go away (and doesn't break Organic Groups...). But it sounds like the real "bug" is in the documentation. This string: / Select which themes are available to your users and specify the default theme. To configure site-wide display settings, click the "configure" task above. Alternately, to override these settings in a specific theme, click the "configure" link for the corresponding theme. / needs changing. Perhaps something like "Choose a default theme for your site, and select which themes your users can choose to override the default." For the record: I do not have a clue what "Alternately, to override these settings in a specific theme, click the "configure" link for the corresponding theme.". If someone will tell me what that means, maybe some of us can translate it into English :-) Then someone can translate it into whatever else we need to support.

1 0

[drupal-devel] [feature] Link in aggregator to update all feeds
by Uwe Hermann 20 Aug '05

20 Aug '05

Issue status update for http://drupal.org/node/18921 Post a follow up: http://drupal.org/project/comments/add/18921 Project: Drupal Version: cvs Component: aggregator.module Category: feature requests Priority: minor Assigned to: Anonymous Reported by: townxelliot Updated by: Uwe Hermann -Status: active +Status: patch (code needs work) The patch does still apply to HEAD, but doesn't seem to work. Uwe Hermann Previous comments: ------------------------------------------------------------------------ Tue, 15 Mar 2005 10:01:59 +0000 : townxelliot Attachment: http://drupal.org/files/issues/aggregator.module_6.patch (1.86 KB) Would be nice to have a manual link in the aggregator to update all feeds immediately without affecting cron. Attached patch (diff -Nur) adds this functionality.

2 1

[drupal-devel] [bug] Bad CSS tag for aggregator module
by Uwe Hermann 20 Aug '05

20 Aug '05

Issue status update for http://drupal.org/node/28702 Post a follow up: http://drupal.org/project/comments/add/28702 Project: Drupal -Version: 4.6.0 +Version: cvs Component: aggregator.module Category: bug reports Priority: normal Assigned to: Anonymous Reported by: Sheldon Rampton Updated by: Uwe Hermann -Status: active +Status: patch (code needs review) Attachment: http://drupal.org/files/issues/aggregator_css.patch (503 bytes) Here's a patch for HEAD (untested). Uwe Hermann Previous comments: ------------------------------------------------------------------------ Thu, 11 Aug 2005 17:05:01 +0000 : Sheldon Rampton The "misc" folder contains a file, "drupal.css," which includes a number of CSS tags that affect the display of content generated by the aggregator module. The following tag creates a line break problem: #aggregator .news-item .title { float: left; } In order to make sure that the next field ("description") breaks to a new line, another tag has been included, as follows: #aggregator .news-item .description { clear: both; } The problem is that if there is no description field, the field which follows immediately after the title is "source," and since source doesn't have a "clear: both" attribute, the "source" line runs together with the title. To fix this, add the following tag to drupal. css: #aggregator .news-item .source { clear: both; } By the way, it's rather frustrating that all of these aggregator-related style tags are buried in the misc folder. The first place where most people are likely to look for style tags will be in their theme directory. The second place they might look would be in the directory for the affected module. CSS tags buried in the misc directory are hard to find and easy to overlook. We spent several hours poring over the style tags in our theme directory before we finally figured out where this bug was located.

1 0

[drupal-devel] [feature] Add support for generating an RSS 0.92 feed of news aggregator items
by Uwe Hermann 20 Aug '05

20 Aug '05

Issue status update for http://drupal.org/node/9167 Post a follow up: http://drupal.org/project/comments/add/9167 Project: Drupal Version: cvs Component: aggregator.module Category: feature requests Priority: normal Assigned to: Anonymous Reported by: blake7 Updated by: Uwe Hermann -Status: active +Status: patch (code needs review) Attachment: http://drupal.org/files/issues/aggregator_feed.patch (4.79 KB) Here's an update for the patch from #18, rerolled for current HEAD. Please test. Uwe Hermann Previous comments: ------------------------------------------------------------------------ Fri, 09 Jul 2004 04:11:13 +0000 : blake7 Attachment: http://drupal.org/files/issues/aggregator.module_0.patch (2.96 KB) The attached patch adds support for generating an RSS 0.92 feed of the default news aggregator page (the output of aggregator_page_last()). This allows re-use of the Drupal aggregator in other RSS readers like Trillian. The patch consists of the aggregator_page_rss() function which builds the XML output needed. It uses the existing RSS building functions already present to construct the feed. Note the comment about how many items are in the feed. In Drupal 4.4.x, there was a variable "aggregator_page_limit" which represented how many items were returned for both the HTML and RSS versions. It defaulted to 75 items. In Drupal CVS, all the HTML output is now paged through a hard-coded limit of 20 items per page. A limit of 20 seems small for the RSS feed, so I reverted to the old limit of 75. Would it be better to add a new variable like "aggregator_rss_limit"? Also, there are 2 places that the callback to aggregator_page_rss are installed. One is in _aggregator_page_list right before the pager output and shows up as the XML icon (like how the OPML feeds are linked now). The other is in aggregator_menu where I try and install a menu itme called "RSS feed". For some reason, the menu itme is not displaying itself though I believe I am inserting it properly. Feel free to contact me if there are any questions. Thanks! ------------------------------------------------------------------------ Fri, 09 Jul 2004 17:29:48 +0000 : blake7 Attachment: http://drupal.org/files/issues/aggregator.module_1.patch (2.54 KB) Fixed the navigation menu problems mentioned above. Please consider this patch instead of the first one. ------------------------------------------------------------------------ Fri, 09 Jul 2004 18:09:54 +0000 : drumm When this functionality is added it should be able to generate feeds for each aggregator category as well. ------------------------------------------------------------------------ Sat, 10 Jul 2004 01:22:31 +0000 : blake7 Attachment: http://drupal.org/files/issues/aggregator.module_2.patch (3.25 KB) Done. The attached patch supports RSS feeds of each aggregator category through the XML icon at the bottom exactly like the main aggregator page. ------------------------------------------------------------------------ Sat, 10 Jul 2004 12:01:05 +0000 : Dries 1. $base_url . "/aggregator" . $url is incorrect. All URLs must be constructed using url() as it is aware of clean URLs and path aliasing. 2. Emitting 75 RSS items is quite much (uncommon) and can easily turn into a bandwidth bottleneck. Can we add one global setting that controls how many entries our feed should have (not just the newly introduced feeds)? To 'export' your content in case you wish to migrate to another tool, a special value 'all' (say '1000000') might be handy. ------------------------------------------------------------------------ Fri, 17 Sep 2004 08:19:27 +0000 : blake7 Attachment: http://drupal.org/files/issues/aggregator.module_3.patch (4.47 KB) 1. Using url() now. 2. Added the presistent variable aggregator_rss_limit which controls how many RSS items are generated. A form_select edit control to control the new variable, with all defined as 1000000, was added to the configure tab. I am not sure what you mean by "our feeds" versus "newly introduced feeds" in your comment. Also, even though the code-freeze has taken place, do you think it would be possible to get this into Drupal 4.5? The code change is very minimal and I believe the ability to share aggregated feeds is a great feature. ------------------------------------------------------------------------ Fri, 17 Sep 2004 18:07:05 +0000 : Boris Mann +1 I actually assumed (there was much discussion?) that the re-exporting of aggregator items on a per-bundle basis was going to be enabled for 4.5. Let's get this in before the code freeze -- this would be a major feature announcement for 4.5, and could perform the basis for other great functionality for 4.6 (e.g. per category OPML file generation). ------------------------------------------------------------------------ Fri, 22 Oct 2004 18:20:21 +0000 : blake7 Now that 4.5 has released. Can this go into CVS/HEAD? Is there any other changes to the patch that need to be made by me to make that happen? Thanks. ------------------------------------------------------------------------ Sat, 23 Oct 2004 18:05:33 +0000 : Dries I'll look at it again. Does the patch add XML-icons or how do people find out about the RSS feeds? Can't we make the URLs a bit more intuitive? For example by making it so that you merely have to append '/rss.xml' to the aggregator module's URLs: foo.com/aggregator/rss.xml foo.com/aggregator/categories/1/rss.xmlIt is certainly not a requirement, just a thought that might be worth considering. ------------------------------------------------------------------------ Sat, 23 Oct 2004 18:15:58 +0000 : Dries I'll look at it again. Does the patch add XML-icons or how do people find out about the RSS feeds? Can't we make the URLs a bit more intuitive? For example by making it so that you merely have to append '/rss.xml' to the aggregator module's URLs: foo.com/aggregator/rss.xml foo.com/aggregator/categories/1/rss.xmlIt is certainly not a requirement, just a thought that might be worth considering. ------------------------------------------------------------------------ Mon, 25 Oct 2004 10:50:27 +0000 : Bèr Kessels cross linking to a [feature] that talks about such a unified rss link: http://drupal.org/node/11937 ------------------------------------------------------------------------ Wed, 09 Feb 2005 20:17:38 +0000 : sethcohn Bump. Neat feature, would be nice for 4.6 What's the progress on making it happen? ------------------------------------------------------------------------ Wed, 09 Feb 2005 20:43:59 +0000 : Boris Mann Here's another bump to this. I would say since it missed 4.5 (and was ready at the time) we get this in to 4.6. Should mesh nicely with walkah's RSS updates. Dries: there is an XML icon at the bottom of each category page, plus the HTML header can include an alternate link to the feed. I vote against any sort of "rss.xml", people can alias if they wish. (ideally we could get per-category OPML links as well, but I'll leave that for another feature request) ------------------------------------------------------------------------ Thu, 10 Feb 2005 14:58:47 +0000 : Bèr Kessels A request for unification of feeds [1] is waiting in the queue already. [1] http://drupal.org/node/11937 ------------------------------------------------------------------------ Thu, 10 Feb 2005 15:23:47 +0000 : Boris Mann This patch is not about "feed unification", it adds RSS feeds for category bundles...which have been asked about (and coded for, here in this patch) since 4.4. ------------------------------------------------------------------------ Mon, 28 Feb 2005 22:37:21 +0000 : playdreamer Thrilled I found this as its the one killer feature that the aggregator appeared to be missing. One point I notice though is that the title of the generated feed is 'drupal', when presumably it should pick up something along the lines of 'sitename news aggregator'. ------------------------------------------------------------------------ Tue, 01 Mar 2005 20:42:20 +0000 : Dries In addition to the other suggestions, this patch should not use arg() and should make the hardcoded string stranslatable. ------------------------------------------------------------------------ Fri, 11 Mar 2005 19:00:53 +0000 : deskpops I'm trying to integrate Blake7's RSS creation code into my aggregator.module, but I don't think I have the experience to do it properly. Has anyone created a complete aggregator.module that has this already in it that I can just use to replace my current aggregator module? (I'm running 4.5.2) Thanks in advance, Jeff ------------------------------------------------------------------------ Tue, 12 Apr 2005 23:06:58 +0000 : Richard Eriksson Attachment: http://drupal.org/files/issues/aggregator.module.bundle-feeds.patch.txt (4.53 KB) The attached patch adds a bugfix in the title (changes it from a hard-coded 'drupal' to a variable_get('site_name', 'drupal') and makes the link element inside the channel a fully-qualifed URL using base_url + '/' then the path of the aggregator. (It doesn't incorporate, however, Dries suggestions for removing the args and translating the hard-coded strings.) This patch is based on the above patches. Suggestions for future patches: +1 on Dries' suggestions, and add a link element in the HTML header for RSS autodiscovery. ------------------------------------------------------------------------ Wed, 08 Jun 2005 19:02:55 +0000 : Michael Acord(a)www.simplemoneymanagement.info Any idea how to get this to apply to drupal 4.6.1? The first chunk does not patch, but chunks 2-4 do.

1 0

[drupal-devel] Re: Workshop on Porting modules to Drupal 4.7-tomorrow 11AM Pacific Coast Time
by Kieran Lal 20 Aug '05

20 Aug '05

This is reminder. If you have custom modules, or want to learn how to help get the first release of CivicSpace on Drupal 4.7 out quickly please attend our first Drupal module porting workshop tomorrow. Karoly Negyesi, a.k.a chx, will be our workshop host. Kieran On Aug 15, 2005, at 7:38 AM, Kieran Lal wrote: > Drupal 4.7 is probably going to go into code freeze in the next > several weeks. In order to facilitate an effective release cycle > for contributed modules we are conducting the first of several > workshops on how to port modules to Drupal 4.7. In particular, this > is important for the CivicSpace community which has at least 30 > contributed modules that they require to be ported to Drupal 4.7. > > When: 11AM Pacific Coast Time, Coordinated Universal Time -7 hours; > Daylight Saving Time > Where: IRC irc.freenode.net, #drupal-porting > Who: > -Module Maintainers > -Developers who are wiling to make patches to contributed modules > -Developers who have written custom modules > -Users who are willing to install Drupal 4.7 from CVS and test > upgraded modules > > An upgrade document has been written for porting Drupal modules > from 4.6 to 4.7 by Karoly Negyesi. Karoly is going to help run a > workshop next Saturday at 11AM Pacific Time for two hours to > facilitate developers porting their modules from 4.6 to 4.7. If you > are not a module maintainer but would like to assist a maintainer > you can port a module and submit a patch that has been peer > reviewed to the maintainer. In most cases maintainers will be happy > to recieve a working peer reviewed patch. If you are a maintainer > and would like volunteers to port your modules for you please > contact me Kieran at civicspacelabs dot org and I'll help to match > volunteers to your modules. If you are not a programmer but are > willing to install Drupal 4.7 from CVS and apply patches to modules > then you can help validate that patches work. > > If you have a custom module that is written for previous versions > of Drupal now is your chance to get live Drupal developer help to > get it read to move to Drupal 4.7. > > Documentation is available here: Porting modules to Drupal 4.7 > > The next porting workshop will be done at a different time to > facilitate the various time zones that our developers work in. > Suggestions welcome. > > The first workshop will be in IRC #drupal-porting on irc.freenode.net. > > If you would like to indicate that you are attending this workshop, > please invite yourself and under add invitees and you will recieve > and invite that you can respond to. > > > > Here is the event: http://civicspacelabs.org/home/node/13752 > > Here is the RSVP which you can add your email address to indicate > you will be attending: http://civicspacelabs.org/home/rsvp/email/ > a9e6b562244d1f3e22c4a92f70ff026e > > > > Sorry for the late notice, there will be similar workshops at later > dates. > > Cheers, > > Kieran > >

1 0

[drupal-devel] [task] Installation instructions for PostgreSQL users
by Cvbge 19 Aug '05

19 Aug '05

Issue status update for http://drupal.org/node/25792 Post a follow up: http://drupal.org/project/comments/add/25792 Project: Drupal Version: cvs Component: postgresql database Category: tasks Priority: normal Assigned to: Anonymous Reported by: Smirnov Updated by: Cvbge Status: patch (code needs review) I like the patch, but IMO it needs to wait till http://drupal.org/node/26091 gets in Cvbge Previous comments: ------------------------------------------------------------------------ Sun, 26 Jun 2005 17:41:57 +0000 : Smirnov Attachment: http://drupal.org/files/issues/INSTALL.txt.oldnew.patch (4.39 KB) Although installing Drupal with PostgreSQL is rather straight forward, there are a few stumbling blocks (needing to load a language into the database and not using the public schema, as well as there being zero instructions): I have added instructions to /INSTALL.txt/ on how to load up the SQL scheme into PostgreSQL, and I have edited /database/database.pgsql/ so that it is easy to install drupal into any schema. As a result, users can now for example install Drupal into database drupal, schema drupal (with the functions in public). This means they could use different modules for different schemas if they wanted to. The instructions include: * Creating a database with /createdb/ * Loading up plpgsql language with /createlang/ * Inserting all the SQL data into the schema of choice * Changing /$db_prefix/ to reflect the schema ------------------------------------------------------------------------ Sun, 26 Jun 2005 17:42:50 +0000 : Smirnov Attachment: http://drupal.org/files/issues/database.pgsql.oldnew.patch (588 bytes) Attached the /database/database.pgsql/ patch ------------------------------------------------------------------------ Thu, 30 Jun 2005 16:11:52 +0000 : Smirnov Attachment: http://drupal.org/files/issues/INSTALL.txt.patch(install only) (4.48 KB) Updated INSTALL.txt against HEAD, also made it so the instructions pertain to installing to the "public" schema by default (and left a notice on there for people to edit database.pgsql if they need to do otherwise). The previous patches can now be safely ignored (esp. since they were for 4.6.1).

1 0

[drupal-devel] [bug] comment preview "Required" is easily bypassed
by drumm 19 Aug '05

19 Aug '05

Issue status update for http://drupal.org/node/28420 Post a follow up: http://drupal.org/project/comments/add/28420 Project: Drupal Version: cvs Component: comment.module Category: bug reports Priority: normal Assigned to: Jeremy(a)kerneltrap.org Reported by: Jeremy(a)kerneltrap.org Updated by: drumm Status: patch (code needs review) The unclosed link in my last update was supposed to say drupal_set_message(..., 'error') drumm Previous comments: ------------------------------------------------------------------------ Mon, 08 Aug 2005 01:55:34 +0000 : Jeremy(a)kerneltrap.org Setting "Preview comment" to "Required" does not strictly require that the comment be previewed first. This is being abused by spammers to quickly and efficiently post spam comments. I discovered this after I added a new feature to my new spam module [1] to auto-blacklist spammer IP addresses, allowing me to block comment spammers when they preview a comment and thus preventing them from ever inserting their spam into my database. I configured my comment module to "require" comment previews, and yet found that the comments were slipping past my filter. I finally realized what the spammer is doing is setting $_POST['op'] to 'Post comment', effectively bypassing the preview phase. I'm currently looking for a clean solution to this. At the moment the only idea I have is to generate a token at the preview phase, and validate the token at the post phase. Unfortunately the token would have to be stored in the databse between the preview and the post, which adds overhead. Alternatively, I've considered using a time-based hash which would constantly update depending on the time of day. This could easily be validated without storing anything in the database. If too long has gone between the preview and the post, an additional preview step would be required... The down side here is that the time-based hash would be publically available, and thus the spammer could easily duplicate it in their script. A private key could solve for that, but increases the complexity as it adds a configuration step. I have the feeling I'm missing a simpler, cleaner solution. Suggestions? [1] http://kerneltrap.org/jeremy/drupal/spam/ ------------------------------------------------------------------------ Mon, 08 Aug 2005 02:26:21 +0000 : moshe weitzman even if you get this fixed, won't these bots just add a preview step? this 'preview required' feature is designed to maintain high quality submissions by forcing users to proof read. it isn;t designed for security. i think you want to hook into comment_validate(). just add a hook here - there is already a hook_comment() waiting for you to add an operation. ------------------------------------------------------------------------ Mon, 08 Aug 2005 08:49:30 +0000 : Eaton I posted a patch a few days ago (http://drupal.org/node/28255) that adds validation and form construction hooks for comments. It's similar to the one that the captcha module uses, though it adds comment form_pre and form_post hooks instead of a single comment form hook. ------------------------------------------------------------------------ Mon, 08 Aug 2005 13:30:34 +0000 : Jeremy(a)kerneltrap.org Attachment: http://drupal.org/files/issues/comment.module_11.patch (2.5 KB) > even if you get this fixed, won't these bots just add a preview step? Eventually, yes, but it drastically changes their ability to fling spam at a site. As is, they simply have a script that shoots data out at high speed without having to wait for messages to return from the server. It is the server that is doing all the work, thus making it simple for a spammer to DoS a site. If "preview required" really meant "preview required", they would be forced to first automate clicking "preview", and then wait for a response before clicking "submit". This requires more resources on their side, and allows us to add delays after clicking "preview" (if we detect that they are a spammer) further using their resources. > this 'preview required' feature is designed to maintain high quality > submissions by forcing users to proof read. it isn;t designed for security. Regardless of the intention, I was misled to believe that configuring my site to require previews would require that all comments were first previewed. As a site administrator, I would prefer to know that "required" really means "required". > i think you want to hook into comment_validate(). just add a hook here - > there is already a hook_comment() waiting for you to add an operation. Yes and no. Ultimately yes that will work and will allow my spam module to prevent the spam from ever being posted. But it still leaves the greatest burden on the web server, instead of on the spammer. The spammer can still use a very simple script that only pushes data, and thus can generate spam at an unbelievable rapid rate. Here is an example patch to enforce "preview required". It's one idea, I'm sure there are better ones. ------------------------------------------------------------------------ Mon, 08 Aug 2005 14:01:38 +0000 : Jeremy(a)kerneltrap.org Attachment: http://drupal.org/files/issues/comment.module_12.patch (1.4 KB) Here's a second version of the patch that doesn't require any manual configuration. ------------------------------------------------------------------------ Mon, 08 Aug 2005 16:27:27 +0000 : Jose A Reyero I like this idea, and the patch looks good Still, I think it misses something, like some timestamp related hash, because once you get the hash code you can post multiple comments with that. Another problem I can think of is, what happens when a cron run happens between the preview and the post?? I'm afraid comments would get lost For this second problem, I think a key generated only once after module activation could do. About the first one....mmm... I'll sit down for a while and think..... ------------------------------------------------------------------------ Tue, 09 Aug 2005 12:27:20 +0000 : Jeremy(a)kerneltrap.org Attachment: http://drupal.org/files/issues/comment.module_13.patch (1.33 KB) > I think it misses something, like some timestamp related hash, because > once you get the hash code you can post multiple comments with that. Using a timestamp will mean that the comment form "expires". That is, if you wait too long to preview your comment, it will generate an error when you try to post. Yes, technically a spammer could post one real comment, then based on what was in the session from that they could post the same identical comment over and over, so long as it was attached to the same node. But this is not what they do, they try and spread their spam throughout your webpage. Furthermore, the spam module is perfectly capable of detecting and preventing this. > Another problem I can think of is, what happens when a cron run happens > between the preview and the post?? I'm afraid comments would get lost The key is only generated once, that's what the first test is about. In any case, in the unlikely event that the key were to change between preview and post they would simply have to post a second time. My earlier patch wasn't quite right, I was testing the token in the wrong place. This patch fixes that. BTW: This is beneficial for maintaining high quality submissions too, as prior to this change someone could: 1) enter a comment 2) press preview 3) completely change their comment (introducing a mistake) 4) press submit and the comment (mistake and all) would go into the database unpreviewed After this change: 1) enter a comment 2) press preview 3) completely change their comment (introducing a mistake) 4) press submit and they get an error because they didn't preview their changes - forcing them to preview once after any change ------------------------------------------------------------------------ Wed, 10 Aug 2005 03:50:33 +0000 : Jeremy(a)kerneltrap.org FWIW: I've been getting slammed by spam attacks this whole week. Installing this patch has made a huge difference. Well over 100 spam attempts per minute (sometimes two and three times that) and I hardly notice the spammer, whereas before it was choking my database. (Granted, the spammer has not yet upgraded his script to first preview, then submit. But even if he did it wouldn't help him as testing has verified that the new spam module would prevent the comments from ever getting to the database.) Additionally, user and anonymous (nonspam) comments continue to show up at a normal rate. ------------------------------------------------------------------------ Tue, 16 Aug 2005 14:08:04 +0000 : Jeremy(a)kerneltrap.org I would love to see _any_ discussion on this. Drupal is currently too easy to spam, with little effort on the spammer's side, and lots of resources wasted on the Drupal side. A patch like this will greatly increase the spammer's burden, and make it possible to effectively block even the most aggressive spammer attacks. ------------------------------------------------------------------------ Wed, 17 Aug 2005 16:24:04 +0000 : Jose A Reyero Well, this patch is definitely better than what we have, and would save some spam for sure. But maybe keeping track, at the session level, of generated hashes for a user, and then removing them when the comment is sent, could do the work. This way we can forget about previewing comments or not, and also the "permission" to post the comment would expire when the session expires. Any randomly generated value could do for this, no need for complex hashes, but having nid and pid in the hash would add some extra security. ------------------------------------------------------------------------ Wed, 17 Aug 2005 19:58:02 +0000 : breyten Jeremy, a big +1 on the idea, but why not generate the private key when it is actually needed (Ie, when displaying the comment form), instead of wasting a _cron() hook on it? ------------------------------------------------------------------------ Thu, 18 Aug 2005 03:20:02 +0000 : Jeremy(a)kerneltrap.org > Well, this patch is definitely better than what we have, and would save some spam for sure. It is continuing to work very well on my site, which seems to be under nearly perpetual spam attacks from multiple sources. > But maybe keeping track, at the session level, of generated hashes for a user, and then > removing them when the comment is sent, could do the work. The catch is: the key has to be something unique to the server, not guessable or learnable from the outside Simply storing the hash data in the session alone is not enough, as then the spammer could create any random data and store it in the session. That said, the hash could be generated off something other than the text of the comment as it is now, so that a preview is not required. I'll look at doing something like that and submit another patch. > This way we can forget about previewing comments or not, and also the "permission" to > post the comment would expire when the session expires. Any randomly generated value > could do for this, no need for complex hashes, but having nid and pid in the hash would > add some extra security. nid and pid alone are worthless, as they are easy to learn. The pid can always be 0 (spam is rarely attached to a pre-existing comment). The nid is obtained in the path of where the spam is being posted. The solution is a "private-key", which is what my patch adds. Then sure, hash the private key plus the nid and the pid, and you've got enough protection to prevent most spammers. To make it even more secure, automatic rey-keying could be easily accomplished. ------------------------------------------------------------------------ Thu, 18 Aug 2005 04:09:10 +0000 : Jeremy(a)kerneltrap.org Attachment: http://drupal.org/files/issues/comment.module_15.patch (1.18 KB) The attached patch: 1) gets rid of the _cron() hook 2) no longer requires that comments be previewed Prior to this patch, comment spammers were able to send data to a Drupal server acting as though they'd filled out a comment form and pressed submit. As they didn't actually use the form, they could submit spam comments at an obscene rate. With this patch, comment spammers will have to actually load the form, enter text, and press submit. Yes, that can still be automated, but it takes much more work and slows them down, as they have to wait for the entry form to load each time. Unfortunately a spammer could manually submit one comment, then re-use that same session info over and over to attach repeated spam comments to the same node. Such an attempt would be detected and blocked by the spam module if enabled, but again such a session re-use attack could be done without loading the form each time. Fortunately there is much less gain for a spammer to submit 100 spam comments on the same page, versus submitting 100 spam comments each on a different page as they do now. Ideas to improve upon this concept include: - re-key every day or week, changing the private key regularly to be sure it couldn't ever be permanently cracked - add a key table, and generate a unique key for every comment form. essentially, upon comment form creation generate a random key which is stored both in a database table and in the session. when a comment is submited, look for the key from the session in the database table, if a match is found delete it from the database table and post the comment. this would prevent session re-use, but adds overhead. i don't know if it's worth it, perhaps as an external module if the hooks were available. ------------------------------------------------------------------------ Fri, 19 Aug 2005 18:55:11 +0000 : drumm <?php form_set_error('error', t('Validation error, please be sure cookies are enabled on your browser.')); ?> form_set_error [2]()'s fist argument should be the name of a form field, not 'error.' Using (..., 'error') would be better in this case. And the actual message needs work. Since this is a hidden field I don't think it has anything to do with cookies. [2] http://drupaldocs.org/api/head/function/form_set_error

1 0

[drupal-devel] [bug] comment preview "Required" is easily bypassed
by drumm 19 Aug '05

19 Aug '05

Issue status update for http://drupal.org/node/28420 Post a follow up: http://drupal.org/project/comments/add/28420 Project: Drupal Version: cvs Component: comment.module Category: bug reports Priority: normal Assigned to: Jeremy(a)kerneltrap.org Reported by: Jeremy(a)kerneltrap.org Updated by: drumm Status: patch (code needs review) <?php form_set_error('error', t('Validation error, please be sure cookies are enabled on your browser.')); ?> form_set_error [1]()'s fist argument should be the name of a form field, not 'error.' Using (..., 'error') would be better in this case. And the actual message needs work. Since this is a hidden field I don't think it has anything to do with cookies. [1] http://drupaldocs.org/api/head/function/form_set_error drumm Previous comments: ------------------------------------------------------------------------ Mon, 08 Aug 2005 01:55:34 +0000 : Jeremy(a)kerneltrap.org Setting "Preview comment" to "Required" does not strictly require that the comment be previewed first. This is being abused by spammers to quickly and efficiently post spam comments. I discovered this after I added a new feature to my new spam module [2] to auto-blacklist spammer IP addresses, allowing me to block comment spammers when they preview a comment and thus preventing them from ever inserting their spam into my database. I configured my comment module to "require" comment previews, and yet found that the comments were slipping past my filter. I finally realized what the spammer is doing is setting $_POST['op'] to 'Post comment', effectively bypassing the preview phase. I'm currently looking for a clean solution to this. At the moment the only idea I have is to generate a token at the preview phase, and validate the token at the post phase. Unfortunately the token would have to be stored in the databse between the preview and the post, which adds overhead. Alternatively, I've considered using a time-based hash which would constantly update depending on the time of day. This could easily be validated without storing anything in the database. If too long has gone between the preview and the post, an additional preview step would be required... The down side here is that the time-based hash would be publically available, and thus the spammer could easily duplicate it in their script. A private key could solve for that, but increases the complexity as it adds a configuration step. I have the feeling I'm missing a simpler, cleaner solution. Suggestions? [2] http://kerneltrap.org/jeremy/drupal/spam/ ------------------------------------------------------------------------ Mon, 08 Aug 2005 02:26:21 +0000 : moshe weitzman even if you get this fixed, won't these bots just add a preview step? this 'preview required' feature is designed to maintain high quality submissions by forcing users to proof read. it isn;t designed for security. i think you want to hook into comment_validate(). just add a hook here - there is already a hook_comment() waiting for you to add an operation. ------------------------------------------------------------------------ Mon, 08 Aug 2005 08:49:30 +0000 : Eaton I posted a patch a few days ago (http://drupal.org/node/28255) that adds validation and form construction hooks for comments. It's similar to the one that the captcha module uses, though it adds comment form_pre and form_post hooks instead of a single comment form hook. ------------------------------------------------------------------------ Mon, 08 Aug 2005 13:30:34 +0000 : Jeremy(a)kerneltrap.org Attachment: http://drupal.org/files/issues/comment.module_11.patch (2.5 KB) > even if you get this fixed, won't these bots just add a preview step? Eventually, yes, but it drastically changes their ability to fling spam at a site. As is, they simply have a script that shoots data out at high speed without having to wait for messages to return from the server. It is the server that is doing all the work, thus making it simple for a spammer to DoS a site. If "preview required" really meant "preview required", they would be forced to first automate clicking "preview", and then wait for a response before clicking "submit". This requires more resources on their side, and allows us to add delays after clicking "preview" (if we detect that they are a spammer) further using their resources. > this 'preview required' feature is designed to maintain high quality > submissions by forcing users to proof read. it isn;t designed for security. Regardless of the intention, I was misled to believe that configuring my site to require previews would require that all comments were first previewed. As a site administrator, I would prefer to know that "required" really means "required". > i think you want to hook into comment_validate(). just add a hook here - > there is already a hook_comment() waiting for you to add an operation. Yes and no. Ultimately yes that will work and will allow my spam module to prevent the spam from ever being posted. But it still leaves the greatest burden on the web server, instead of on the spammer. The spammer can still use a very simple script that only pushes data, and thus can generate spam at an unbelievable rapid rate. Here is an example patch to enforce "preview required". It's one idea, I'm sure there are better ones. ------------------------------------------------------------------------ Mon, 08 Aug 2005 14:01:38 +0000 : Jeremy(a)kerneltrap.org Attachment: http://drupal.org/files/issues/comment.module_12.patch (1.4 KB) Here's a second version of the patch that doesn't require any manual configuration. ------------------------------------------------------------------------ Mon, 08 Aug 2005 16:27:27 +0000 : Jose A Reyero I like this idea, and the patch looks good Still, I think it misses something, like some timestamp related hash, because once you get the hash code you can post multiple comments with that. Another problem I can think of is, what happens when a cron run happens between the preview and the post?? I'm afraid comments would get lost For this second problem, I think a key generated only once after module activation could do. About the first one....mmm... I'll sit down for a while and think..... ------------------------------------------------------------------------ Tue, 09 Aug 2005 12:27:20 +0000 : Jeremy(a)kerneltrap.org Attachment: http://drupal.org/files/issues/comment.module_13.patch (1.33 KB) > I think it misses something, like some timestamp related hash, because > once you get the hash code you can post multiple comments with that. Using a timestamp will mean that the comment form "expires". That is, if you wait too long to preview your comment, it will generate an error when you try to post. Yes, technically a spammer could post one real comment, then based on what was in the session from that they could post the same identical comment over and over, so long as it was attached to the same node. But this is not what they do, they try and spread their spam throughout your webpage. Furthermore, the spam module is perfectly capable of detecting and preventing this. > Another problem I can think of is, what happens when a cron run happens > between the preview and the post?? I'm afraid comments would get lost The key is only generated once, that's what the first test is about. In any case, in the unlikely event that the key were to change between preview and post they would simply have to post a second time. My earlier patch wasn't quite right, I was testing the token in the wrong place. This patch fixes that. BTW: This is beneficial for maintaining high quality submissions too, as prior to this change someone could: 1) enter a comment 2) press preview 3) completely change their comment (introducing a mistake) 4) press submit and the comment (mistake and all) would go into the database unpreviewed After this change: 1) enter a comment 2) press preview 3) completely change their comment (introducing a mistake) 4) press submit and they get an error because they didn't preview their changes - forcing them to preview once after any change ------------------------------------------------------------------------ Wed, 10 Aug 2005 03:50:33 +0000 : Jeremy(a)kerneltrap.org FWIW: I've been getting slammed by spam attacks this whole week. Installing this patch has made a huge difference. Well over 100 spam attempts per minute (sometimes two and three times that) and I hardly notice the spammer, whereas before it was choking my database. (Granted, the spammer has not yet upgraded his script to first preview, then submit. But even if he did it wouldn't help him as testing has verified that the new spam module would prevent the comments from ever getting to the database.) Additionally, user and anonymous (nonspam) comments continue to show up at a normal rate. ------------------------------------------------------------------------ Tue, 16 Aug 2005 14:08:04 +0000 : Jeremy(a)kerneltrap.org I would love to see _any_ discussion on this. Drupal is currently too easy to spam, with little effort on the spammer's side, and lots of resources wasted on the Drupal side. A patch like this will greatly increase the spammer's burden, and make it possible to effectively block even the most aggressive spammer attacks. ------------------------------------------------------------------------ Wed, 17 Aug 2005 16:24:04 +0000 : Jose A Reyero Well, this patch is definitely better than what we have, and would save some spam for sure. But maybe keeping track, at the session level, of generated hashes for a user, and then removing them when the comment is sent, could do the work. This way we can forget about previewing comments or not, and also the "permission" to post the comment would expire when the session expires. Any randomly generated value could do for this, no need for complex hashes, but having nid and pid in the hash would add some extra security. ------------------------------------------------------------------------ Wed, 17 Aug 2005 19:58:02 +0000 : breyten Jeremy, a big +1 on the idea, but why not generate the private key when it is actually needed (Ie, when displaying the comment form), instead of wasting a _cron() hook on it? ------------------------------------------------------------------------ Thu, 18 Aug 2005 03:20:02 +0000 : Jeremy(a)kerneltrap.org > Well, this patch is definitely better than what we have, and would save some spam for sure. It is continuing to work very well on my site, which seems to be under nearly perpetual spam attacks from multiple sources. > But maybe keeping track, at the session level, of generated hashes for a user, and then > removing them when the comment is sent, could do the work. The catch is: the key has to be something unique to the server, not guessable or learnable from the outside Simply storing the hash data in the session alone is not enough, as then the spammer could create any random data and store it in the session. That said, the hash could be generated off something other than the text of the comment as it is now, so that a preview is not required. I'll look at doing something like that and submit another patch. > This way we can forget about previewing comments or not, and also the "permission" to > post the comment would expire when the session expires. Any randomly generated value > could do for this, no need for complex hashes, but having nid and pid in the hash would > add some extra security. nid and pid alone are worthless, as they are easy to learn. The pid can always be 0 (spam is rarely attached to a pre-existing comment). The nid is obtained in the path of where the spam is being posted. The solution is a "private-key", which is what my patch adds. Then sure, hash the private key plus the nid and the pid, and you've got enough protection to prevent most spammers. To make it even more secure, automatic rey-keying could be easily accomplished. ------------------------------------------------------------------------ Thu, 18 Aug 2005 04:09:10 +0000 : Jeremy(a)kerneltrap.org Attachment: http://drupal.org/files/issues/comment.module_15.patch (1.18 KB) The attached patch: 1) gets rid of the _cron() hook 2) no longer requires that comments be previewed Prior to this patch, comment spammers were able to send data to a Drupal server acting as though they'd filled out a comment form and pressed submit. As they didn't actually use the form, they could submit spam comments at an obscene rate. With this patch, comment spammers will have to actually load the form, enter text, and press submit. Yes, that can still be automated, but it takes much more work and slows them down, as they have to wait for the entry form to load each time. Unfortunately a spammer could manually submit one comment, then re-use that same session info over and over to attach repeated spam comments to the same node. Such an attempt would be detected and blocked by the spam module if enabled, but again such a session re-use attack could be done without loading the form each time. Fortunately there is much less gain for a spammer to submit 100 spam comments on the same page, versus submitting 100 spam comments each on a different page as they do now. Ideas to improve upon this concept include: - re-key every day or week, changing the private key regularly to be sure it couldn't ever be permanently cracked - add a key table, and generate a unique key for every comment form. essentially, upon comment form creation generate a random key which is stored both in a database table and in the session. when a comment is submited, look for the key from the session in the database table, if a match is found delete it from the database table and post the comment. this would prevent session re-use, but adds overhead. i don't know if it's worth it, perhaps as an external module if the hooks were available.

1 0