Not logged in. · Lost password · Register
Page:  1  2  next 

All posts by sTeamTraen (20)

topic: Can't see Register button (using authPDO)  in the forum: General Help and Support Installation and Configuration
Avatar
sTeamTraen #1
Member since Sep 2009 · 20 posts
Group memberships: Members
Show profile · Link to this post
Yay, that worked! Hopefully I can now forget all about DokuWiki configuration for another few years. :D
topic: Can't see Register button (using authPDO)  in the forum: General Help and Support Installation and Configuration
Avatar
sTeamTraen #2
Member since Sep 2009 · 20 posts
Group memberships: Members
Show profile · Link to this post
Subject: Can't see Register button (using authPDO)
I have set up authPDO authentication and can log in with an existing account. However, the "Register" link is not available, only "Log In".

I tried to simulate the effect of this button with the URL "doku.php?id=start&do=register". The error message is "Action disabled: register".

Some searching suggests that this message appears when the configuration explicitly excludes registration via "disableactions". However, this field is completely empty (i.e., nothing is disabled).

I'm guessing that the problem could be due to my authPDO configuration not containing a particular SQL string that would be necessary to add new users, but I'm not sure what that might be. Can someone confirm if this is a plausible explanation? Perhaps the code checks that a certain number of config elements are defined before it allows the Register link to be displayed. In that case I would maybe try to read the code to establish what that list of elements is. (This migration from authMySQL to authPDO is a bit of a pain...)

Thanks for any ideas!
Nick
topic: Looking for authPDO usage example  in the forum: General Help and Support Installation and Configuration
Avatar
sTeamTraen #3
Member since Sep 2009 · 20 posts
Group memberships: Members
Show profile · Link to this post
In reply to post ID 63406
Thanks! That seems to be working. (Your untested code for the groups worked once I put `` characters around the word "group", which was otherwise being treated as a keyword.)
topic: Looking for authPDO usage example  in the forum: General Help and Support Installation and Configuration
Avatar
sTeamTraen #4
Member since Sep 2009 · 20 posts
Group memberships: Members
Show profile · Link to this post
Subject: Looking for authPDO usage example
I am moving from PHP 5.6 to PHP 7.2 and apparently I can't use authmysql any more. I have been told that authPDO is the best way to connect to my (MySQL) user authentication database. However, I'm having trouble finding what to do.

At the moment, everything I need is in a few lines in local.php:

$conf['plugin']['authmysql']['server'] = '10.x.x.x';
$conf['plugin']['authmysql']['user'] = 'DWUsers';
$conf['plugin']['authmysql']['password'] = 'xxxxxxxx';
$conf['plugin']['authmysql']['database'] = 'DWUsers';

All I want to do is to have this authentication continue to work. But I don't understand the documentation that I have seen for authPDO (e.g., https://www.dokuwiki.org/plugin:authpdo). It talks about writing SQL statements (which I know how to do), but not where to put them, or whether I have to include them directly in an SQL file or call them from PHP, etc etc.

Does someone perhaps have a working example of a simple authPDO configuration so that I know what files to edit and what syntax to use in there? Or experience of migrating from authpysql to authPDO?

Thanks...

Nick
topic: [Solved] Error "No ACL setup yet! Denying access to everyone" on PHP 7.x (OK on 5.6)  in the forum: General Help and Support Installation and Configuration
Avatar
sTeamTraen #5
Member since Sep 2009 · 20 posts
Group memberships: Members
Show profile · Link to this post
In reply to post ID 63378
Ah! Maybe I need to look at mysqli. Thanks!
topic: [Solved] Error "No ACL setup yet! Denying access to everyone" on PHP 7.x (OK on 5.6)  in the forum: General Help and Support Installation and Configuration
Avatar
sTeamTraen #6
Member since Sep 2009 · 20 posts
Group memberships: Members
Show profile · Link to this post
Subject: [Solved] Error "No ACL setup yet! Denying access to everyone" on PHP 7.x (OK on 5.6)
I'm running 2018-04-22a "Greebo", which I upgraded to because I had this bug with an older version, but it continues.

The issue is pretty straightforward. When my PHP version is set to 5.6 my wiki works. With PHP 7.0, 7.1, or 7.2, I get these error messages (even if I'm not trying to log in -- just at the start of doku.php):

Pink background: "User authentication is temporarily unavailable. If this situation persists, please inform your Wiki Admin."
Mauve background: "No ACL setup yet! Denying access to everyone."

White background:
 Permission Denied
 Sorry, you don't have enough rights to continue.

 You are currently not logged in! Enter your authentication credentials below to log in. You need to have cookies enabled to log in.

I have searched for previous occurrences of this issue, but they all seem to involve acl.auth.php. I presume that if that was the problem, my Wiki wouldn't work with PHP 5.6 either. Indeed, I can provoke a similar set of messages by commenting out the "* @ALL 1" line from acl.auth.php, except that I don't see the pink-background message saying "User authentication is temporarily unavailable. If this situation persists, please inform your Wiki Admin."

I have this in my local.php file:
  $conf['authtype'] = 'authmysql';
So I presume the problem is that something about the MySQL setup that I have doesn't like PHP 7.x.  Again, flipping back to PHP 5.6 fixes the problem instantly.

Any help would be appreciated.

Nick
This post was edited on 2018-10-27, 18:12 by sTeamTraen.
topic: [Solved] Can't get 2018-04-22a "Greebo" to work: Server error 500  in the forum: General Help and Support Installation and Configuration
Avatar
sTeamTraen #7
Member since Sep 2009 · 20 posts
Group memberships: Members
Show profile · Link to this post
In reply to post ID 63363
Thanks! Using the dokuwiki-downloader approach worked. In fact it failed at Step 1 because it wasn't able to download the .tgz file, but I had that on my PC so I was able to upload it and continue with Step 2.

I will look at the difference between the two setups to see what might be different.

Now I have another problem, but I will post that in a different thread if I can't find the solution.
topic: [Solved] Can't get 2018-04-22a "Greebo" to work: Server error 500  in the forum: General Help and Support Installation and Configuration
Avatar
sTeamTraen #8
Member since Sep 2009 · 20 posts
Group memberships: Members
Show profile · Link to this post
Subject: [Solved] Can't get 2018-04-22a "Greebo" to work: Server error 500
I am currently running an old (V46) version of DokuWiki, which works fine with PHP 5.6, but now my hosting company wants to move to PHP 7.0, which doesn't work with that version. So I downloaded the latest stable version, 2018-04-22a "Greebo". It's several years since I installed the previous version of DokuWiki, and I have to re-learn everything from scratch every time I upgrade it, but up to now each upgrade has worked.

Note that my web server is run by a hosting company, so as far as I know I don't have any way to install modules or configure any kind of server parameters apart from through config files. For example, I can set the PHP version to 5.6 or 7.0 with a magic file.

Because I'm an old and very conservative sysadmin, I decided to make a completely new Wiki with this new software version before I upgrade the Wiki that's in place. But it doesn't work. I unpack the files and copy them to a new folder on my server (/wikinew), but when I attempt to run anything (index.php, doku.php, or install.php), I get a blank screen on Firefox, or "HTTP error 500" on Chrome. This is whether I set the PHP version to 5.6 or 7.0.

This is with the default .htaccess file (indeed, the default everything). I also tried deleting that file completely, with no luck. I imagine that I need to set some very basic parameter, but I was hoping to at least be able to run install.php.

Thanks for any ideas...

Nick
This post was edited on 2018-10-27, 18:12 by sTeamTraen.
topic: Lost mysqlauth superuser password  in the forum: General Help and Support Plugins
Avatar
sTeamTraen #9
Member since Sep 2009 · 20 posts
Group memberships: Members
Show profile · Link to this post
Subject: Lost mysqlauth superuser password
Never mind, fixed it!
This post was edited on 2015-02-08, 01:18 by sTeamTraen.
topic: Configuration Manager generates unusable local.php file  in the forum: General Help and Support Installation and Configuration
Avatar
sTeamTraen #10
Member since Sep 2009 · 20 posts
Group memberships: Members
Show profile · Link to this post
In reply to post ID 38806
Quote by ach on 2013-05-27, 21:52:
You have mysql.conf.php, right? And that line is really not in there?
I just looked - yes, that line is in there.  So I can see why replacing it with an empty array would trash things.

Good luck to all the developers and documentation writers with fixing the various issues. :)
topic: Configuration Manager generates unusable local.php file  in the forum: General Help and Support Installation and Configuration
Avatar
sTeamTraen #11
Member since Sep 2009 · 20 posts
Group memberships: Members
Show profile · Link to this post
In reply to post ID 38801
Quote by ach:
Quote by sTeamTraen on 2013-05-26, 13:34:
1. This
$conf['authtype'] = 'authmysql';
require_once ('mysql.conf.php');
had become (approximately, I didn't keep a copy, but basically, an extra level of quotes got added to everything)
$conf['authtype'] = '\'authmysql\'; require_once (\'mysql.conf.php\');'
which totally trashed MySQL authentication

Then you didn't follow the instructions properly. See how to configure authmysql plugin
That's probably because I wasn't even aware that I was configuring a plugin.  As I noted elsewhere, I was surprised to note that for such a major set of changes, there wasn't a section entitled "Stuff to read first, even if you have done several previous upgrades, because we've changed some really important things" in a very prominent place close to the download link.

Quote by ach:
Quote by sTeamTraen on 2013-05-26, 13:34:
3. This line
$conf['plugin']['authmysql']['TablesToLock'] = array();
had been added

I can confirm that that line gets automatically added whenever something is saved via the configuration manager. I filed a bug report here: https://bugs.dokuwiki.org/index.php?do=details&task_id…
In your case I can imagine that whatever you had in $conf['auth']['mysql']['TablesToLock'] got overwritten, which is causing the issue. Just copy that to the new config option.
I didn't have anything in $conf['auth']['mysql']['TablesToLock'].  This line is completely new.  (After all, I hadn't been using, or even aware of the existence of, the authmysql plugin until I upgraded.)
topic: Configuration Manager generates unusable local.php file  in the forum: General Help and Support Installation and Configuration
Avatar
sTeamTraen #12
Member since Sep 2009 · 20 posts
Group memberships: Members
Show profile · Link to this post
Subject: Configuration Manager generates unusable local.php file
I just configured a plugin (captcha) using Configuration Manager.  Everything broke. :(

In local.php, I found the following:

1. This
$conf['authtype'] = 'authmysql';
require_once ('mysql.conf.php');
had become (approximately, I didn't keep a copy, but basically, an extra level of quotes got added to everything)
$conf['authtype'] = '\'authmysql\'; require_once (\'mysql.conf.php\');'
which totally trashed MySQL authentication

2. Similarly, this
$conf['mailfrom'] = $conf['title'] . admin . ' <do-not-reply@earwigo.net>';
had become (approximately)
$conf['mailfrom'] = '$conf[\'title\'] . admin . \' <do-not-reply@earwigo.net>\';'
which meant that mails seem to come from "$conf"

3. This line
$conf['plugin']['authmysql']['TablesToLock'] = array();
had been added, which meant that the front page of the Wiki displays this pink message:
Command disabled: register
and new users don't get a "Register" link.

Now maybe all of these are being caused by something strange in my hosting company's PHP setup to do with escaping quotes or some other general PHP BS, but in any case it seems that the code should be able to detect and handle those situations.  I'm happy to do further testing if required to help fix this problem, which it seems to me would be likely to cause some Wiki owners to run screaming from the room.
topic: Overwhelmed occasional user  in the forum: General Help and Support Installation and Configuration
Avatar
sTeamTraen #13
Member since Sep 2009 · 20 posts
Group memberships: Members
Show profile · Link to this post
In reply to post ID 38771
Quote by turnermm:
I am not familiar with mysql logins but you need the quotation marks:
$conf['authconfig'] = 'authmysql';
I tried that too (despite it not being what was written in the very explicit pink message).  Didn't help.

Then I found =authconfig#authentication_backends_plugins]this gem:
btw: authconfig in the message is a spelling mistake, it should be authtype

A-ha!  So I now have this in local.php:
$conf['authtype']   = authmysql;

And it seems to work.  At least, I don't have the pink message any more.  But maybe there are two typos in the message, and I do need the quotes.  However, normally I try to follow instructions to the letter.  (After some testing, it seems that whether I use the quotes or not, it still works.  Maybe my hosting company's PHP setup is running with some tolerant settings that turns unquoted sequences of characters into strings.)

I normally try to avoid criticising free, open-source software, but I must say I was disappointed to find that a large warning message contains a substantial typo in the instructions that it gives to fix the issue.  Also, given the substantial nature of the changes to authentication, I would have expected a "!!!! STUFF HAS CHANGED WITH THIS RELEASE, YOU NEED TO CHANGE SOME OF YOUR STUFF TOO !!!!" note to have been added to the standard upgrade instructions.
topic: Overwhelmed occasional user  in the forum: General Help and Support Installation and Configuration
Avatar
sTeamTraen #14
Member since Sep 2009 · 20 posts
Group memberships: Members
Show profile · Link to this post
Subject: Overwhelmed occasional user
I just want a set-and-forget Wiki, but every time I upgrade Dokuwiki it seems something breaks.

My current issue is this message, on a pink background:
Your authtype setting is deprecated. You must set $conf['authconfig'] = authmysql in your config

So I replaced
$conf['authtype']   = 'mysql';
with
$conf['authconfig'] = authmysql;
and then nobody could log in.

So then I put
$conf['authtype']   = 'mysql';
back, leaving
$conf['authconfig'] = authmysql;
as well, but I still get the pink message.

Here is the totality of my local.conf file:
$conf['title'] = 'My Wiki';
$conf['lang'] = 'en';
$conf['useacl'] = 1;
$conf['superuser'] = '@admin';

$conf['mailfrom'] = $conf['title'] . ' admin' . ' <do-not-reply@mydomain.net>';

$conf['authtype']   = 'mysql';
$conf['authconfig'] = authmysql;

require_once ('mysql.conf.php');

In words of one syllable, what else do I need to know?  Have I suddenly started "using a plugin" without knowing it?  Do I need to define "authmysql", which looks like some kind of PHP constant?

I thought maybe I could do whatever it is that I need to do via "Admin"/"Configuration settings"/"Plugin settings"/"Authmysql Plugin Settings", but I'm slightly surprised to see that all the fields there are blank. I'd expect them to be filled in with the values from mysql.conf.php, which defines a valid database server, username, password, DB name, assorted SQL strings, etc.  Is there meant to be some relationship between mysql.conf.php and the plugin settings manager?  Or do I need a plugin to manage the plugins?  Did I miss something in the upgrade from v38 to v40?  Maybe I'm running on deprecated "non-plugin" authentication code, etc etc.

Thanks for helping a confused newbie...

PS: I have 38 years of programming experience, but having to learn 100,000 pages of documentation for a new system is getting rather tedious. :)
topic: Help! I locked myself out!  in the forum: General Help and Support Installation and Configuration
Avatar
sTeamTraen #15
Member since Sep 2009 · 20 posts
Group memberships: Members
Show profile · Link to this post
In reply to post ID 38754
Sorry for the incoherence in my previous posts.  I was panicking!
Quote by ach:
My advice: Install the captcha plugin.
Oooh, that looks interesting.  Thanks.

