You are here: Foswiki>Tasks Web>Item11392 (11 Dec 2012, GeorgeClark)Edit Attach

Item11392: Configure doesn't do sanity checking on PERL input fields

Priority: Normal
Current State: Closed
Released In: n/a
Target Release: n/a
Applies To: Engine
Component: Configure
Reported By: KipLubliner
Waiting For:
Last Change By: GeorgeClark
I was using DatabasePlugin, and I entered an invalid value for {Plugins}{!DatabasePlugin}{Databases} (I missed a comma). Configure script did not help me to discover the misconfiguration ... I created a small perl script to discover the error.

The screen that displays the variable changes and asks for the password to continue could be improved: The script could evaluate the new values for perl data types, and give an error message if the new setting does not compile.

Foswiki did not break ... I could not find the new value in LocalSite.cfg. So it seems that this check is already being done somewhere. It should also be done a little earlier to help admins to enter valid values.

-- KipLubliner - 29 Dec 2011

Thanks for reporting this issue.

The current (trunk) version of configure validates PERL data items, so if this Extension is using configure - I don't have DatabasePlugin installed, but assume it is since you opened the item against configure - you shouldn't experience this problem in the future.

Configure now parses PERL items to make sure they conform to the restricted subset of PERL that is acceptable, and also checks for errors when it eval s the item. Errors are reported in real-time - usually with a pointer to the line in error. (Always with a pointer to the line where the problem is detected - not always the same thing.)

I'm closing this item as it is fixed in trunk, and Item12180 owns the check-ins/release process; if you still have your reproducer and can make it fail, feel free to re-open it.

I'm also documenting the checkins specific to this issue here - although they depend on a number of other checkins in the configure overhaul and can not be applied to previous versions of Foswiki.

-- TimotheLitt - 11 Dec 2012

If a task has checkins, and is a bug that was reported against a prior release, it should probably go into Waiting For Release status. The only task that should be closed with checkins are ones that fix bugs new to the code that were never released. This way the specific summary gets added to the release notes. This seems like one worth calling out in the release notes.

-- GeorgeClark - 11 Dec 2012

ItemTemplate edit

Summary Configure doesn't do sanity checking on PERL input fields
ReportedBy KipLubliner
Codebase 1.1.4
SVN Range
AppliesTo Engine
Component Configure
Priority Normal
CurrentState Closed
TargetRelease n/a
ReleasedIn n/a
trunkCheckins distro:c2485aa3ce24 distro:896fe70885be
Topic revision: r3 - 11 Dec 2012, GeorgeClark - This page was cached on 12 Sep 2020 - 22:29.

The copyright of the content on this website is held by the contributing authors, except where stated elsewhere. See Copyright Statement. Creative Commons License    Legal Imprint    Privacy Policy