- Development - lists.drupal.org

[drupal-devel] Fwd: Bayosphere
by K B 16 May '05

16 May '05

Since Dan Gillmor is well known to the Slashdot crowd, and his articles are featured there every now and then, I submitted the story there. So, there is a chance for drupal.org being slashdotted if the article gets accepted. Dries: this would be a good test for the performance patches you were working on :-) ---------- Forwarded message ---------- From: Dries Buytaert <dries(a)buytaert.net> Date: May 15, 2005 2:26 PM Subject: Re: [drupal-devel] Bayosphere To: K B <kbahey(a)gmail.com> Thanks! On 15 May 2005, at 19:37, K B wrote: > I wrote a small article in the forums and promoted it to the front > page. > > If anyone wants to flesh it out, please either edit it directly, or if > you do not have the permissions, reply to this with more info that I > can add. -- Dries Buytaert :: http://www.buytaert.net/

2 1

[drupal-devel] Chicago
by Dries Buytaert 16 May '05

16 May '05

This message is slightly off-topic but I just wanted to let you know that I'll be in Chicago, IL from June 10th to June 17th. If you live in Chicago and want to catch up, drop me an e-mail. Looks like all hotels in downtown Chicago are fully booked. :( If you're familiar with Chicago or if you can recommend an affordable hotel that offers a good connection (public transport) to downtown Chicago ('The Loop, Grand Park'), please let me know. Thanks. -- Dries Buytaert :: http://www.buytaert.net/

2 1

[drupal-devel] [feature] are spaces allowed in passwords though?
by jakeg 15 May '05

15 May '05

