Item779: {AuthScripts} setting needs a * option, and a dynamically created list of cgi's that are installed.

where * means everything requires login, but login and reset password still work.

configure should also list all the cgi's in the bin dir (so the admin knows that some addon added something, and hilight which require login, which are core and ok, and which are non-core and they should be aware of to consider securing.

-- SvenDowideit - 16 Jan 2009

That's bound to hurt REST scripts at least. Instead {AuthScripts} should be deprecated.

-- MichaelDaum - 15 Mar 2011

The Checker now exists - listing the "unprotected" scripts, and warning if any *auth scripts are in bin that are not included in AuthScripts. It was committed on task Item11194 and Item11448

Do we still need an * option, or can this be closed as complete enough.

-- GeorgeClark - 01 Feb 2012

personally, I'd feel more comfortable with *, or better, to deprecate {AuthScripts} and replace with a new {AuthNotRequiredForScripts} - so that anyone installing something that has a bin script won't be unsafe by default.

tbh, I come across way too many foswiki's where the admin either doesn't use configure at all, or uses it just to install and ignores the warnings

-- SvenDowideit - 22 Feb 2012

+1 for AuthNotRequired. That doesn't mean the script can be run unprotected, of course, just that Foswiki::UI will not enforce logged-in-ness.

-- CrawfordCurrie - 25 Feb 2012

I have looked at at our code and the way {AuthScripts} is used. I've considered adding an {AuthNotRequired} several times before. It seems it's actually not a huge change, we have a nicely centralized (albeit confusingly named) method on the LoginManager to check if the script should call auth.

The last time I contemplated this Sven reminded me that we shouldn't even have 12 different scripts in bin; we should really only have foswiki & foswikiauth. But something is better than nothing.

-- PaulHarvey - 26 Feb 2012

{AuthScripts} needs to be eliminated. REST handlers for a long time have been able to register their auth requirements. The auth requirements of the other scripts don't change, and don't need a configure option - their requirements should be reflected directly in the implementation. {AuthScripts} was a quick hack that many people just don't understand, because it gets confused with Apache auth, and is far too coarse-grained.

-- CrawfordCurrie - 21 Mar 2012

Commenting is disabled while not logged in