- Development - lists.drupal.org

[drupal-devel] [feature] Allow annoymous users to log in on access denied
by willmoy 01 Aug '05

01 Aug '05

Issue status update for http://drupal.org/node/24050 Post a follow up: http://drupal.org/project/comments/add/24050 Project: Drupal Version: cvs Component: user system Category: feature requests Priority: normal Assigned to: gordon Reported by: gordon Updated by: willmoy Status: patch (code needs review) If we implement an option for user/login, it's going to be reasonable for someone to request an option for user/register (please register to gain access to premium content/full articles/whatever). Same again for a dual login/register page. I'm working on a site with most content behind the login, and I've been struck by how unenticing user/login and user/register are anyway. Perhaps adding to the handbook a selection of nicely done, helpful custom 403s (that maybe tie in to drupal themes) with a good explanation of how to use them would provide the functionality and help people make more attractive sites. The form description could include a link. The custom 403 on that site shows 'You do not have permission to view this page' if the visitor is logged in or 'You need to log in' if it's an anonymous visitor. If they log in, they are sent straight to whatever page they wanted in the first place. I'd paste it here, but it wouldn't survive the input check. More than happy to share it, though. willmoy Previous comments: ------------------------------------------------------------------------ Wed, 01 Jun 2005 05:51:25 +0000 : gordon Attachment: http://drupal.org/files/issues/denied_login.diff (1.41 KB) If the user is anonymous, then the user will be presented with the login page 'user/login' instead of a the 403 default page. If the user then logins in and has access to the page they will then get redirected to the page they were trying to access. If the user is already logged in then they will get the defined 403 page. With the standard system you cannot just set user/login as the 403 page as you will not be redirected to the page that you were originally requesting, but instead to the user page. ------------------------------------------------------------------------ Sun, 05 Jun 2005 00:22:06 +0000 : gordon Attachment: http://drupal.org/files/issues/denied_login2.patch (3.43 KB) here is a newer version of the patch which adds an option to admin/settings page so this functionality can be turned off and on. ------------------------------------------------------------------------ Sun, 05 Jun 2005 01:38:39 +0000 : moshe weitzman I have been wanting this since i first saw drupal (i.e. a long time). +1 ------------------------------------------------------------------------ Sun, 05 Jun 2005 10:29:05 +0000 : Dries Because the 403 page is configurable, this is already possible. This patch only makes it more convenient. I tempted to say: "Won't commit, but let's extend the form description a bit so it is clear this is possible.". That or we add a link to the login page (without the extra setting), cfr. to what the comment module does. ------------------------------------------------------------------------ Sun, 05 Jun 2005 12:06:40 +0000 : moshe weitzman dries - upon executing the 403 handler, the original $_GET['q'] is lost. That means that we cannot redirect to the destination page after login and thats one of the main benefits of this patch. ------------------------------------------------------------------------ Sun, 05 Jun 2005 12:40:57 +0000 : gordon Yes you can use the user/login link, but once you login you get the user page and not the page you were triing to get to. Also if you are logged in you will still get the user/login page when really you should get the custom access denied page. ------------------------------------------------------------------------ Sun, 05 Jun 2005 20:57:20 +0000 : slower What version of Drupal is this for? I'm using 4.5. ------------------------------------------------------------------------ Sun, 05 Jun 2005 23:47:19 +0000 : gordon It is for cvs (4.7) I would have to rewrite it if I was to port it back to 4.5 ------------------------------------------------------------------------ Mon, 13 Jun 2005 23:49:02 +0000 : gordon Dries, What is the verdict on this patch. I have found no way of prompting anonymous users to login and continue seemlessly without this patch. Please correct me if I am wrong, as this is some functionality that I require. ------------------------------------------------------------------------ Tue, 14 Jun 2005 01:00:12 +0000 : neofactor Glad to see it... I had always just added the following custom pages: http://neofactor.com/error403 (with a login link) http://neofactor.com/error404 (Adding the auto search) My 403's are only for non-members and all members have the same access. I use PHP to control groups differently for lots of different clients, so this works out well form me. The auto redirect function is nice.... keeping the user's initial request in place. hey.... When is Drupal going to add images to pages at core? Visual appeal.... It would be great if menu items and other areas started to do this... then people could just swap them out. Just a wish list. ;) ------------------------------------------------------------------------ Tue, 14 Jun 2005 03:02:01 +0000 : gordon Just adding the pages does work, but does not give the effect that I need. You can always use the login box on the sidebar, which will do the same thing. You said that the 403's aren't used to logged in users as they have the same privledge, But not everyone has the same privledge on your site (unless everyone has the same rights as user 1 ;-)) So what if a user who is already logged in goes to /admin you do not want to tell them that they need to login to get to the admin page, you want to send them to a big go away page. ------------------------------------------------------------------------ Tue, 19 Jul 2005 11:34:19 +0000 : jjeff Before I saw this thread, I posted another take on this bug at http://drupal.org/node/26659. It explains the problem a little more in-depth. Here's the thing: What makes Drupal sites look like Drupal sites is that they've got a login/password box on every page until the user is logged in. For Drupal to become a mature platform, it's going to need to move away from dependence on this crutch. Drupal should provide the infrastructure to allow the option of a simple "Login/Register" link. However, if a user gets an access denied message, they should be prompted to log in. As it is, the best that you can do after login is direct them back to the node that defines the "Access Denied" message. This is more than just confusing for the user. It's downright wrong! Dries, please reconsider this patch and/or some variation that solves this problem. It is essential for all current versions of Drupal. Thanks, Jeff ------------------------------------------------------------------------ Tue, 19 Jul 2005 11:52:21 +0000 : Kobus In concept, a definitive +1 from me. Especially the mention that the login box does not even display unless the user has to log in. I have started to remove the block completely and put it in a menu somewhere else so that it is not so obtrusive. For a commercial site, the exaggerated login page makes it look "as if you have something to hide". Not good. Regards, ------------------------------------------------------------------------ Mon, 25 Jul 2005 14:57:15 +0000 : Steven You say you can't use a custom 403 page because it doesn't know where it came from... so, why not set a destination parameter instead? I think all that needs to be done is set $_REQUEST['destination'] = $_GET['q'] before calling menu_set_active_item() in drupal_access_denied(). Probably the same for drupal_not_found(). The destination is then picked up by the login-block which adds destination=drupal_get_destination() in the form's action. ------------------------------------------------------------------------ Mon, 01 Aug 2005 02:59:07 +0000 : gordon The login block already picks up the correct page. but there are some people who do not want to have a login block on the site, but use a link to the login page to allow a user to login. Also having getting users to enter in PHP code to solve this problem IMO makes Drupal very unfriendly (in this area) as it will require the admin to know a lot more about PHP than they should need to. I have still not been able to user standard configuration options to achieve this.

