• 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'm using LdapContrib which doesn't create a Main.User file for new users. Using the EditTablePlugin, authentication doesn't work when trying to edit the table.

All other Access Control settings work as expected without a Main.User file.

EditTablePlugin should function without Main.User files, just like the rest of the TWikiAccessControls

That's sounds unlikely. IIRC EditTablePlugin redirects to viewauth which is supposed to be an authenticated script, so should trigger a login. Failing that, when the edit is saved there should be an access control violation if access isn't permitted - otherwise anyone could use EditTablePlugin to save content.

Please check that viewauth is set require valid-user. Can you save content without logging in?



Has any other developers tried to reproduce this?

EditTablePlugin is a default plugin and any access right issue will be a release blocker.


I have tried to emulate the situation.

I am not familiar with LdapContrib as such. But I am familiar with normal LDAP auth where Apache takes care. And to emulate this I did the following.

  • Added a user called TestGuy in .htpasswd
  • Did not register him or create any home page for him.
  • Used Apache Login instead of Template

I can then log in as TestGuy and I can edit topics and I can use EDITTABLE tables.

If I put an ALLOWTOPICCHANGE to someone else you cannot edit the topics and you cannot edit with EDITTABLE.

So I am sure that either it is an LdapContrib issue which I doubt. Or as CC suggests lack of authentication of viewauth.

I am lowering this to normal.


Waiting from feedback on questions from reporter.


No feedback, so discarding under the 30 day rule.


What 30 day rul are you referring to?


The 30 day rule documented against the Waiting for Feedback state: the report was insufficient to analyse the issue, and more feedback is needed from the person named in the "Waiting For" field. Once the reporter has added feedback they should flip the state back to "New". If feedback is not received within 30 days, the issue will be discarded.


Peter. The 30 day rule does not mean that the reporter or someone else cannot come back and flip it back to new - after having provided the needed feedback. But if we just leave the bug items that noone can reproduce without more feedback from the reporter - we will end up with 1000s of waiting for feedback items at the end. I think 30 days is a long time to wait for feedback. If you raise a bug item and the developers ask for more information I would expect the reporter will check up on his own bug items at least weekly to see if there is progress.

I bet the reporter in this case in reality just had forgotten to authenticate viewauth in the Apache config. It is an error we have seen before. But he never came back and said he made it work or he just gave up and did not care.


Summary Access Control only works when Main.User file exists
ReportedBy TWiki:Main.CurtWilhelm
Codebase 4.0.5
SVN Range TWiki-4.1.0, Thu, 04 Jan 2007, build 12435
AppliesTo Extension
Component EditTablePlugin
Priority Normal
CurrentState No Action Required
WaitingFor TWiki:Main.CurtWilhelm

TargetRelease n/a

Edit | Attach | Watch | Print version | History: r10 < r9 < r8 < r7 < r6 | Backlinks | Raw View |  Raw edit | More topic actions
Topic revision: r10 - 2007-04-10 - KennethLavrsen
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2022 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback