myroot namespace is restricted to only a few users. like this if people without the rights for the root namespace are promted for a login and password but afterwards read the message “you don't have the right's to see this page”. Instead it would make much more sense to provide a list of namespaces and pages they actually can access with their rights. How would I do this? can I redirect them to the index somehow right after logging in?

thx

User and user: If you add a user to a new group, and then you give this group new rights to a specific namespace, it is necessary to use the same letters - either capital or not, when giving the group rights on the accessmanagment-plugin. (USER and user ist not the same group)

I can't get an Edit button for the Start page despite being an admin. (This seems to be a problem only for the Start page.) My user id is in the configuration file as superuser, I'm also shown in the acl page as having full power, I even set up a separate permission for the Start page specifically giving myself editing privileges. Yet even when logged in I only get a View Source button, not an Edit button. Can anyone tell me why this is happening? Thanks!

- Jee

Oh well, looks like it's been solved. I just deleted the start.txt file and started over–works fine now. I'll jot down an error message I got in the process, though, in case it becomes a problem later:

Writing /web/home/loki/html/wiki/data/meta/start.meta failed

I no longer got this error message, either, once I deleted the start.meta file. I just go deleting things all over the place :)

Deleting individual files didn't work for me. I had to “delete” the entire tree, but it worked. I was getting a bunch of errors on each page until I cleaned out everything from ….\meta on down. Once I renamed the \meta folder and created a new one, I got zero errors relating to write failures. I don't even need the Safemode Hack. — DGM2 2007-11-20 01:04

I just upgraded to the 2006-11-06 version of Dokuwiki. I use LDAP authentication to Active Directory. The 3.9.2006 version works with my acl.auth.php file perfectly. However, after upgrading to the current version it appears the file is being ignored. Is anyone else experiencing this?

Further investigation on my part has found that this is directly tied the the /inc/auth.php file. If I replace the 11.6.2006 version with the 3.9.2006 file all works well. Is this a configuration issue on my end, or a bug within the new version of the file?

Scott 2006-11-11

– I have the same issue. happened after the upgrade.

– Does anyone have a fix for this, is this planned to be fixed in the next release?

– Idem

– working fine now…. not really sure what the deal was :o)

I have a long list of namespaces, when I scroll down to click on one to open it, I am then taken back to the top of the page. Then, I have to scroll back down to the namespace. If there is a namespace beneath that, I click it, get taken back to the top of the page and so on and so on. Is there a plug-in, or future enhancement to allow namespaces to be opened without taking you to the top of the page? Or is there a way to make each namespace an anchor, so the namespace is taken to the top of the page only (this would be good for the top-level namespace, not for the sub namespaces).

Any help or direction would be greatly appreciated.

- Scott

good

I finally got my ACL almost all set up after a couple of hours. Can register users, no problem at all. But when I log in as the superuser and click on “admin” → “configuration” I get a table with the following (German) text above:

“Die Konfigurationsdatei kann nicht geändert werden, wenn dies unbeabsichtigt ist überprüfen Sie, dass die Dateiberechtigungen korrekt gesetzt sind.”

Basically saying: The configuration file can't be changed. Please check that all permissions are set correctly.

There is no “save” button so I can't save any changes to the table. That's really bugging me. Via gFTP I set the permissions on nearly every file to be readable, writable and executable for everyone. Still seems, I missed the right one. Or what else have I done wrong??
Melanie 2006-06-29

Taken from lib/plugins/config/settings/config.class.php

    // configuration is considered locked if there is no local settings filename
    // or the directory its in is not writable or the file exists and is not writable

To fix this, you should change the permission on the conf folder.

chmod 777 conf

Andrei Gavrila 2006-07-28

Adding another ACL discussion page, ACL2 around my attempted implementation. — Josh 2005-03-14 17:49

Could the register process use a page named with the username, to set some site preferences? For example, the date format to output, the timezone where the user is, the full name and the nickname, the e-mail address and the password, and so on and so on. Of course, this page should only be visible to WikiAdmin and the user itself.

I think the only kind of user preference that could/should exist is the user's password. DokuWiki stores everything in text files, and will not be able to differentiate between dates in users' signatures and dates in DokuWiki pages–so a timezone offset will not be possible.

Agreed, certainly a change password / reset password option is required where I work. Timezone doesn't really matter a lot as long as its clear what TZ the host computer is using.

I am now thinking that it would be a good idea for the signature button to write the server timezone, too. Eg. 27.10.2004 15:10 GMT

All options are set for acl use, but I can't register any user. Everytime I want to register a user it gives me the message “user exists”. But there aren't any users registered. So I tried to put in a user manually in the users.auth and generating the hash with md5sum without success = password or username wrong. I'm using apache 1.3 on slackware and dokuwiki 10.11.2004 hoergen

users.auth needs to be writable.

When I change USEACL to 1 I get the following message: “Sorry, you don’t have enough rights to continue. Perhaps you forgot to login?”. This is even though @ALL is set to 4. So I go to log in, but the screen doesn't change. I am working on a Windows ftp server for the first time. All files and directories are apparently wrx. Any ideas?

I have the same problem, Why if I made users.auth writable and $conf['useacl'] = 1; $conf['openregister'] = 1. ¿? Hope soon answer. Thanks in advance.

I'm also having this problem. Maybe it's the most recent release? I'll try an older one… Yes, that seemed to fix it. The 2005-05-07 version seems to work. It seems that acl is broken (or maybe changed?) in 2005-07-01

And here too :( Can anyone confirm that the latest will work with ACL under *nix? Or have I got to grab the earlier build?

I run devel version (2005-07-11) on Gentoo and it works fine. My recollection is there haven't been any bugfixes concerning ACL since 2005-07-01. At some point, I don't recall when, the two plain auth files acquired a ”.php” suffix (users.auth.php & acl.auth.php). I do recall seeing some code to automatically convert the old files to the new, though I couldn't locate it in a quick search through my site. Check you are using the new files and they are both writable by your webserver. The only difference between the old files and the new is the presence of these four lines at the top

# conf/acl.auth.php  (or # conf/users.auth.php)
# <?php exit()?>
# Don't modify the lines above
#

ChrisS 2005-Jul-14

Just tried the new 07-13 build under windows, and still can't get past the “Sorry, you don’t have enough rights to continue. Perhaps you forgot to login?” message which appears when trying to get to the login screen!

Same problem here with the 07-13 build under Fedora. Login is impossible, because of “Sorry, you don’t have enough rights to continue. Perhaps you forgot to login?” (Carsten, 2005/07/15)

I was upgrading to 07-13 and having the problems above. I actually deleted everything, and reinstalled 05-07, but then it occurred to me that I had (a) downloaded the files from Unix to Windows and was uploading them; and (b) when I did edits (e.g. for user.auth.php and acl.auth.php), was being sloppy in using Notepad, rather than a UTF-8 editor (i.e. Crimson Editor, with settings done right!) On the second time I uploaded, I used the FTP program to chmod everything to 777. This now seems to be working for me. {David Ing, 2005/07/17}

I changed from 07-13 to 05-07 on Fedore Core 4, but still see the same problem. Things work fine as long as I do not enable ACL. But with useacl set to 1 I have to log in, but have no permissions to do so. Changing permissions to 777 did not help. All files are owned by apache:apache. I noticed that the cache, medai etc. directories moved into the data directory on 07-13, but since the version does not seem to make a difference for me, I guess this is unrelated. (Carsten, 2005/07/18)

I got 07-13 to work. I only had to copy users.auth.php.dist to users.auth.php and acl.auth.php.dist to acl.auth.php. I guess I missed that part in the documentation somewhere. (Carsten)

Confirmed. I was having the same issue. Renaming the files mentioned above solved the problem.

You just need to have a line like

*       @ALL    4

in acl.auth.php - this is neccessary to get permission for any page (e.g. Login form). Unfortunately this permission is inherited for all other namespaces - so you also have to set permissions

YourHiddenGroup:*       @ALL    0

to all secured namespaces. It seems the whole permission management process is not very failsafe this time . Good luck : deka

After installing, I went to the playground, and it was locked (as were the dokuwiki and syntax pages under wiki). How do I unlock it and make it available for playing in the sand?

Figured it out … chmod.

— Randal Matheny 15.11.2004 21:08

To allow me viewing the changelog, I cheated … I did a softlink to the changelog file from the /data folder (called it changelog.txt), which made the file loadable within dokuwiki via [[changelog|Show ChangeLog]]. Now, problem is now people can edit it if they know its there (I hided my link to it - not telling exactly how ), I am dodgy on ACL, but can just certain files be made writable by the wiki and protected from users, or is it all or nothing, cause if I chmod 644 the changelog file its also not writable by the wiki.

— Marco Piampiani 02.12.2004 03:17

If you enable the ACL feature as described here you can protect that page without chmod'ing it. — Andreas Gohr 02.12.2004 09:13

I did a simple, quick hack that allows IPv4 address ranges (CIDR 8/16/24/32) to be matched in the ACL rules. This is useful when a page is public, but should only be editable by a local subnet without requiring people to register and log in. In auth.php:auth_aclcheck, at DokuWiki version 2006-11-06 around line 306, please apply the following patch (unified diff compatible with Linux/UNIX patch):

--- inc/auth.php            2007-05-09 17:02:00.053328494 +0200
+++ inc/auth.php.rsc        2007-05-09 20:00:51.418239336 +0200
@@ -306,6 +306,14 @@
     $regexp = '@ALL';
   }
 
+  //add the IPv4 address to the regexp
+  $ip = split("\.", $_SERVER['REMOTE_ADDR']);
+  $groups[] = $ip[0].'\.'.$ip[1].'\.'.$ip[2].'\.'.$ip[3];
+  $groups[] = $ip[0].'\.'.$ip[1].'\.'.$ip[2].'\.\*';
+  $groups[] = $ip[0].'\.'.$ip[1].'\.\*\.\*';
+  $groups[] = $ip[0].'\.\*\.\*\.\*';
+  $regexp  .= '|' . join('|',$groups);
+
   //check exact match first
   $matches = preg_grep('/^'.preg_quote($id,'/').'\s+('.$regexp.')\s+/',$AUTH_ACL);
   if(count($matches)){

The ACL would then have the IP address range you want to allow access to in the following form to allow the 192.168.1.0/24 subnet (i.e. with a subnet mask of 255.255.255.0):

wiki:discussion:acl	192.168.1.*    8

This solution is tested and should work for IPv4 networks at all. Maybe the IP should be prefixed with some kind of character to mark it as an IP type, otherwise there are ways to confuse the ACL and possibly allow users to have more access to specially named pages that originally intentioned.

Also please refer to the Wiki Security:IP Address Verification page to become familiar with the security risks involved with IP-based security. Chris Lee

Question: Is there a way to submit the login information to dokuwiki embedded in the url? (i.e. for bookmarks or for crawler)

Solution: add ?do=login&u=user&p=passwort to the url-link. (BTW: it works also without do=login, is it really needed?)

If a user has no right to see a given page, he won't know it until he tries to follow the link (and get the log-in dialog presented). For better usability, it would be very nice, if links to protected content could be marked. (p.e. with a little leading \”no-enter sign\”).

I understand, that DokuWiki would have to check all links on a page (before displaying them) for the rights, the current user would has on them. I guess this would break caching and maybe it would effecting performance badly.

An other way could be using java-script. Because it is a nice-to-have feature, clients with scripting deactivated could still see the content. — Konrad Bauckmeier 2005-11-28 10:46

Even with ACL's in place I found that I could access the raw text files directly using:

http://a.b.c.d/data/pages/test/test.txt

To prevent this, I simply moved the data directory outside of the website's DocumentRoot (I'm using Apache2) and updated $conf['savedir'] to point to the new path.

I also set PHP's open_basedir variable for added security.

— Andy Lee 2005-12-05 04:12

I think this is a good point to enhance safety. You can also could prohibit your web server to serve .txt files in the configuration or in the .htaccess - file
My (shared) Webspace provider has done this already, so I get error 403 \”Forbidden\” if I try to access the files directly.
— Konrad Bauckmeier 2005-12-05 17:28

Another solution would be to put a .htaccess file in the data directory to block everything

We want to establish DokuWiki as a knowledge base++ (so to speak) in our company's IT division. So we decided to reuse a Windows Server 2003 SP1 machine. We installed XAMPP 1.5.1 which consist of (only the relevant parts I hope):

• Apache 2.2.0
• PHP 5.1.1 + PHP 4.4.1-pl1 + PEAR

With PHP5 the ACL admin page only gives a Fatal error: fatal flex scanner internal error–end of buffer missed in C:\Program Files\xampp\htdocs\lib\plugins\admin.php on line 169. We would rather avoid switching to PHP4 as the templater does not reliably work (or so it seems). Does anyone know how to fix this? A newer/older version of PHP5 (and therefor XAMPP), maybe? Or changing the file, or anything like that? Many thanks in advance,

Dieter Stehle I had the same problem and the solution is: the '?>' end is missing. The scanner cannot find the end of the php script.

Sebastian Fontius

I also had that problem (XAMPP with PHP5), and it appears that adding a blank new line after the last line in the admin.php file works.

I added a blank line after the last line. It works now without an error but I can't see/get access the links of the installed plug-ins, e.g. access management or user management. Can you help me? Many thanks in advance,

Peter K. Siebert

Same problem here. Did anyone find a solution to get the administration working while running php5?

Andreas

Got the same problem. Only a blank Admin page with the first line:

Folgende administrative Aufgaben stehen in DokuWiki zur Verfügung.

» is visible. Any solution? Rafael

Seems to be a language problem. Switching to “en” has fixed that for me

I also experienced this problem with XAMPP 1.5.1 and the german (de) language profile. As mentioned above switching to “en” fixed that problem. Today I moved to XAMPP 1.5.3a and now I can “ADMIN” in german. Cheers, Frank! — Franky 2006-07-22 11:33

How do I restrict access to unregistered users from editing/creating a new post and how do I let registered user create new posts?? Any help would be appreciated.

Go to Admin » Access Control List Management - you can change it there.

I also have the same problem. (Both 2006-11-09 & 2006-03-09 version) I think the upload file should be read by the user who has the read permission. — Jonathan Tsai 2006-11-28 00:12

I have problem with acl. How can I set permissions on media? Let's say I have page www.foo.com/wiki/doku.php?id=2006:flash and I restrict it only for some users to see with acl. Now I upload a image to this page. I have read write access to all pages but users only have access to this page. What must I add to acl for users to see the image?
— a.t.b

On 2006-11-06 i made small hack. Comment lines from 51 to 56 in /wiki/lib/exe/fetch.php. Comment this

    if(auth_quickaclcheck(getNS($MEDIA).':X') < AUTH_READ){
      header("HTTP/1.0 401 Unauthorized");
      //fixme add some image for imagefiles
      print 'Unauthorized';
      exit;
    }

— Alpmild 2007-02-27 13:48

How about adding a new ACL level which allows a user/group to modify the ACLs for the pages into a namespace? It would be useful if you want to let some users to manage a namespace or so, without requiring super-user intervention.

That would be useful for me too