Quote by ach:
Quote by sTeamTraen:
(Apparently, adding the line "" breaks something in version 38. [...])
Which line, where? Sorry, I don't understand what you mean.
Doh!  In my panic, I submitted that post before I remembered to copy/paste the line from the file.  The line causing problems is:
  $conf['disableactions'] = 'register';
That gets added when I check the box to prevent people from registering themselves.

Quote by ach:
Quote by sTeamTraen:
Quote by sTeamTraen:
A question then arises: do all users have to be in the "user" group in order to be able to log in?
Yes, it seems they do. :)

The don't. I have no clue why this behaves like it does in your case, but the admin most definitely does not need to be in the user group.
The one thing you forgot to mention in all your posts: Which *authentication* system do you use? It cannot be the default one, because you mentioned you fixed your login issue by changing something in an SQL database...
Sorry: $conf['authtype']   = 'mysql';
The instant I remove the admin account from the user group, it collapses.  I can do this in real time with phpMyAdmin open in another tab.  Delete the user-group record for the admin account in "user", it breaks.  Re-insert, it works.  Again, this is with version 38.  I'm doing a backup of the Wiki prior to installing version 40, but that's taking ages because my FTP client is choking on some of the huge filenames generated by the spam articles.  (I need to back up everything including the spam, because there is so much spam I will have to do some bulk deletes and may hit a bit of genuine data.)

(Edit by ach: fixed quote formatting)
This post was edited on 2013-05-27, 16:41 by ach.
Close Smaller – Larger + Reply to this post:
Special characters:
Page:  1  2  next 
Special queries
Go to forum
Imprint
This board is powered by the Unclassified NewsBoard software, 20150713-dev, © 2003-2015 by Yves Goergen
Current time: 2019-07-23, 00:52:48 (UTC +02:00)