Issue status update for http://drupal.org/node/11791 Project: Drupal Version: 4.6.0 Component: user.module Category: feature requests Priority: normal Assigned to: Anonymous Reported by: kps Updated by: jakeg Status: patch I am +10 for this... but so far have leading/trailing spaces been allowed in passwords? If they have, then this causes an obvious problem - users with existing leading/trailing spaces in their passwords will no longer be able to login. You can't pull the password hash out of the database and trim that... that's not how hashes work. If leading/trailing spaces *have* been allowed in the past, then the obvious work around would be: if someone tries to login and enters a leading/trailing space and the login fails, ask them whether their password has one. If it does, get them to reset their password then choose a new one. Of course you also have to ensure that when users setup new passwords/edit their passwords the password hash is made from a trimmed version of their password. You don't have to inform them that its been trimmed. Its irrelevant to them. You just do it. jakeg Previous comments: ------------------------------------------------------------------------ October 20, 2004 - 17:29 : kps They create an account. They get a password by email. They select the password plus the preceding blank or following newline. They paste it into the 'Password' box. They can't log in. They write to me complaining. I get tired of complaints and patch user.module to strip leading and trailing blanks. ------------------------------------------------------------------------ October 20, 2004 - 17:39 : kps Attachment: http://drupal.org/files/issues/user.module_0.patch (766 bytes) I claim I'm not *really* dumber myself. Drupal timed out on me.... ------------------------------------------------------------------------ October 20, 2004 - 18:02 : moshe weitzman makes sense to me ------------------------------------------------------------------------ October 20, 2004 - 21:54 : rkendall +1 FWIW - I could see this being useful, and don't really see any practical drawbacks. I does smell of hack, but is that really an issue? I mean, it might not be the 'done' thing to mess with passwords, however, I can't imagine any regular user intentionally putting leading or trailing whitespace on a password, but I can imagine it being done accidentally fairly often (either when setting a password, or when logging in). To be consistent, it would make sense to trim passwords when setting them as well. ------------------------------------------------------------------------ October 20, 2004 - 23:09 : Bèr Kessels -1 from me. I think we should nstart meddling with passwords by trim()ing them. If you have dumb users, you should fix it in the mail that is send to them. That is really easy. For example: add a word after the passwords: your password is WKDKAFAJ34 please mind capital letters. or so. Bèr ------------------------------------------------------------------------ October 20, 2004 - 23:36 : Steven I don't agree with Bèr... copy/pasting is a fiddly business, especially because when pasting a password all you see is asterisks and you don't notice if there is an extra character. Trimming the password won't hurt, I very much doubt that there are people who consciously use a space at the beginning or end of their password. +1 on trimming, it is a usability improvement. ------------------------------------------------------------------------ October 20, 2004 - 23:51 : chx +1 here. Bèr, if you write a sentence around it, you can still copy-paste the whitespace before and after it. ------------------------------------------------------------------------ October 21, 2004 - 01:18 : Uwe Hermann I'm unsure if I really like this, but if this really gets applied, please make it a configuration option. Do not hardcode it for all Drupal installations. Thanks, Uwe. ------------------------------------------------------------------------ October 21, 2004 - 05:06 : robertDouglass +1 I can confirm from my logs that the typical user bungles initial login 1-4 times, with each bungled attempt making an all-out failure more likely. Not only am I in favor of trimming, I am much in favor of investigating other means of initial password assignment like on the initial register form or by generating a unique URL that gets mailed and only has to be clicked or pasted into the browser address bar. Sorry if those alternatives have already been widely discussed here. ------------------------------------------------------------------------ October 21, 2004 - 06:21 : stefan nagtegaal I am all for trimming the spaces in front of the username and after it, but I am absoklutely against another option for such thing. IMO this is only a usability improvement and it is not needed to make it a configurable behaviour.. We have enough options already, and if you'll ask me I'll tell you that we need less options instead of more.. ------------------------------------------------------------------------ October 21, 2004 - 09:58 : Bèr Kessels Admitted: no one will conciously add spaces to his or her passwords. So i will pull out my -1 hereby. but -1 for making ot an option. As steef syis: its useability. I still stick to the -1 for applying this specific patch. I beleive that we should be 1) consitant, and strip /all/ password whitespace. 2) use drupal_set_message() to warn people when whitespace was stripped. And so to educate users to be aware of whitespace when copying passwords. ------------------------------------------------------------------------ October 21, 2004 - 11:39 : kps My proposed patch also strips white space when the user changes the password, so it's not possible to create an unusable password. I agree that a warning message would be a good idea. ------------------------------------------------------------------------ October 21, 2004 - 16:10 : Chris Johnson Part of the problem with users copying and pasting extraneous whitespace around passwords (or userrnames) is the inconsistent behavior in GUI windowing environments. That is to say, in some applications in some GUIs, double-clicking on a word will copy the word and its surrounding white space, for example. In others, it will not. One might think it would be visibly obvious that the surrounding white space was included in the copy operation, but that's not so. The words might be displayed in a very small, proportional font (and further might be justified or kerned in unpredictable fashion) which make it hard to see just where the highlighted copied text begins and ends. This is under the control of the application and the user. Or, the user might think logically that since all he or she wanted was the word, and likewise that "whitespace" is irrelevant, the user may assume that what was copied was only the desired word even if they can visibly see that the adjacent spaces are highlighted. I'm well aware of this behavior myself and even I sometimes get tripped up when copying and pasting bits of data here and there by the occasional undesired white space. My vote would be to always trim leading and trailing white space, and to document in the help that such white space is not valid in passwords. ------------------------------------------------------------------------ March 13, 2005 - 18:25 : killes(a)www.drop.org The patch still applies. Apart from Ber everybody liked it. I also like it. ------------------------------------------------------------------------ March 14, 2005 - 13:42 : Bèr Kessels "apart from Ber everyone liked it", so here a short comment: I still beleive modifying what a user inserts should never be modified. But the current situation is far worse, so I guess it *gets a +1* from me now too :). ------------------------------------------------------------------------ March 15, 2005 - 18:03 : tangent RE #11, if whitespace is not checked for in the password validation it should be. Preventing whitespace from being used is preferable to simply stripping it. ------------------------------------------------------------------------ April 29, 2005 - 19:18 : kps Attachment: http://drupal.org/files/issues/password-trim.patch (951 bytes) Patch against 4.6 attached.

1 0

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

