Learn about DokuWiki
Learn about DokuWiki
This page is no longer active. Use either the fckgLite mailing list or the dokuwiki forum
Lets say that you have DokuWiki, what can be accessed from the internet and has confidential files, what are protected with Wiki ACL.
If you have installed fckgLite, then all your files can be accessed without logging in: http://yoursite.com/wikitest/lib/plugins/fckg/fckeditor/userfiles/flash/secret/file.zip
In worst scenario +Indexes is on (Apache directory listing is allowed) and everyone can freely browse through your secret documents.
Add .htaccess file into lib/plugins/fckg/fckeditor/userfiles/ folder, containing:
Deny from all
- Mxrgus Pxrt
Actually, this won't work with fckgLite, because the FCKeditor is considered an intruder and is denied access. See Security below. -MT
If you want to use Clean URLs add lines following lines in beginning of lib/plugins/fckg/render.php:
global $conf; $conf['userewrite'] = '0';
Or links are broken.
- Mxrgus Pxrt
First, there is no lib/plugins/fckg/parser.php. Perhaps you mean, render.php. Setting userewrite to 0 will presumably turn nice URLs off, and the reason it doesn't (if you are talking about render.php) is that the resetting of this value comes too late in the loading process to take effect.
Support for nice URLs was added as of Nov 26 2009 and has been regularly enhanced. Download the version from the download button on this page. -MT
If when clicking the media “Browse server” button you get the error “Forbidden.” You don't have permission to access /lib/plugins/fckg/fckeditor/editor/filemanager/browser/default/browser.html on this server.“ then you may have a mod security problem.
If the server is running Apache 1 you may be able to fix it by adding the following to the .htaccess file in your server root.
SecFilterEngine off SecFilterSelective off
For Apache 2 you whitelist the domain for the appropriate rule. You may require your web host to organize this for you.
If the inserted images don't display in the editor until after the page is displayed you may have a permissions problem with the media files. Add a .htaccess file into (webroot)/data/media/ with the lines
order allow,deny allow from all
Please see discussion below for security issues.
Technically, there is a security issue, if you keep sensitive documents in your media directory. Since those will not be images, however, what you can do is to create a folder (or folders) for sensitive documents, place an .htaccess file in these directories which denies direct access to the folders
order allow,deny deny from all
You can then still link to them if you need to, using the link browser's “Non-DokuWiki Internal Files” link type. This works because the documents are fetched internally by a Dokuwiki script and not by means of a URL. If the files have non-standard characters in them, a good practice would be to upload these files to a directory which accepts them and then move them over to the protected folder; this will assure that the files conform to the DokwWiki typographic requirements. -M.T.
Update: Recent versions of the fckgLite filebrowser can move files between folders, more specifically from the current folder to one of its subfolders. This means you can upload a file using the filebrowser and then without closing the filebrowser, move it over to a secure directory. See http://www.mturner.org/fckgLite/doku.php?id=media&#moving_files
This will allow the images to display directly from the editor. [ Are there any security issues with this?]
I'm not quite sure what “This” refers to, but I'll give it a shot. First of all, you are talking about images. So unless you've hidden corporate secrets in your images, why should there be a security risk? Secondly, I don't really know what you mean by 'directly from the editor'. If 'in the editor', i.e. during editing, then the files are protected by ACL and presumably the person editing has access to the material in the folders. Thirdly, if the images display in the editor, and the page is made public, then they will display in the browser and the whole world has access to them by right-clicking and downloading.
This all applies equally to non-image files.
Another secure solution is to protect the media directory in this way:
order allow,deny allow from mysite.com 192.168.1.4
This will give access only to your organization or to a LAN where the web site is on IP 192.168.1.4.
Only works when nice urls (with htaccess) are enabled
I found a solution (which works fine for me) that doesn't require giving up the “deny from all” safety!
You just have to change one line in “*wikidir*/lib/plugins/fckg/fckeditor/editor/filemanager/browser/default/frmresourceslist.html”
LINE 95: (ORIGINAL) "window.top.opener.SetUrl( encodeURI( fileUrl ).replace( '#', '%23' ) ) ;"
LINE 95: (NEW) "window.top.opener.SetUrl( encodeURI( fileUrl ).replace( '#', '%23' ).replace('data/media','_media').replace(/^(.*)\/(.*?)$/, '$1\:$2') ) ;"
After installation of the plugin some internal links like 'wiki:syntax' appeared red and did not work anymore - the editor stripped the 'wiki:'. Even a revert to the previous version will 'pipe' the source through the editor and destroy the link - which renders the plugin a bit useless. Can this behaviour be changed? - Bernd-B
Download the most recent version using the download button at the top of this page. If you continue to have trouble write to the mailing list. -MT
This is not enough to go on. Either write to the mailing list or the forum with more details, like the OS, whether you are using nice urls, and which, what was on the page that got lost. Did you try saving a page with fckgLite and then re-loading it? Did you lose it? If it was saved, was it there after you switched back to the native DW editor?
This doesn't sound like the same problem at all. The previous writer says the links didn't work; there are various configuration issues that could explain that. But you are saying that the editor loses pages when going from the fckgLite editor to the native DW editor. -MT
I have a problem with inserting images. I insert an image and it looks Ok, having the link /dokuwiki/lib/plugins/fckg/fckeditor/userfiles/image/file.jpg. Then once the page is saved, the link becomes /dokuwiki/lib/exe/fetch.php?w=600&h=338&media=file.jpg and the image isn't shown. Dokuwiki version is 2012-01-25a “Angua” (installed from Debian testing repo).
Spiffy plugin, but very buggy. Regularly corrupts my wiki pages even when saving after making zero changes… have to go back and fix everything manually. –Roger
Well, Roger, why don't you report your issues to the mailing list or the forum? This plugin is widely used and when problems occur, they are quickly addressed. What is it that's being corrupted? What versions of Dokuwiki and fckgLite are you using? etc,etc. Maybe you are trying to do things which are outside the scope of fckgLite. Have you checked the fckgLite web site? Have you googled your problem or searched the forum or mailing list?
I used a previous (manually installed) Version of fckg and everything worked well. Now I want to update. I removed the old PlugIn and tried to install the new one like I have done it in the past (copying the fckg directory into the plugins directory of dokuwiki). After that I was not able to connect to Dokuwiki anymore. I just received a blank page. After removing the fckg directory from the plugins folder everything worked well again. Surely I have done something wrong but I cannot figure out what it is. (Apache 2.2, PHP 5, Win2008R1, DW: Angua)
– Regards Jörg
Have your tried again, after removing the fckg directory (removing it entirely)? And have you looked in your apache logs to see whether there was a PHP error? Also delete the cache—all files and directories in data/cache. And clear the cache on your browser. And does it happen in all browsers?
Yes, I removed, and cleared the cache. Both the browser and the wikicache. I also tried several browsers everyone whith the same result. The logs show only this error: ”
xx.xx.xx.xx - - [20/Feb/2012:09:56:01 +0100] “GET /wiki/doku.php HTTP/1.1” 500 -“. Maybe some problems with another plugin? I will check this out in the next days.I suspect that there is a PHP error. Add this near the top of your main.php:
<?php error_reporting(E_ALL); ini_set('display_errors','1'); ?>Sorry, that does not work. The page remains blank. After switching back to the old fckg I was able to see some Messages. They belong to the file renderer.php and complain missing offsets. I do not know if this is of any importance for you?
Specify an error log:ini_set('error_log','/path/to/my_file.log');
Then you can check the log for errors. And you might consider placing the error settings in doku.php. just in case the error is coming before main.php is loaded. And what do you mean by the “old fckg”? What version was the old and what version of fckgLite are you updating to? Get the version from
fckg/VersionThe working version is:
SafeFN-05-11-Jun_30-22_23. Unfortunatly I had no success with the logging-code. Nothing was written to the file. But it looks to me like an individual Problem. I am glad, that you spend so much time trying to help me out, but I will try to reinstall dokuwiki to see if the problem will be solved after that.
Hi, I have been experiencing the exact same issue on two different DokuWikis. After the installation, I got a blank page, and no other page would display. As mentioned in the
auto_install.pdf, there seems to be issues concerning symlinks, whether it's on Windows or Linux.
Passed those issues, two configuration options were added in :
It's that last one option that seems to block DokuWiki if the symlinks are not correct, so I managed to make it go through by setting
no_symlinks to 1, so that the symlink checking doesn't block :
$conf['no_symlinks'] = 1;
I hope it'll help you, this is a temporary solution considering that there are still symlink issues that need to be solved separately. I would suggest discussing the issue in the main page, because when it happened to me, I wasn't able to find this discussion thread in the first place.
2013-07-24 This solution worked for me. Thank you! -grumfellow
The only way to do this would be manually:--- //[[firstname.lastname@example.org|Joe Smith]] 2012/07/13 06:14//