-
Notifications
You must be signed in to change notification settings - Fork 175
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Configuration] Path settings must be valid paths #4023
Conversation
$err = 'Path ' . htmlspecialchars($value, ENT_QUOTES) | ||
. ' is not valid.'; | ||
// Set response code and display error message. | ||
$displayError(400, $err); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is not a function name? typo?
When I test it, there is no error message, and all the paths can't be changed. |
@kongtiaowang You were right. I fixed the problem. Please test again if you have time. |
@paiva can you please test this one ? |
This might cause issues with the Logs path because I think it's deliberately set up as a partial path (i.e. tools/logs/) I'm not sure where this is used exactly but I think I'll need to issue another PR to update those usages once this is merged. |
This is now blocked by #4087 as it uses the new data type in its query. |
Addressed by using new data types.
This code does what it is supposed to do. However, at the moment, default path values such as "/PATH/TO/EXTERNAL/LIBRARY/" or "/PATH/TO/Genomic-Data/" are not allowed anymore so the user is left with either: Should blank be allowed? or should default values from the ConfigTables schema be allowed? |
I guess ideally we would have a toggle switch on each of the modules saying whether a project will use them or not... I think it makes sense to allow blank values in this case. The default params don't really make sense anyway and only some of the paths are configured to have one in the /NOT/REAL/PATH format. Blank paths will probably result in ConfigurationExceptions at some point in whatever modules use them. I don't know if this is the best solution but I think it's what we have available right now. |
foreach ($_POST as $key => $value) { | ||
if (is_numeric($key)) { //update | ||
if ($value == "") { | ||
$DB->delete('Config', array('ID' => $key)); | ||
$DB->update('Config', array('Value' => null), array('ID' => $key)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is this changed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The basic idea of my changes is to verify whether the incoming data is a web_path
type in the DB and if so make sure that it's a valid path.
When debugging a problem another reviewer had, i realized that the script was actually deleting values when they are blank.
This is a problem because we decided in a meeting at some point that the paths should be left blank when they're not configured (rather than allowing for /INVALID/PLACEHOLDER/PATHS
as a value).
I figured it would make sense to keep the IDs in the database and set them to null rather than delete them. It makes more sense to me intuitively to have a setting be blank/uninitialized than for it to vanish.
Do you see this causing problems?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, when new config settings are added/unchanged from the default they do not have any entry in the Config table. The update statement will return 0 rows and report success but silently do nothing. As a result, no one will ever be able to set a config setting for the first time for any config that doesn't have a non-empty default. Not having a value in the table when the setting is blank is correct behaviour.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
when new config settings are added/unchanged from the default they do not have any entry in the Config table
Aren't defaults stored in the Config table? ConfigSettings doesn't have any information about the value.
@@ -52,20 +63,40 @@ | |||
if ($keySplit[0] == 'add') { | |||
if ($value !== "") { | |||
if (countDuplicate($keySplit[1], $value) == '0') { | |||
$DB->insert( | |||
$DB->update( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This will not work when the value isn't in the table
Co-Authored-By: Dave MacFarlane <driusan@gmail.com>
@johnsaigle Why did you add "Discussion Required" to this PR? |
@driusan I replied to your above comment and you didn't follow up. I think that this PR makes sense the way I've done it. Maybe it makes the most sense for us to discuss it in person so I can walk you through my thinking. |
This PR does not make sense the way it's done. The config tables are normalized. If there is no value, it should be deleted from the value table, not updated to a blank value. Defaults are only stored in the config table of the default schema if the default is non-empty. |
…81023-ValidateConfigPaths
@driusan I modified this PR to use insert/delete instead of updates, as requested. Please review when you have time. |
PR rewritten to address review concerns. New review required.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
mostly minor things and error handling.
$DB->delete( | ||
'Config', | ||
array('ConfigID' => $ConfigSettingsID) | ||
); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
else throw exception?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
Co-Authored-By: Dave MacFarlane <driusan@gmail.com>
Co-Authored-By: Dave MacFarlane <driusan@gmail.com>
…81023-ValidateConfigPaths
@driusan I made your requested changes. |
request changes have been addressed
@driusan Tagging you again because this ideally would go into the next |
Brief summary of changes
I was recently able to develop an exploit where I could upload and execute scripts via manipulating config path settings. This PR ensures that these settings actually correspond to existing paths on the system before changing their values in the database.
To Test
Paths
to an invalid path. You'll get a400
error.