15 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: ec Status: patch 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> ec Previous comments: ------------------------------------------------------------------------ September 16, 2004 - 14: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 - 14:47 : ccourtne Dag nabit. Replace $source = realpath($source); with $source = realpath(dirname($source)); Craig ------------------------------------------------------------------------ September 16, 2004 - 14: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 - 02:34 : ccourtne Attachment: http://drupal.org/files/issues/checklocation.patch (666 bytes) Here is the patch. ------------------------------------------------------------------------ February 23, 2005 - 01: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 - 18:32 : killes(a)www.drop.org Still applies. ------------------------------------------------------------------------ April 18, 2005 - 12:10 : ec Is this patch still to be use with actual Drupal 4.6.0 ? Thanks. eric ------------------------------------------------------------------------ May 7, 2005 - 11: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 - 11:36 : Wes Cowley Meant to add, that was a 4.6.0 Linux installaion that this patch cleared up. ------------------------------------------------------------------------ May 14, 2005 - 08: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 - 09: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 - 09: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 - 12:51 : Dries Don't we use file_create_path for that (it appends the 'files'-bit)?

1 0

[drupal-devel] Hello all!
by Alexander Simonov 15 May '05

15 May '05

Hello all! I working in GeeksForLess Ukrainian Operatop Company, parthner of Hostopia.com. I was born 24 March 1985 in Nikolaev, Ukraine. I am a PHP developer. I well know php, perl, bash, pascal and others. I want help the this cool project :) I think i may help the project! I am a fanatic of programming :) -- WBR, Alexander Simonov (AS1199-UANIC | DEVL-UANIC) Programmer, European Department, Hostopia.com, Inc. (http://hostopia.com) Ukrainian Gentoo Community Domain Coordinator Jabber-Id: devil(a)jabber.gentoo.org.ua E-Mail: devil(a)gentoo.org.ua

1 0

[drupal-devel] [bug] Do not execute functions in include files
by chx 15 May '05

15 May '05

Issue status update for http://drupal.org/node/18213 Project: Drupal Version: cvs Component: base system Category: bug reports Priority: normal Assigned to: chx Reported by: killes(a)www.drop.org Updated by: chx Status: patch A very stupid bug related to variable init is fixed and I am sync'd to HEAD, so timer_init('page') is called. chx Previous comments: ------------------------------------------------------------------------ March 2, 2005 - 00:09 : killes(a)www.drop.org Drupal currently executes functions in include files. This is very annoying if you want to include files from external scripts such as update scripts or other scripts that want to use Drupal as a framework. Offending files are: database.inc: db_set_active(); session.inc: session_set_save_handler("sess_open", "sess_close", "sess_read", "sess_write", "sess_destroy", "sess_gc"); session_start(); common.inc: A bunch of stuff at the bottom. All this should be moved into a start.inc file. ------------------------------------------------------------------------ March 27, 2005 - 08:44 : adrian I haven't done this recently, but back in 4.4 era I attempted something similar to this for the install api. A _lot_ of modifications were required to be able to use (for instance) the theme api without needing to have a database connection active. ------------------------------------------------------------------------ March 27, 2005 - 08:55 : adrian It's definately not a simple problem. For instance.. the db connection needs to be started during bootstrap, and during normal execution. I think the better idea is to include a DRUPAL_INIT constant we can check before executing the function. (or a DRUPAL_NO_INIT .. i'm not picky). ------------------------------------------------------------------------ April 28, 2005 - 23:53 : killes(a)www.drop.org Here's an old patch by me that illustrates what I want to do. http://lists.drupal.org/archives/drupal-devel/2005-03/txtq23pAcHATw.txt Instead of putting the stuff into index.php, alternative file names need to be found. ------------------------------------------------------------------------ May 4, 2005 - 19:36 : chx Attachment: http://drupal.org/files/issues/boot.patch (6.83 KB) Well, I have written something to address the issue. Now you can include everything to your hearts content just include init.inc as well and do an appropriate drupal_bootstrap. Alas, ATM database and bootstrap is very interwined. This interdependency could be obliterated if we'd not use variable_get('dev_query') in database.*.inc. cvs diff -u -N -F^f against cvs.drupal.org as CVSROOT failed to include to include the two new files, so I'll include them as followups. ------------------------------------------------------------------------ May 4, 2005 - 19:37 : chx Attachment: http://drupal.org/files/issues/boot_0.patch (10.31 KB) Hm, settings.php changes were ommited. ------------------------------------------------------------------------ May 4, 2005 - 19:37 : chx Attachment: http://drupal.org/files/issues/init.inc (3.46 KB) ------------------------------------------------------------------------ May 4, 2005 - 19:38 : chx Attachment: http://drupal.org/files/issues/settings_ini_set.php (850 bytes) ------------------------------------------------------------------------ May 4, 2005 - 19:44 : chx Attachment: http://drupal.org/files/issues/boot_1.patch (14.49 KB) Following advice from darix I have now created one patch. Still, I'd like to know how could I do this with cvs. ------------------------------------------------------------------------ May 4, 2005 - 20:01 : chx Attachment: http://drupal.org/files/issues/boot_2.patch (14.48 KB) Steef found that I had $$ in settings.php. He also asked what's this good for. Several things, but most advantages come when you use only parts of Drupal. If you want use, say, only our forms functions then now you can include('common.inc'); without side effects. If you need the database layer, you do a include('init.inc') and call drupal_bootstrap('database') ------------------------------------------------------------------------ May 5, 2005 - 23:03 : chx Attachment: http://drupal.org/files/issues/boot_3.patch (17.98 KB) The database layer is now totally independent of other parts of Drupal.

1 0

[drupal-devel] Bayosphere
by Dries Buytaert 15 May '05

15 May '05

http://bayosphere.com/node/28 http://bayosphere.com/why-drupal Might be worth a main page item! -- Dries Buytaert :: http://www.buytaert.net/

4 3

[drupal-devel] Cleaner Directory structure
by Jeremy Epstein 15 May '05

15 May '05

On 5/12/05, K B <kbahey(a)gmail.com> wrote: > All this does not need to go in CVS as it is. The CVS can largely > remain as it is. What the developers see when committing code and what > the end user (site admin) sees are two different things. > > The script that creates the tarball can deal with all this and > everything else remains the same. Not sure that I understand you there. The current situation in Drupal is that the contents of the tarball are exactly the same as the contents of CVS (except that CVS is more up-to-date). Are you saying that this will no longer be the case? Do you mean that checking out Drupal core will now have a different result to downloading a tarball of Drupal core? My understanding was that the Drupal core CVS repository would have everything under /public_html, and that the Drupal core tarball would have the same (this is how it is now). Why would you want to change this? Doing so would only confuse people. Jaza.

6 8

[drupal-devel] Idea - move help text out of code into database
by puregin 15 May '05

15 May '05

I'm going to re-float here on both lists the idea of having each module's help texts provided within the Drupal database, as opposed to being hardcoded in. Advantages: the help text documentation would be - easier to maintain - easier to translate - easy to tailor to user's experience level and preferences (tag each helptext with a 'User experience level" vocabulary and select the text according to the user's preferences) I think it would make the code easier to maintain also. Code review and documentation review could occur independently. Comments? Djun

7 9

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

15 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: Dries Status: patch Don't we use file_create_path for that (it appends the 'files'-bit)? Dries Previous comments: ------------------------------------------------------------------------ September 16, 2004 - 15: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 - 15:47 : ccourtne Dag nabit. Replace $source = realpath($source); with $source = realpath(dirname($source)); Craig ------------------------------------------------------------------------ September 16, 2004 - 15: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 - 03:34 : ccourtne Attachment: http://drupal.org/files/issues/checklocation.patch (666 bytes) Here is the patch. ------------------------------------------------------------------------ February 23, 2005 - 02: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 - 19:32 : killes(a)www.drop.org Still applies. ------------------------------------------------------------------------ April 18, 2005 - 13:10 : ec Is this patch still to be use with actual Drupal 4.6.0 ? Thanks. eric ------------------------------------------------------------------------ May 7, 2005 - 12: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 - 12:36 : Wes Cowley Meant to add, that was a 4.6.0 Linux installaion that this patch cleared up. ------------------------------------------------------------------------ May 14, 2005 - 09: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 - 10: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 - 10: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.

1 0