Item415: FoswikiDrawPlugin cannot save with TemplateLogin if not authenticated before you hit edit

Using foswiki nightly svn 1201, Installed JHotDrawPlugin.zip from twiki plugins repo. (note, the same happens on foswiki svn with FoswikiDrawPlugin installed)

I am using TemplateLogin (not http basic auth)

The drawing applet runs OK until time to save. The applet reports failure to save any of draw.map, gif files.

The browser says "java.io.IOException ... 403" .

The server logs say "client denied by server configuration: /home/eliot/public_html/foswiki/bin/upload"

I can upload ordinary attachments to the topic.

-- EliotBlennerhassett

I have quickly analysed this one since I recently claimed how well this works and because I want to fix if I screwed something up recently.

And I found out that the problem is different.

The problem is old. I can reproduce it on TWiki 4.2.4 and JHotDrawPlugin.

The problem occurs when

• You run TemplateLogin
• You edit a drawing (click on it) while not being authenticated
• And then save

It seems the java applet cannot authenticate against Foswiki or TWiki when it is in TemplateLogin mode.

If you authenticate first it works fine in both IE and FF.

And if you run ApacheLogin it also seems to work. Then the applet asks for username and password once.

As I write this the original reporter this see the problem even when authenticated and I am trying to see if some other server side config makes the difference.

The important message is - it is not name space related and it is not the FSA or Foswiki stuff that causes the issue.

It is an old issue.

I am thinking about a work around.

-- KennethLavrsen - 08 Dec 2008

An additional twist. It seems that on a Linux machine even when authenticated, the java does not know it is authenticated. Maybe no access to the needed session cookie.

I (EliotBlennerhassett) can confirm that the HTTP POST header when using icedtea-gcjwebplugin does not contain the auth cookie. When I replace this with sun-java6-plugin, the POST header has the correct cookie. (package names are for Ubuntu 8.04)

-- KennethLavrsen - 09 Dec 2008

A twist to the twist. The Linux problem was a buggy Java (gcj instead of Sun) With Sun java it works as I also see it.

So we can focus on finding a solution to the authentication.

The plan is to change the plugin to using rest (another bug item is open for this). When we do we need to make sure we test the case where you are not authenticated and use TemplateLogin. If the rest script also asks the Java applet to authenticate then we probably have the same problem again unless we design for it.

-- KennethLavrsen - 09 Dec 2008

References

• http://developer.apple.com/qa/qa2001/qa1265.html How to force cookie on the applet
• https://bugs.launchpad.net/ubuntu/+bug/306449 Launchpad bug report for gcj plugin

---

Resolved by making the editor only available when the current user is able to change the topic that contains the drawing. Not 100%, but good enough.

• CrawfordCurrie - 09 Dec 2008

On my installation it goes into edit mode right away but when you save it hangs for several minutes. Then times out and have done nothing but stays in the editor.

• KennethLavrsen - 10 Dec 2008

Were you authenticated? Are there any errors in the logs?

-- CrawfordCurrie - 13 Dec 2008

Bug occurs when

• You use TemplateLogin (remember to change the httpd config to not authenticate the bin files except configure)
• You are NOT authenticated before you hit Edit on the drawing
• You try to save

In ApacheLogin the applet prompts for username and password when you save and you are not authenticated.

There is nothing in the Apache error log. The java console reports an error with authentication. It attempts to send a Foswiki SID by cookie. But this is not valid because you are not authenticated so it is an old one.

-- KennethLavrsen - 16 Dec 2008

• You are NOT authenticated before you hit Edit on the drawing

Then you have to be using an old version (or something is borked). I changed the code so that an unauthenticated user is not presented with the edit link. At all, Ever. Can you please check that you are using the latest from Subversion, and that the edit link is disabled?

-- CrawfordCurrie - 17 Dec 2008

I am running a svn checkout from trunk, which I update many many times per day.

I am refreshing the browser with control-F5

I see the same in both FF and IE. Exact same behavior.

The edit link is NOT disabled.

It is a fine way to fix the issue but it does not work

• KennethLavrsen - 17 Dec 2008

Are you perhaps logged in as an admin? Can you edit the topic?