We use Dokuwiki on our corporate intranet, and I have setup LDAP/AD integrated authentication, which is working nicely. However if users want to login, they still have to visit the login screen, and enter their username & password. Would it be possible to somehow setup dokuwiki to automatically detect the user’s current logged on username & password? I thought James Van Lommel's solution using adLdap found here http://wiki.splitbrain.org/wiki:auth:ldap sounded like it might do the trick, but I've set it up following his instructions, and I still get the login screen. bjb 2007-01-15 14:20

These options are shown as checkboxes which is quite strange. I've tried to set permissions “Upload” and “Read” but actually I got all actions from “Read” to “Upload” allowed. I thought that it's a bug but read the manual and now I've got it So is there a way to set permissions separately (not by auth level)? Constants are power of 2 so we can combine it. And if not I suggest two things:

• to change permissions with a radio buttons (it's more logical)
• separate media upload and delete from page creation/edition (that's logical, too - one may want to create pages in some namespace by himself but allow uploading files for everyone) — ShTiRLiC 2007-02-01 02:55

In our wiki we have an internal area that is only accessable by a few people. Is there a way get the recent changes list to reflect changes made on those internal sites (but only for people who can access them)? — Jan 2007-05-03 17:49

I am having difficulties creating new user groups in my WIKI (2006-03-09b). In order to create the new user groups I am just adding them to the acl.auth.php file. Whenever I add a new user to any of the new groups, he/she can't get access to any page, and the LOGIN REQUIRED message appears.

 
*					@ALL		0
 
*					@user		1
 
*					@new-user	16
*					@new-guest	1	
 
discussion:*				@user		8
projects:*				@new-guest	0
howcraftthewiki:howcraftthewiki 	@new-guest	0

I assume I am missing something, but I've been stuck with these for quite a while. Any help-suggestion would be appreciated.

Dan 2007-08-27

Hi, is there an easy way to configure/modify an ACL-enabled DokuWiki such that it displays the “Login” page directly (instead of the “Permission Denied” page where you would have to click on “Login”) when calling the Wiki?

I tried modifiying the index.php file in DokuWiki's base directory, making it redirect to doku.php?do=login, but this doesn't work. Suggestions are welcome.

— Christian 2007-09-12

I don't know the exact background, but I solved this problem by adding a line

<html>
<meta http-equiv="Refresh" content="5;url=http://www.yourwiki.com/doku.php/start?do=login">
</html>

into a file denied.txt in /…/yourwiki/inc/lang/yourlanguageabbreviation folder. You need to have HTML enabled in admin settings. This line redirects you after few seconds to the login page. You can also put a welcome sentence here in denied.txt since it's the first page one can see. You can see it working here.

— Jan Dostal 2008-01-04

I have a namespace TODO. I would like to give users of the group devel access to create pages under that namespace. There after they should have full access to that page they created. However they should not be allowed to edit other users pages. Is this possible with the generic ACL plugin?

— Morten 2007-11-30

I would like to give the whole world read access to the root namespace, which I've done. Then, I want a “private” namespace that only people in the “users” group can read and write to.

In order to do this, you'll need to add 2 ACL permissions to the private:* namespace. First, add a set of permissions for the group ALL. Don't check any boxes, since we want ALL users to have NO ACCESS to this area. Then, add another set of permissions for the group users. On this one, check all of the boxes you want users to have.

Now, only private users will have access to the namespace.

I tray to manage access to our dokuwiki with acl's. That work grait. User with lower access-priority (aka DAU's) can't access the “hot-topic-sites”. If a dau searches for secrets he cant find them.

BUT:

If a DAU uses the index of our doku-wiki, he has full-access to the hole dokuwiki! :( We are using dokuwiki rc2008-04-11 and the monobook-template.

Is there a way to close this “backdoor” or is it possible to rule the access-rights for the toolbox?

— Django 2008-04-24

He has not full-access, he can only views namespaces and pages name but not their content. You can disable it with sneaky_index.