No Edit Link & Authentication Required

I have a working Foswiki installation & after a few issues I had JHotDrawPlugin working

A client is experiencing a couple of problems with their version, so for the first time in a couple of weeks, I brought up the basic plugin topic to compare to their system.

I noticed that the edit links for the drawings wre not created. Switching to the Sandbox, where I have a topic with a drawing, I got a message "edit access denied". My system is locked down, even for Sandbox, so I logged in & the proper edit link appeared, both in the Sandbox & the plugin topic itself.

This is only of interest, because I take it that it means the drawing plugin is performing more access checks than the text body around it.

My client is suffering what seems to be a related issue: they have topics with DRAWING variables in them (with links), but clicking to edit brings up an "Authentication Required" dialog box.

I assume it is trying to prove they have access to the pllugin Java applet. This is under IIS, so no .htaccess for me to examine.

Does anybody have any suggestions as to where I should look to find out what is asking for the extra authorization, why it's doing it - and more to the point how I can stop it.

-- ChrisHogan - 23 Mar 2010

Check {Validation}{Method} in configure. At the moment JHotDraw only supports strikeone validation. If it's set to anything else, the plugin fails, but if I recall correctly, not really in the way you're describing. Please report back the {Validation}{Method} from configure/LocalSite.cfg

-- PaulHarvey - 23 Mar 2010

They did have {Validation}{Method} set to none, but changing it to strikeone makes no difference to the Authentication pop-up. We've tried every login we can think of. Does it need a particular permissions group to access the .jar file I wonder? The different behaviour in my test wiki (where the validation is strikeone) would perhaps be down to the groups I've defined?

-- ChrisHogan - 23 Mar 2010

Reading the code, they just need need to have CHANGE permission on the topic. I assume they can edit the topic?

Perhaps the code is too simplistic to deal with non-vanilla user/login managers. Are they using LDAP or some other login/user mapper?

-- PaulHarvey - 04 Apr 2010

I've managed to get them to do a few experiments & it seems all the JavaScript & the applet itself are loaded - it's as if the applet needs permission from IIS to access the directory to see if there is a pre-existing .draw file. This is a bit outside my experience, I'm used to a Linux server at the other end.

The chap doing the testing is an administrator, so I'd think he has change rights to absolutely everything, but I wonder if the Java applet can tell that if he has this usual login process.

-- ChrisHogan - 09 Apr 2010

Check that they can upload attachments, and browse the /pub dir directly

-- PaulHarvey - 11 Apr 2010

Major Progress with this - I quote from my client "to have another look around the settings in there and I found under the properties for the website and under Directory Security, within the Authentication and Access Control there was a tick at the side of Digest
authentication for Windows domain servers. I knew the Java authentication box mentioned Digest so I've tried unticking that,
reseting the website and lo and behold the authentication box disappears." - so this is an IIS issue, not a JHotDraw one.

We should, I suppose record this as an issue in the installation of Foswiki under IIS? Just to help other people.

Not quite finished though, another quote "Now we're not quite there as I'm getting the JHotDraw window appearing but at the bottom is the following message:

Error reading /pub/System/JHotDrawPlugin/empty.draw: java.io.FileNotFoundException: http://rdc-tad3/pub/System/JHotDrawPlugin/empty.draw"

Given that empty.draw should be missing I don't understand this (yet).

-- ChrisHogan - 20 Apr 2010

Should it be missing? Try putting an empty.draw there. I assume this is some sort of new-drawing-template.

-- PaulHarvey - 20 Apr 2010