Item1359: Port TWiki:Plugins.ExitPlugin to Foswiki

I am the author of TWiki:Plugins.ExitPlugin.

This plugin redirects links to external sites via a page of your choice. You might want to do that to display a disclaimer ("You are leaving Foswiki, come back soon.") or to remove topic names from HTTP referer headers.

I currently maintain this plugin in my own private repository and upload new versions to TWiki.

I plan to port this plugin to Foswiki and submit it to subversion.

-- IanBygrave - 23 Mar 2009

First pass submitted, with bin/exit.cgi translated to a rest handler. Redirection via this handler must work for unauthenticated users, however it seems unauthenticated rest doesn't work, possibly by design. See Item4929 and Item6023.

-- IanBygrave - 24 Mar 2009

Oh I see, rest is in $Foswiki::cfg{AuthScripts}. Shouldn't the plugin or rest handler decide if the verb needs to be authenticated?

-- IanBygrave - 26 Mar 2009

CommandAndCGIScripts#rest asserts that

The rest script should always require authentication in any site that has logins. Otherwise there is a risk of opening up major security holes. So make sure you add it to the list of authenticated scripts if you are using ApacheLogin.

I don't see what the potential "major security holes" are. Could someone enlighten me?

This plugin (and at least one more) require either unauthenticated rest handlers (apparently insecure) or scripts in /bin (contrary to FSA).

-- IanBygrave - 28 Mar 2009

Hi Ian,

Thanks for sharing your extension with foswiki community!

Actually to have a script in bin is not exactly contrary to FSA, as long as it also has a SwitchBoard entry and its implementation is not in the script (the script is called only in CGI setups). Look at CompareRevisionsAddOn for an example.

-- GilmarSantosJr - 28 Mar 2009

The "risk of opening up major security holes" comes from sloppily-written REST scripts contributed by extensions authors. Because REST scripts are somewhat under the hood, they don't receive the scrutiny that the other scripts do, and it's easy to accidentally open up holes with them. Requiring authentication doesn't actually plug any of the holes, but it at least slows down evil guests.

As you suggest REST functions really ought to be classified into "requires authentication" and "does not require authentication", with the default being the former. At the moment we rely on the access control exception mechanism to trap operations requiring authentication, which rather breaks some scripts. Add a feature request, and we might get to it for Foswiki 2.0

-- CrawfordCurrie - 29 Mar 2009

Aren't the risks from sloppily-written REST scripts exactly the same as the risks from slopily-written scripts in bin? Except that:

• Small stand-alone CGI scripts are easier to get right.
• An admin installing a plugin that adds a script to bin should be more aware that he's opening a potential security hole.

I'll add a feature request. Meanwhile I'll revert this plugin to using a script in bin.

-- IanBygrave - 29 Mar 2009

Any progress in this or your other Plugins Ian? Question263 by MichaelWhite mentions the need for your TWiki:Plugins.FootNotePlugin. Any chance that that gets ported soon too?

-- FranzJosefGigler - 11 Aug 2009

I think this plugin may be done. I'll update the state of this task once I've checked.

TWiki:Plugins.FootNotePlugin is next on my todo-list, but I've had very little spare time recently, and porting this plugin took at least a whole weekend.

-- IanBygrave - 11 Aug 2009

Reviewing the state of this task:

• The code is complete in /trunk/ExitPlugin
• Tested on a local SVN install
• I can't see what (if anything) else is needed to complete the porting task.
• I still have little free time to spend on this.

As this is the simplest of my plugins I decided to port it first. At this rate, I doubt I will get around to porting the others this year.

-- IanBygrave - 31 Aug 2009

From what I see, the main effort here was converting your bin script into a rest call, which you finally abandoned. As it seems FootNotePlugin hasn't any bin script, it should be pretty easy to port.

Also, did you use the t2f.sh script or anything similar, or you did all the porting yourself manually?

-- OlivierRaginel - 31 Aug 2009

I did all the porting manually.

I'm about to start porting my other plugins. I can't find any other reference to t2f.sh and it isn't in my foswiki checkout. Where can I find it?

Also, as my port of ExitPlugin is complete, I'm marking this task done. If there is something else I have to do to get this plugin in the next release, please reopen this task.

-- IanBygrave - 04 Oct 2009

The script is in the tools directory, called twiki2foswiki.

Having said that, I never used it when porting. Its not too much effort to do it by hand.

-- AndrewJones - 04 Oct 2009

I've just installed ExitPlugin from the foswiki-1.0.7 debian repository. It failed with:

Undefined subroutine &Foswiki::Func::getRequestObject called at /var/lib/foswiki/lib/Foswiki/Plugins/ExitPlugin.pm line 186.
 at /var/lib/foswiki/lib/Foswiki/Plugins/ExitPlugin.pm line 186

It seems that this plugin depends on Item1333 which is released in foswiki-1.1.0.

How should I mark this plugin as not for release before 1.1.0?

-- IanBygrave - 11 Oct 2009

Why not use the current API call so we can use it in 1.0.X?

I have reopened Item1333 which I think is a major blunder. We should not change the API call and create a silly compatibility problem just because of a name. When do we start learning from our past mistakes?

-- KennethLavrsen - 12 Oct 2009

I used the trunk API. I work in a private wiki based on foswiki/trunk as recommended.

If Item1333 gets reverted I'll change to getCgiQuery.

What is the recommended technique for extensions to cope with API changes between foswiki versions? Subversion branches?

-- IanBygrave - 12 Oct 2009

After reading Item1333 more closely (and looking at distro:7965f76d061d) I can see that Foswiki::Func::getCgiQuery has not been removed, merely deprecated. As a CGI object is what I wanted anyway, I've change to using that function.

-- IanBygrave - 17 Oct 2009