AFAICT it works fine.....

-- CrawfordCurrie - 30 Jan 2009

Have you tested as admin and seen it fail since you ask?

And yes I can edit the topic. That should be clear from the report.

The problem is that you are not authenticated BEFORE you edit the drawing AND use TemplateLogin.

-- KennethLavrsen - 31 Jan 2009

Perhaps you have misunderstood the intent. The idea is that you have to have CHANGE access to the topic before you will be presented with an edit link. If you have change access without logging in, then that constraint is satisfied and you will see the edit link. What you seem to be saying above is that you do not have CHANGE access, but are still able to see the link, which is why I asked if you are admin.

-- CrawfordCurrie - 31 Jan 2009

My friend. You have not understood the problem correctly. How can I be an admin when I have not authenticated???

Please try and reproduce the bug with the exact same settings as I describe. I will be very specific now. Hope it works out this way.

• You must have setup Foswiki for TemplateLogin
• You must have setup httpd config so that none of the bin scripts requires authentication and restarted the webserver
• You must have setup the access rights at both web and topic level to be standard out of the box. Ie. no DENYWEB or DENYTOPIC to guest for example. If you can authenticate you can edit must be the condition. This also means testing outside System web which is normally blocked for non admins.
• You must have a fresh browser window in a browser which has not yet authenticated in any other window
• No sticky sessions so the browser can auto login. Normal default setting so closing browser and starting again requires new authentication to edit a topic.
• You now arrive to your test page. You will see the drawing and you see the edit button. I do not know why you say one cannot see the edit button unless you have change access. That makes no sense. You are arriving unauthenticated which means Foswiki sees this client as WikiGuest. But even WikiGuest requires authentication to edit so attempting to edit a topic requires authentication. Once authenticated Foswiki knows who you really are. But we are not authenticating. We are just looking at the nice very visible and very clickable edit botton next to the drawing.
• We now click the Edit button next to the drawing. A new window pops up and then another with the Java applet. At no point am I asked to authenticate. Foswiki still has no clue who I am. Neither has the Java applet because I am not authenticated. I can edit. When I save, the applet hangs. The applet cannot authenticate using template login. This is very obvious. The applet is not able to get redirected to a html type login page, put username and password and hit submit. It just waits for Apache to ask for authentication which never happens.

In ApacheLogin this happens which is why it works.

• We have come to the point where we want to save.
• The java applet saves and Apache requests basic authentication. The applet can handle this. Java presents the user with a dialog asking for username and password. When given - the java applet saves the drawing. If you ask Java to save username and password it will even remember this so you do not need to give credentials next time.

In TemplateLogin when already authenticated this happens.

• I arrive to the page. I authenticate by clicking Login or by doing normal editing of the page. The browser is now authenticated and holds a session cookie.
• I click the Edit button of the drawing. Windows pops up, and then the Java applet window pops up.
• I edit the drawing and save
• The java applet has already the session cookie from the browser so when saving Foswiki/Apache is happy because the Java applet is seen has already authenticated because it can present the correct authenticated active session cookie. So the saving goes well with no username/password dialog required.

So what do we do?

In my view the JHotDrawPlugin should ask for login when you hit the Edit button next to the drawing if you are not already authenticated. The java applet should always when activated hold a valid session cookie. In TemplateLogin this would fix the problem this bug reports describes.

And even in ApacheLogin the experience is better this way because it can be a bit confusing that you suddenly get a authentication window that looks different than you are used to when Java asks for username and password. It would be better if being not authenticated and clicking Edit for a drawing instantly required a normal browser login dialog. It seems strange that you are allowed to open the drawing tool and alter things and it is not until you want to save you are asked for credentials.

At Motorola I have none of these problems because I have setup our server to always require authentication even to view normal topics so people are always authenticated. And we use ApacheLogin on top of it (with mod_ldap). So it is for the TemplateLogin guys I am fighting to get this plugin working in a satisfactory way.

Hope you are able to reproduce and understand the problem now.

I have confirmed today that the problem is still there.

-- KennethLavrsen - 31 Jan 2009

OK, the problem is due to the check needing to include a check for an authenticated user.

-- CrawfordCurrie - 31 Jan 2009