1 0

[drupal-devel] [feature] Per-User Input-Format Preferences
by jchris 01 Aug '05

01 Aug '05

Issue status update for http://drupal.org/node/26036 Project: Drupal Version: 4.6.1 Component: filter.module Category: feature requests Priority: normal Assigned to: Anonymous Reported by: jchris Updated by: jchris Status: patch Attachment: http://drupal.org/files/issues/filter.module_9.patch (1.61 KB) Here's a patch to filter.module that allows users to set their preferred input format, when multiple formats are available. A selection of available formats is added to the user-account editing page. The user's selection is persistent and is used to initialize the input-format selector on the node-editing pages. This patch requires an addition of an 'input_format' field to the {users} table: alter table users add input_format int(4) NOT NULL default '0'; I'm not 100% sure I did this correctly. I'm no PHP coder. Anyway, it seems to work. Patch file is attached. Enjoy. jchris

3 4

[drupal-devel] [feature] Allow annoymous users to log in on access denied
by gordon 01 Aug '05

01 Aug '05

Issue status update for http://drupal.org/node/24050 Post a follow up: http://drupal.org/project/comments/add/24050 Project: Drupal Version: cvs Component: user system Category: feature requests Priority: normal Assigned to: gordon Reported by: gordon Updated by: gordon Status: patch (code needs review) The login block already picks up the correct page. but there are some people who do not want to have a login block on the site, but use a link to the login page to allow a user to login. Also having getting users to enter in PHP code to solve this problem IMO makes Drupal very unfriendly (in this area) as it will require the admin to know a lot more about PHP than they should need to. I have still not been able to user standard configuration options to achieve this. gordon Previous comments: ------------------------------------------------------------------------ Wed, 01 Jun 2005 05:51:25 +0000 : gordon Attachment: http://drupal.org/files/issues/denied_login.diff (1.41 KB) If the user is anonymous, then the user will be presented with the login page 'user/login' instead of a the 403 default page. If the user then logins in and has access to the page they will then get redirected to the page they were trying to access. If the user is already logged in then they will get the defined 403 page. With the standard system you cannot just set user/login as the 403 page as you will not be redirected to the page that you were originally requesting, but instead to the user page. ------------------------------------------------------------------------ Sun, 05 Jun 2005 00:22:06 +0000 : gordon Attachment: http://drupal.org/files/issues/denied_login2.patch (3.43 KB) here is a newer version of the patch which adds an option to admin/settings page so this functionality can be turned off and on. ------------------------------------------------------------------------ Sun, 05 Jun 2005 01:38:39 +0000 : moshe weitzman I have been wanting this since i first saw drupal (i.e. a long time). +1 ------------------------------------------------------------------------ Sun, 05 Jun 2005 10:29:05 +0000 : Dries Because the 403 page is configurable, this is already possible. This patch only makes it more convenient. I tempted to say: "Won't commit, but let's extend the form description a bit so it is clear this is possible.". That or we add a link to the login page (without the extra setting), cfr. to what the comment module does. ------------------------------------------------------------------------ Sun, 05 Jun 2005 12:06:40 +0000 : moshe weitzman dries - upon executing the 403 handler, the original $_GET['q'] is lost. That means that we cannot redirect to the destination page after login and thats one of the main benefits of this patch. ------------------------------------------------------------------------ Sun, 05 Jun 2005 12:40:57 +0000 : gordon Yes you can use the user/login link, but once you login you get the user page and not the page you were triing to get to. Also if you are logged in you will still get the user/login page when really you should get the custom access denied page. ------------------------------------------------------------------------ Sun, 05 Jun 2005 20:57:20 +0000 : slower What version of Drupal is this for? I'm using 4.5. ------------------------------------------------------------------------ Sun, 05 Jun 2005 23:47:19 +0000 : gordon It is for cvs (4.7) I would have to rewrite it if I was to port it back to 4.5 ------------------------------------------------------------------------ Mon, 13 Jun 2005 23:49:02 +0000 : gordon Dries, What is the verdict on this patch. I have found no way of prompting anonymous users to login and continue seemlessly without this patch. Please correct me if I am wrong, as this is some functionality that I require. ------------------------------------------------------------------------ Tue, 14 Jun 2005 01:00:12 +0000 : neofactor Glad to see it... I had always just added the following custom pages: http://neofactor.com/error403 (with a login link) http://neofactor.com/error404 (Adding the auto search) My 403's are only for non-members and all members have the same access. I use PHP to control groups differently for lots of different clients, so this works out well form me. The auto redirect function is nice.... keeping the user's initial request in place. hey.... When is Drupal going to add images to pages at core? Visual appeal.... It would be great if menu items and other areas started to do this... then people could just swap them out. Just a wish list. ;) ------------------------------------------------------------------------ Tue, 14 Jun 2005 03:02:01 +0000 : gordon Just adding the pages does work, but does not give the effect that I need. You can always use the login box on the sidebar, which will do the same thing. You said that the 403's aren't used to logged in users as they have the same privledge, But not everyone has the same privledge on your site (unless everyone has the same rights as user 1 ;-)) So what if a user who is already logged in goes to /admin you do not want to tell them that they need to login to get to the admin page, you want to send them to a big go away page. ------------------------------------------------------------------------ Tue, 19 Jul 2005 11:34:19 +0000 : jjeff Before I saw this thread, I posted another take on this bug at http://drupal.org/node/26659. It explains the problem a little more in-depth. Here's the thing: What makes Drupal sites look like Drupal sites is that they've got a login/password box on every page until the user is logged in. For Drupal to become a mature platform, it's going to need to move away from dependence on this crutch. Drupal should provide the infrastructure to allow the option of a simple "Login/Register" link. However, if a user gets an access denied message, they should be prompted to log in. As it is, the best that you can do after login is direct them back to the node that defines the "Access Denied" message. This is more than just confusing for the user. It's downright wrong! Dries, please reconsider this patch and/or some variation that solves this problem. It is essential for all current versions of Drupal. Thanks, Jeff ------------------------------------------------------------------------ Tue, 19 Jul 2005 11:52:21 +0000 : Kobus In concept, a definitive +1 from me. Especially the mention that the login box does not even display unless the user has to log in. I have started to remove the block completely and put it in a menu somewhere else so that it is not so obtrusive. For a commercial site, the exaggerated login page makes it look "as if you have something to hide". Not good. Regards, ------------------------------------------------------------------------ Mon, 25 Jul 2005 14:57:15 +0000 : Steven You say you can't use a custom 403 page because it doesn't know where it came from... so, why not set a destination parameter instead? I think all that needs to be done is set $_REQUEST['destination'] = $_GET['q'] before calling menu_set_active_item() in drupal_access_denied(). Probably the same for drupal_not_found(). The destination is then picked up by the login-block which adds destination=drupal_get_destination() in the form's action.

1 0

[drupal-devel] [feature] Adding ability to include named anchors for form_group()
by gordon 01 Aug '05

01 Aug '05

Issue status update for http://drupal.org/node/25478 Post a follow up: http://drupal.org/project/comments/add/25478 Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: Anonymous Reported by: RobRoy Updated by: gordon -Status: patch (code needs review) +Status: patch (code needs work) -1 The addition of the anchor doesn't seem to be very drupalish. This IMO would be better if it was a separate function so that if can be used in more places than just the form_group. maybe a drupal_anchor() that can be called. The example that has been provided, with the inclusion of the expanding and collapsing groups is no longs nessecary as they entire page may not be more than a single page so the browser will not be able to move anywhere. gordon Previous comments: ------------------------------------------------------------------------ Tue, 21 Jun 2005 23:08:06 +0000 : RobRoy Attachment: http://drupal.org/files/issues/common_anchor_names.patch (1.02 KB) Added ability to have an before each so as to allow linking to a page#foo when directing users to upload their user picture or whatever. I think this is really important for usability as the user account page can get rather long, and for the old folks who can't use the Internet that well, this is helpful. Also, included a change to the user.module to write out a named anchor for the user picture as an example. ------------------------------------------------------------------------ Mon, 01 Aug 2005 01:41:15 +0000 : killes(a)www.drop.org see http://drupal.org/node/25480 for use case.

1 0

[drupal-devel] [feature] Adding ability to include named anchors for form_group()
by killes 01 Aug '05

01 Aug '05

Issue status update for http://drupal.org/node/25478 Post a follow up: http://drupal.org/project/comments/add/25478 Project: Drupal -Version: 4.6.1 +Version: cvs -Component: drupal.module +Component: base system Category: feature requests Priority: normal Assigned to: Anonymous Reported by: RobRoy Updated by: killes(a)www.drop.org Status: patch (code needs review) see http://drupal.org/node/25480 for use case. killes(a)www.drop.org Previous comments: ------------------------------------------------------------------------ Tue, 21 Jun 2005 23:08:06 +0000 : RobRoy Attachment: http://drupal.org/files/issues/common_anchor_names.patch (1.02 KB) Added ability to have an before each so as to allow linking to a page#foo when directing users to upload their user picture or whatever. I think this is really important for usability as the user account page can get rather long, and for the old folks who can't use the Internet that well, this is helpful. Also, included a change to the user.module to write out a named anchor for the user picture as an example.

1 0

[drupal-devel] [task] GD2-specific functions should be moved to image.gd2.inc
by Junyor 01 Aug '05

01 Aug '05

Issue status update for http://drupal.org/node/19611 Project: Drupal Version: cvs Component: base system Category: tasks Priority: normal Assigned to: Junyor Reported by: Junyor Updated by: Junyor Status: patch Attachment: http://drupal.org/files/issues/system-image.patch (6.8 KB) The new image handling tools in core have a lot of GD2-specific logic, making image.inc overly cluttered and complicated. If gd2 were just treated like another toolkit (though the only one included by default), then the image.inc code would be much cleaner and more easily maintained. This patch removes all the GD2 stuff from image.inc and puts it into image.gd2.inc. The _settings hook is now doing what it sounds like it should, return settings for the toolkit. I've added a _check hook which will tell if the PHP functions needed are available. If _check fails, then the toolkit will not be listed on admin > settings and an error will be logged in watchdog. I've also update image.gd1.inc, image.imlib.inc, and image.imagick.inc with the same logic. Junyor

6 14

[drupal-devel] [feature] move check_query() into the database interface files
by killes 01 Aug '05

01 Aug '05

Issue status update for http://drupal.org/node/13180 Post a follow up: http://drupal.org/project/comments/add/13180 Project: Drupal Version: cvs Component: database system Category: feature requests Priority: normal Assigned to: chx Reported by: chx Updated by: killes(a)www.drop.org -Status: patch (code needs review) +Status: patch (code needs work) Accordign to Steven's last comment we should not use the mysql specific functions. killes(a)www.drop.org Previous comments: ------------------------------------------------------------------------ Fri, 19 Nov 2004 19:35:06 +0000 : chx Attachment: http://drupal.org/files/issues/check_output_patch.txt (1.54 KB) The check_query documentation says 'Prepare user input for use in a database query, preventing SQL injection attacks.' But the code itself is a simple addslashes. This is simply not correct -- for mysql, yes, but the world is not just mysql. There are _escape_string functions for that: mysql_escape_string, pg_escape_string, sqlite_escape_string... Read the manual for pg_escape_string: "Use of this function is recommended instead of addslashes()." Or read sqlite_escape_string: "addslashes() should NOT be used to quote your strings for SQLite queries; it will lead to strange results when retrieving your data." Ooooops. So I propose moving check_query() declaration from bootstrap.inc to database.*.inc. I've already written a letter to the devel list about this, but drumm said "code is better than talk" so here is a patch. At this moment, this does absolutely nothing, only opens the possibility to use the aforementioned escape_string functions. But database.sqlite.inc simply will not work without this change. ------------------------------------------------------------------------ Fri, 19 Nov 2004 19:42:04 +0000 : drumm Looks straightfoward enough. Is there any reason to not put in pg_escape_string() now? ------------------------------------------------------------------------ Fri, 19 Nov 2004 19:47:07 +0000 : chx Actually, yes. Read on the mentioned manual page: "Note: This function requires PostgreSQL 7.2 or later." I have no idea how the check it. There is a pg_version() but I will leave this postgres business to someone who has a working postgres install to code and check this thing. ------------------------------------------------------------------------ Fri, 19 Nov 2004 20:58:27 +0000 : Chris Johnson PostgreSQL 7.2 was released February 4, 2002. Major production releases 73. and 7.4, along with many point releases, have been issued since then. Current production is 7.4.6 and 8.0 is in the 4th revision of beta. It seems pretty safe to assume that any Drupal installation using PostgreSQL would have version 7.2 or later. Document if a user encounters errors with PostgreSQL that they need to check the version is 7.2 or later. ------------------------------------------------------------------------ Sat, 20 Nov 2004 13:42:37 +0000 : Dries +1 I suggest creating a db_escape_string() function, and removing check_query() all together. ------------------------------------------------------------------------ Sat, 20 Nov 2004 13:55:44 +0000 : Goba +1 on Dries ------------------------------------------------------------------------ Sat, 20 Nov 2004 17:32:09 +0000 : chx Attachment: http://drupal.org/files/issues/check_output_patch_0.txt (1.6 KB) db_escape_string sounds find to me, it's really a better name, thanks Dries. But removing check_query? I'd suggest deprecating it and removing it later. I am afraid It would break a lot of custom modules. Here is a slightly modified patch with pg_escape_string included and documented. ------------------------------------------------------------------------ Sat, 20 Nov 2004 17:43:37 +0000 : killes(a)www.drop.org We were never afraid of breakign things for the good of the project. Please don't change this policy. ------------------------------------------------------------------------ Sat, 20 Nov 2004 18:26:10 +0000 : chx Attachment: http://drupal.org/files/issues/db_escape_string.txt (20.87 KB) Let's do it. ------------------------------------------------------------------------ Sat, 20 Nov 2004 18:29:33 +0000 : chx Attachment: http://drupal.org/files/issues/db_escape_string_0.txt (20.88 KB) Something funny happened to the PostgreSQL db_escape_string comment and I have missed it, sorry. Reposting the patch. ------------------------------------------------------------------------ Sun, 21 Nov 2004 08:29:22 +0000 : Dries I committed the patch. Thanks chx. Keep it coming. I've also updated the upgrade notes at http://drupal.org/node/12347. I'll update some contributed modules unless someone objects. ------------------------------------------------------------------------ Sun, 21 Nov 2004 11:27:27 +0000 : chx Attachment: http://drupal.org/files/issues/mysql_escape_patch.txt (572 bytes) Keep it coming? Well, let's see the MySQL case... It's far from being trivial, and I expect some controversy over it. ------------------------------------------------------------------------ Wed, 09 Mar 2005 23:36:30 +0000 : chx Attachment: http://drupal.org/files/issues/mysql_escape_patch_0.txt (573 bytes) OK, here is mysql version a bit corrected, this should get into 4.6 -- addslashes is not a correct way any more. ------------------------------------------------------------------------ Thu, 10 Mar 2005 18:29:16 +0000 : Dries Can we read up on that somewhere? ------------------------------------------------------------------------ Thu, 10 Mar 2005 18:37:41 +0000 : Goba Dries, sure: http://php.net/mysql_escape_string [1] and http://php.net/mysql_real_escape_string [2]. The latter also uses the connections charset settings to properly escape, so it is the best (but is not available in old PHP versions). The addslashes page user notes also have more information [3]. [1] http://php.net/mysql_escape_string [2] http://php.net/mysql_real_escape_string [3] http://hu.php.net/addslashes#20013 ------------------------------------------------------------------------ Sat, 12 Mar 2005 08:50:26 +0000 : Dries addslashes() has been working for ages (and is simpler code-wise). I guess the mysql_ functions are slightly more secure or not even that? That aside, I'm not really a big fan of version_compare()s. Also note that the patch violates Drupal's coding standards (again) but that's easy enough to fix. ------------------------------------------------------------------------ Sun, 13 Mar 2005 19:49:48 +0000 : chx I can only repeat what Goba said: . mysql_real_escape_string uses the connections charset settings to properly escape, so it is the best (but is not available in old PHP versions). ------------------------------------------------------------------------ Wed, 01 Jun 2005 03:40:04 +0000 : Steven Actually, Drupal does nothing to ensure the database character set is set to UTF-8 (can it?). Thus, escaping with mysql_real_escape_string() is not advised.

1 0

[drupal-devel] [bug] Menu cache prohibiting access for users
by killes 01 Aug '05

01 Aug '05

Issue status update for http://drupal.org/node/24034 Post a follow up: http://drupal.org/project/comments/add/24034 Project: Drupal -Version: 4.6.0 +Version: cvs Component: menu system Category: bug reports Priority: critical Assigned to: Anonymous Reported by: nysus Updated by: killes(a)www.drop.org -Status: patch (code needs review) +Status: patch (code needs work) Does not apply anymore. killes(a)www.drop.org Previous comments: ------------------------------------------------------------------------ Wed, 01 Jun 2005 00:05:09 +0000 : nysus See http://drupal.org/node/24019 for description of the problem. ------------------------------------------------------------------------ Wed, 01 Jun 2005 01:04:21 +0000 : Steven Attachment: http://drupal.org/files/issues/user.menu.cache.patch (1.62 KB) Patch attached.

1 0

[drupal-devel] [bug] conf_init should strip out port numbers in bootstrap.inc
by killes 01 Aug '05

01 Aug '05

Issue status update for http://drupal.org/node/19934 Post a follow up: http://drupal.org/project/comments/add/19934 Project: Drupal Version: cvs Component: base system Category: bug reports Priority: normal Assigned to: chx Reported by: bwooster47 Updated by: killes(a)www.drop.org -Status: patch (code needs review) +Status: patch (ready to be committed) patch still applies, my testsite kept working (is not on a non-standard port, though). killes(a)www.drop.org Previous comments: ------------------------------------------------------------------------ Sun, 03 Apr 2005 23:07:58 +0000 : bwooster47 The latest Drupal from CVS (4.6.0) offers multisite configuration files, but currently the conf_init function in includes/bootstrap.inc will also include the :portnum URL specification in the directory name, which does not seem right (and the colon character may cause problems on Mac/Windows). Snippet from bootstrap.inc: * Example for a fictitious site installed at * http://www.drupal.org/mysite/test/ the 'settings.php' is * searched in the following directories: ..... If the site is: http://www.drupal.org:8080/mysite/test/ the same list of directories should be searched as listed in the example in the file, and the :8080 should not be added to the directory name (I think...) I don't know enough PHP to submit a patch, but this is probably easy for those who know this stuff :-) ------------------------------------------------------------------------ Fri, 08 Apr 2005 07:08:53 +0000 : chx Attachment: http://drupal.org/files/issues/conf_init_ports.patch (768 bytes) Here you are. ------------------------------------------------------------------------ Fri, 08 Apr 2005 11:16:52 +0000 : Dries Won't commit. Removing the port seems like a bad idea (I could have two drupal sites at two different ports but otherwise identical URLs) and adding regex' all over the map isn't advised. If ":" is an invalid character, then there might be more such characters. I suggest we replace them with '.' and that we document this behavior much like we do with $db_url. ------------------------------------------------------------------------ Mon, 11 Apr 2005 23:25:51 +0000 : chx Attachment: http://drupal.org/files/issues/conf_init_ports_0.patch (1.35 KB) ------------------------------------------------------------------------ Tue, 19 Apr 2005 17:03:46 +0000 : bwooster47 Regarding update #3 - does this mean the code has made it in, and will be available in the next release? Secondly: I follow the logic for the update, and it makes sense for non-standard HTTP port numbers, but not sure if the logic is valid when port 80 is used. For example, http://yourdomain.com/ and http://yourdomain.com:80/ both will go to the exact same page, but looks like the search for the conf.php will be different. Not sure if this matters...

1 0

[drupal-devel] [bug] settings.php change to prevent PHPSESSID in URL
by kbahey 01 Aug '05

01 Aug '05

Issue status update for http://drupal.org/node/21170 Project: Drupal Version: 4.6.0 Component: other Category: bug reports Priority: normal Assigned to: kbahey Reported by: kbahey Updated by: kbahey Status: patch Attachment: http://drupal.org/files/issues/settings_0.patch (576 bytes) As per the workaround mentioned in discussion [1], the default settings.php file that is shipped does not always prevent PHP from adding the PHPSESSID in the URL. Although this is a hosting setting issue, a workaround exists for it: A patch is attached, and it just adds the following line to settings.php ini_set('url_rewriter.tags', ''); [1] http://drupal.org/node/17947#comment-36339 kbahey

3 3