View Issue Details

IDProjectCategoryView StatusLast Update
0007774mantisbtcustom fieldspublic2007-05-08 03:42
Reporterdaudo Assigned Tovboctor  
PrioritynormalSeveritymajorReproducibilityalways
Status closedResolutionfixed 
Product Version1.0.6 
Target Version1.0.7Fixed in Version1.0.7 
Summary0007774: custom fields not stored correctly in bug history
Description

the maximum field length for field names does not allow all custom field names to fit in, see this:

---------CUT---------
mysql> describe mantis_bug_history_table;
[...]
field_name | varchar(32) [...]
[...]
mysql> describe mantis_custom_field_table;
name | varchar(64)
---------CUT---------

This again leads to a real security issue where custom fields are still print out because the access check is unable to determine the access level of a custom field with a name exceeding 32 characters.

This is something that hit us along with bug 0007772.

TagsNo tags attached.
Attached Files
7774.patch (2,546 bytes)   
Index: core/custom_field_api.php
===================================================================
RCS file: /cvsroot/mantisbt/mantisbt/core/custom_field_api.php,v
retrieving revision 1.61
diff -u -r1.61 custom_field_api.php
--- core/custom_field_api.php	6 Mar 2007 07:05:19 -0000	1.61
+++ core/custom_field_api.php	1 Apr 2007 07:41:52 -0000
@@ -588,12 +588,20 @@
 	# --------------------
 	# Get the id of the custom field with the specified name.
 	# false is returned if no custom field found with the specified name.
-	function custom_field_get_id_from_name( $p_field_name ) {
+	function custom_field_get_id_from_name( $p_field_name, $p_truncated_length = null ) {
 		$t_custom_field_table = config_get( 'mantis_custom_field_table' );
 
 		$c_field_name = db_prepare_string( $p_field_name );
 
-		$query = "SELECT id FROM $t_custom_field_table WHERE name = '$c_field_name'";
+		if ( ( null === $p_truncated_length ) || ( strlen( $c_field_name ) != $p_truncated_length ) ) {
+			$query = "SELECT id FROM $t_custom_field_table WHERE name = '$c_field_name'";
+		} else {
+			# @@@ This is to handle the case where we only have a truncated part of the name.  This happens in the case where
+			# we are getting the custom field name from the history logs, since history is 32 and custom field name is 64.
+			# This fix will handle entries already in the database, future entries should be handled by making the field name max lengths match.
+			$query = "SELECT id FROM $t_custom_field_table WHERE name LIKE '$c_field_name%'";
+		}
+
 		$t_result = db_query( $query, 1 );
 
 		if ( db_num_rows( $t_result ) == 0 ) {
Index: core/history_api.php
===================================================================
RCS file: /cvsroot/mantisbt/mantisbt/core/history_api.php,v
retrieving revision 1.39
diff -u -r1.39 history_api.php
--- core/history_api.php	6 Mar 2007 07:05:19 -0000	1.39
+++ core/history_api.php	1 Apr 2007 07:42:51 -0000
@@ -133,8 +133,8 @@
 			extract( $row, EXTR_PREFIX_ALL, 'v' );
 
 			// check that the item should be visible to the user
-			// custom fields
-			$t_field_id = custom_field_get_id_from_name( $v_field_name );
+			// custom fields - we are passing 32 here to notify the API that the custom field name is truncated by the history column from 64 to 32 characters.
+			$t_field_id = custom_field_get_id_from_name( $v_field_name, 32 );
 			if ( false !== $t_field_id && 
 					!custom_field_has_read_access( $t_field_id, $p_bug_id, $t_user_id ) ) {
 				continue; 
7774.patch (2,546 bytes)   

Relationships

parent of 0007875 closedvboctor Port 7774: custom fields not stored correctly in bug history 

Activities

vboctor

vboctor

2007-03-05 09:33

manager   ~0014129

This will be applicable to both 1.0.x and 1.1.x branches.