• Do not register here on develop.twiki.org, login with your twiki.org account.
• Use View topic Item7848 for generic doc work for TWiki-6.1.1. Use View topic Item7851 for doc work on extensions that are not part of a release. More... Close
• Anything you create or change in standard webs (Main, TWiki, Sandbox etc) will be automatically reverted on every SVN update.
Does this site look broken?. Use the LitterTray web for test cases.

...I wouldn't have noticed, but the PreferencesPlugin explicitly asks for bin/viewauth.

I guess it is simply a copy of bin/view, so I suggest to add it to the tarball (a symlink wouldn't work here because following symlinks is forbidden in my apache config).

Hmmm... I seem to be unable to submit from my TWiki:Main.HaraldJoerg account, while others can.

The convention is for symlink or copy, if the script is used. But since most sites use TemplateLogin, viewauth isn't needed. So I don't think we should ship it.

If the documentation is insufficient, please highlight where it could be improved.


Sorry if my description wasn't clear. I agree that TWiki can live fine without viewauth. But $dist/lib/TWiki/Plugins/PreferencesPlugin.pm has it as an (undocumented) prerequisite for viewauth. I guessed that shipping viewauth would be easier than changing the plugin, which was a bad idea.

Just try to (Click for form-based editing of existing preferences) on http://develop.twiki.org/~develop/cgi-bin/view/TWiki/TWikiPreferences to see viewauth in action....

One could add "needs viewauth" in the installation instructions for PreferencesPlugin. But I'd still hope that it can be fixed in code - what happens if we change 'viewauth' to 'view'?

From $dist/lib/TWiki/Plugins/PreferencesPlugin.pm:

    my $viewUrl = TWiki::Func::getScriptUrl( $web, $topic, 'viewauth' );
    $_[0] = CGI::start_form(-name => 'editpreferences', -method => 'post',
                            -action => $viewUrl ).

-- TWiki:Main.HaraldJoerg

Also TWiki:Plugins.EditTablePlugin uses the viewauth script. I could fix both plugins, but I'm not sure of what's the proper behavior as they're trying to "force" authentication.


Proper behaviour is for plugins to behave themselves. A plugin that intends to change a topic should use the edit script, not hack around the view script. However, we do not have proper behaviour, so we have to work with what we've got. Arguably the build system should generate *auth versions of all the scripts in bin. However that would be confusing, as edit is by default an implicit editauth. The expedient solution is to create and check in (and add to MANIFEST) viewauth as a copy of view. The risk is low; the view script is unchanged for many months.


i'd recommend using symlinks instead. the way i interpret the docs, windows users will end up with copies rather than symlinks in their working copies.

should i checkin symlinks versions? which scipts need auth versions?


try it, and see - I know none of the apache's i look after allow following symlinks, and develop.twiki.org's config makes it really nasty

the other thing was that in previous releases copying those files was one of the things that had to be done by the peter when he created the release archive

-- SD

EditTablePlugin and others depend on an authenticated viewauth. This needs to be supported, hence the need for a symbolic link or simply a copy. A simple copy in the distribution for viewauth and rdiffauth (by build script) seems sensible since the scripts are stubs anyway, so admins are not likely to change them. In addition, some admins might miss creating the symlinks for viewauth and rdiffauth when installing TWiki manually.

-- PTh

For Dakar we can add viewauth to the build scripts; but this usage of viewauth should be deprecated, as it is undocumented and is very fragile. Authentication should be handled (is handled) by throwing access control exception when a forbidden access is attempted. The plugin should be smart enough to raise such an exception when an edit is attempted. viz

unless( TWiki::Func::checkAccessPermission( 'change', ...)) {
   throw TWiki::AccessControlException(...)

SVN 7293


Can we not detect the plugins that use viewauth and reissue them to avoid doing so?


Summary Dakar Beta: bin/viewauth missing
ReportedBy TWiki:Main.HaraldJoerg
AppliesTo Engine
Priority Normal
CurrentState Closed

Checkins 7293
Edit | Attach | Watch | Print version | History: r12 < r11 < r10 < r9 < r8 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r12 - 2005-11-04 - MartinCleaver
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback