Old PermissionsProblems are moved here, most recent at the bottom.

hmmm .. I have a permission problem with the RecentChanges? page on a new installation of ZWiki 0.6.

Logged in as manager I receive following traceback: (removed)

If I give access rights to anonymous everything works as expected (but that's of course no solution).

btw: Zwiki is really cool.


So that's what the new validate does :). Thanks, I'll look into this --SM

Okay .. I went into this today and I had a look into the original validate function, which is defined in cDocumentTemplate.c

This is, what I've found. If you change validate in ZWikiPage.py around line 500 to:

         if roles is None or ("Anonymous" in roles): return 1    
         try: #see here if AUTHENTICATED_USER is authorized
             if md.AUTHENTICATED_USER.has_role(value,roles): return 1
         except AttributeError: pass         
         if inst is parent:
             raise 'Unauthorized', (
                 'You are not authorized to access <em>%s</em>.' % name)

everything works fine. But I'm not comlpetely sure, if I'm right here. So this should better treated very carefully :) --ThomasW

Yes (for it is subtle, and quick to anger). I believe this is caused not by the new validate method but by the fact that RecentChanges? and similar pages require the Access contents information permission to do their work. (I had this permission assigned to Anonymous in my root folder). I think this is reasonable, so I have documented it in zwiki_examples/index_html.

Comments ? --SM

hmm, I'm not really convinced :). With the new validate function, you have to assign the access contents information permission to Anonymous to see the RecentChanges?. If I delete the validate code and restart Zope, I can access RecentChanges? as Manager without giving Anonymous the access contents .. permission.

But maybe I'm missing something here. --ThomasW

I s-e-e... so: as of the 0.6 release, when a zwiki page is rendered, any embedded DTML runs with permissions equivalent to Anonymous. This is a safety feature.

As a result, now the Anonymous role must have "access contents information" permission on the folder for RecentChanges?/JumpSecrch?/SearchPage? to work, regardless of who you are logged in as.

Ack! Set the "Access contents information" permission and then it messes up a manager/owner from automatically viewing "manager_main". It's annoying!

I think that's the way it has to be for now. So I'll make this clearer in the docs. Other ideas welcome. --SM

Yup, let the DTML execute with any proxy roles the ZWiki Page has, otherwise execute with NO roles... You could then let pages like RecentChanges? even have the Manager proxy role and be safe (just don't give anyone except manages the Modify Wiki Pages permission on that object -- ChrisW?

Sounds plausible.. let's discuss on IRC --SM

Proxy roles should work fine in 0.7.0 --SM

I am having problems with the validate code. The basic principle (running DTML as Anonymous) seems ok, but I feel I should be able to call a DTML method that has a proxy role set and gain the additional proxy permissions. For some reason this doesn't appear to work.

I tried adding back in the bit about proxy roles from the DTMLMethod oldvalidate method, but that doesn't seem to have any effect help. --DuncanBooth

Proxy roles should work fine in 0.7.0 --SM

I installed the .6.1 version, and now anonymous can't edit any pages. I've changed the permissions as documented except I don't see " grant the Change ZWiki Page permission; and to allow page creation, grant the Add ZWiki Page permission. " anywhere in my installation. --Graham

*The permissions should be listed under the Security tab when you visit yourwikiurl/manage_main. Let me know if you still see a problem with 0.7.0 --SM*

In ZWiki 0.6.1, how can I set up a ZWiki folder that does not allow Anonymous users view access? If I remove View permission for the Anonymous role in the folder, then RecentChanges? doesn't work for authenticated users. -- BobFinch

you're right, should be fixed in next release. possible workaround: remove getSize and other attributes requiring view permission from your recentchanges page --SM

should be fixed in 0.7.0 --SM

AUTHENTICATED_USER reveals dual personality.

There is some problem with AUTHENTICATED_USER being overtaken or ignored in DTML Methods in some cases but not others. This might be an echo of the permissions issue above, but it's a significant problem for me since I want to present things differently to users with different roles.

The problem is easily shown in standard Zope 2.1.6 and ZWiki 0.6.1. Create a new ZWiki or ZWikiWeb and a user (say Test1) with Manager role (and able to Change Wiki Pages). Then choose a format (I used structured) and edit both editform and standard_wiki_footer to include the lines:

    <em>User name</em> <b><dtml-var "AUTHENTICATED_USER.getUserName()"></b>
    <em>User role(s)</em> <b><dtml-var "AUTHENTICATED_USER.getRoles()"></b>

Now start a new Web page and select the appropriate FrontPage. You'll see your username is Anonymous User and role is Anonymous. Now edit.

You'll need to log in to save the edit, so log in as Test1. That's fine, but the FrontPage display shows you still, incorrectly, as Anonymous User. Press the edit button again. Now, correctly, you're Test1, with role of Manager.

To check this, create a DTML Method TestPage with the contents <dtml-var REQUEST>, and link to it from the standard_wiki_header. Depending on which page you jump from you will see one or other of your AUTHENTICATED_USER personalities.

Now try a new TestPage1 that is a DTML Document (not Method). Same contents. Link to it through standard_wiki_header, alongside TestPage. You can replicate the behaviour above. Now jump to TestPage1 from FrontPage and the proper behaviour occurs (i.e. you are seen as Test1 and no longer Anonymous). Back at FrontPage (after a refresh) you are now, correctly, Test1. Back at TestPage (the Method) you are now, correctly, Test1!

I tried a relevant-looking Zope patch (Brian Lloyd's one about __roles__ = None from the archives - I've lost its details for the moment) and the ZWiki role patch mentioned above without noticeable effect.

This isn't right is it? Any pointers / patches would be welcome.

Workaround. Encourage a login at the FrontPage, by creating a Login link to a DTML Document (named "login" for example). The login page should have its security changed so that Anonymous cannot view it, thus forcing the login. The login page can contain an automatic redirect back to FrontPage.

The login works reliably - FrontPage now always shows the real logged-in you.

The strange behaviour logging in through the edit page persists. What's more, if you have FrontPage showing incorrectly that you're anonymous, you can now press the Login link which recognizes the real you without asking for your name and password again and instantly redirects back to FrontPage with your real login displayed.

--GeoffGardiner 2000-05-26.

I want to note here that this - below - is still a problem with a new installation of Zope (2.2.4b1) and ZWiki (0.7.1). Just stick <dtml-var AUTHENTICATED_USER> up in your standard_wiki_header and watch your login change! --GeoffGardiner 2000-11-27

Sorry Geoff, this is one I have been avoiding until I'm feeling wizardly.. not forgotten though.. --SM

2001/04/24: Yes - I see what you're saying. I have experienced this too and tend to believe it's a browser quirk. As if sometimes the browser has indeed acquired the authentication but does not present it to the server until it's really required, so the page doesn't know about it. I have had to handle it as you did, by forcing an authentication challenge. I wonder if jcForceAuth is at all relevant. --SM

I've just tried this but couldn't get it to appear as a Product. My login page is a simpler solution but that's currently working intermittently - I just can't work it out (as usual)! --GG

bypassing write protection via bookmarks

2001/Jan/21, kas: On several occasions I have been able to create new pages on otherwise write-protected zwikis by first mentioning the WikiName in the BookMarks? field of the UserOptions? page, then clicking the question mark. Is this a (known) bug or a feature?

This would be a bug, and unexpected. Are you sure about this one ? can you link an example here ? --SM

2001/May/22 Here is something that appears to be a browser-specific problem. If you are using Mozilla 0.9, even after you are authenticated, when you go to edit a new ZWiki page, there is a "login required" next to the ChangeXXX? button. If you edit the page and hit ChangeXXX?, you lose the changes, but the login required message goes away. Once you have hit ChangeXXX? for a particular page, future changes are not lost. I've tried this with NS 4.75 and IE 5, and the changes are not lost.

Where are the permissions that control whether or not the "append a comment" is present on a page? thanks, Mark Madsen

It's something like "Append to ZWiki Pages".. but make sure the form exists in your standard_wiki_footer. If not, [standard_wiki_footer/view_source]?