What the Hell is Strikeone?

I can see an error with JHotDrawPLugin that it doesn't work with a server "not configured for strikeone" - what the hell does this mean? I can't find a reference to it

I've a client trying to compare Foswiki to TWIki to see if they need to migrate.

They've identified a couple of plugins/extensions are essential and so far TWikiDrawPlugin just comes up & runs (under TWiki), but I can't get JHotDrawPlugin to save a change.

Not exactly impressive.

Sorry, but I've used TWiki since, well I don't know when. I've set a Twiki & Foswiki test site up for them to see - and it's not going well for Foswiki. I realise that this could be in part down to me, with my better understanding of Twiki, but it's also change for change sake (so to speak) in that some things in Foswiki just don't work compared to their equivalents in TWiki.

I hope that the reputed greater developer support in Foswiki will resolve this quickly.

-- ChrisHogan - 03 Feb 2010

I'm not a Foswiki developer, so my answer might not be complete. I just wanted to let you know that I've got JHotDrawPlugin running fine on Foswiki 1.0.9.

Strikeone is a mechanism against cross-site request forgery (Wikipedia:Cross-site_request_forgery) which was introduced in Foswiki 1.0.6. There are version of JHotDrawPlugin which work with Foswiki version before 1.0.6 but the latest plugin version requires strikeone to be enabled. See also JHotDrawPlugin#Known_Problems

There is also a task describing your problem (although there is no solution yes): Tasks.Item2614

-- MartinKaufmann - 04 Feb 2010

The JHotDrawPlugin doc really shouldn't talk about "strikeone" - it's an internal codename for the CSRF protection. I'm afraid I haven't had any free time to work on JHotDrawPlugin for some time.

Unfortunately there's often a conflict between people's desire for features and security, and the common man's desire for simplicity. CSRF protection is a complex subject when done properly. But it's described in simple terms in WhyYouAreAskedToConfirm, and in more complete terms in SecurityFeatures#Cross_site_request_forgery_CSRF

You can turn on/off the CSRF protection in the Security Settings section of configure.

-- CrawfordCurrie - 04 Feb 2010

As Martin correctly states, you must have the configure setting {Validation}{Method} set to strikeone to use the current version of JHotDrawPlugin. This is the default in Foswiki 1.0.9.

Naturally JHotDrawPlugin (same as TWikiDrawPlugin but newer and better and fully backwards compatible with older TWikiDrawPlugin drawings) will soon be fixed to also work with the less secure settings.

But in 99% of the cases you will want to run with {Validation}{Method} set to "strikeone" and it works great in practical use and gives you good security. I wonder why you run with it turned off??

If some special circumstances demand that you turn off the CSRF protection then you can download an older version of JHotDrawPlugin and be happy with that too.

If the problem with {Validation}{Method} set to "strikeone" is that you cannot go back in the browser and resubmit or make many submits from the same topic to other topics without the confirmation screen then I recommend to keep {Validation}{Method} set to "strikeone" and instead change {Validation}{ExpireKeyOnUse} to un-checked. This way you still have good security, JHotDrawPlugin will work with the latest version, and users will only see the validation screen when there is a good reason.

-- KennethLavrsen - 04 Feb 2010

I'm a bit confused - I haven't set {Validation}{Method} to anything. In fact I can't even find it in the configuration script. It is in the Localsite.cfg but not offered anywhere in the interface script

This is a Foswiki installation straight out of the box, so to speak.

I just set {Validation}{ExpireKeyOnUse} to 0 - the effect was almost identical - I clicked on the empty drawing in the JHotDraw topic, edited it & save/exit. No change to the topic. Click again & it will not even exit from the Java applet.

I can easily believe other people have this running, but with a plain vanilla installation I'm puzzled that it doesn't work.

I'd try with strikeone disabled, just to see the effect, but I don't know the alternatives, because it's not offered in the configure script.

Do I have to do something else to get strikeone running or is there a problem with my installation? My client reported a difference in content between the .zip & .tgz for 1.0.8 (the zip was missing files) so I took the .tgz - I'll download again & try to see if something is missing from my current installation.

-- ChrisHogan - 08 Feb 2010

Try pressing "Yes, I have read all the documentation" (expert mode) in configure, to see the validation method settings. Foswiki 1.1 has a completely new configure UI which should hopefully avoid these sorts of confusion.

Are you using a custom skin? See my notes at the end of Tasks.Item8387

-- PaulHarvey - 08 Feb 2010

Doh! What a twit! I know I should press that! Yes, the option now appears & it is set to strikeone.

I'm using the default skin that Foswiki ships with. At this stage the idea was to present comparable TWiki & Foswiki installations, with the plug-ins that they thought they'd need & not much else, so that they could see the effects of what they were doing easily.

I am going to have another attempt today to get to the bottom of this.

-- ChrisHogan - 09 Feb 2010

I simply disabled the plugin & manually removed all elements of it - including the file in the templates directory. I then reinstalled it once again & lo and behold it all works!

I can't see that it was a corruption, so did I just make my first download too early so to speak. I read all of te incidents reports against the plugin, but every one of them seemed fixed in the version I had downloaded - the pace of change with Foswiki is very fast.

The issue with strokeone did not reocurr - I have absolutely no idea why it happened in the first place.

I don't know if the version I installed the second time had been updated, all I can say is I'm pleased that it works. I just fell a little mystified.

-- ChrisHogan - 22 Feb 2010

The new version of JHotDrawPlugin uses a template common to all skins.

The old had a special version for PatternSkin.

If you upgraded the plugin the old template file was still there and it then gets picked because the template path has skin specific before generic.

Now that you wiped the plugin out and re-installed you got the old file wiped as well.

The installers we have install but they do not remove files when upgrading. We should perhaps have a remove feature for specific named files.

I added a note about this on the JHotDrawPlugin plugin topic in the Compatibility field.

-- KennethLavrsen - 22 Feb 2010