Question

When using the NatSkin v2.92 (2005-12-05) with NatSkinPlugin v2.93 (2005-12-06), after Login through the NatSkin mechanism on the webpage, I need to authenticate again through the browser-login-box for the first to edit of any topic during that session.

This behaviour is the same with different browsers (IE, Mozilla, Firefox). When using a different skin, without an own login mechanism it works correctly, with only the login-window from browser appearing. If Proxy-Settings are different (wrong), even for viewing a login-window from browser appears. We installed the same TWiki and NatSkin-Version on a Linux-Server (Suse 9.3 with Apache 2.0), with the same issues.

How can I disable the second login window from the browser? Of course it needs to be secure, when temporarily changing the skin... Any Ideas? Thanks for your Support!

The Story in pictures:

• NatSkin Logged in:
  

• When editing a page first time during the session an annoying additional Login-Window of the browser appears:
  
  
• If login is cancelled the webpage looks like this: WebHome_Edit_Error.htm

Environment

-- ChrisHausen - 11 Apr 2006

Answer

If you answer a question - or someone answered one of your questions - please remember to edit the page and set the status to answered. The status selector is below the edit box.

Simple: edit the file bin/.htaccess and comment out sections containing require valid-user and any Auth* configuration. This will disable the second authentication dialog. Note, that the latest NatSkin/NatSkinPlugin supports twiki's all other standard login schemes besides the buildin natlogon scheme. I added a related configuration documentation to NatSkinPlugin.

-- MichaelDaum - 12 Apr 2006

Thanks for your quick reply. Seems simple, works and disables the second authentication, but if the skin is changed, for example just by adding ?skin=pattern to the URL (also as User or Web-Preferences-Setting), everybody can edit the pages as TWikiGuest without any authentication. What needs to be done to close that "security hole"?

-- ChrisHausen - 12 Apr 2006

Chris, there is no security hole, at least not the way you described Try it.

-- MichaelDaum - 12 Apr 2006

Michael, well, I tried it on both installations, still having the "security hole" doing following:

1. starting browser from scratch
2. opening any topic within sandbox
3. adding ?skin=pattern to URL
4. using EDIT button from pattern skin to edit
5. during, edit, the NatSkin layout appears, but containing all buttons to save and quit
6. modification of page is successful.

I also tried to remove the TWikiGuest user, but then, the topic is just edited as Main.guest.

I attached my updated .htaccess-file, did I do anything wrong there? Do I need to change my configuration somewhere else?

-- ChrisHausen - 13 Apr 2006

Most probably your Sandbox web is world writeable. What are the access rights in Sandbox.WebPreferences?

-- MichaelDaum - 16 Apr 2006

OK, that did the trick! I just did following setting to WebPreferences (i.e. WebPreferences) on my TWiki: Set DENYWEBCHANGE = Main.guest, TWikiGuest, which is a setting which is not necessary for the standard skins.

Thank you very much for your help! That pushes me a lot forward on my TWiki-Implementation in my department. I very much like the NatSkin because of its nice and well customizable layout and the very neat search/jump functionality at the top right, which is similar to the GnuSkin which I used before, but much more advanced!

-- ChrisHausen - 18 Apr 2006

Great to hear that. Thanks for the positive feedback on the NatSkin.

One closing remark: twiki's access right lists should be as tight as possible for the site policy that you intend to implement.

Furthermore this all is more a thing of authentication and authorization. There are different authentication schemes: htaccess realm, template login, natlogin. The latter is only available on NatSkin and was superseded later by dakar's template login scheme. All schemes except htaccess realm force authentication on lack of authorization. The htaccess realm scheme forces authentication based on the action to be performed. This is completely decoupled from the authorizations expressed in the ACLs of a resource.

I think you ran just into this discrepancy. And this is definitely a point where twiki could improve.

-- MichaelDaum - 19 Apr 2006

http://ntp.isc.org/ uses also the NatSkin.

-- FranzJosefSilli - 19 Apr 2006