Category: Error

If you're editing a page and you fail the CAPTCHA or your session expires, your whole edit is lost. Most users expect their browser to have saved the form data, many would know enough to log back in then hit the back button to get back to the form (or at least, hit "back" and copy the data for later pasting after login). This does not work - after a "back" the form is empty!

I'm ranking this bug as priority 7 because it is very serious - data loss and angry users. I think the solution is trivial, too: see below.

The "Directory Batch Upload" page states "Please do not use this feature to upload data into the database." The page is stating that it should not be used, thus rendering it unusable. Clarification is needed.

Tiki is using cn & tw, and cause a problem -- the CKEditor hang at 'Loading...' screen. I followed the suggestion from Nelson Ko and cloned three language support files (zh-cn.js => cn.js), then the CKEditor worked.

The language code of Simplified Chinese shall be zh-cn, and Tradition Chinese shall be zh-tw, which two are more popular. I would suggest changing them to avoid any further problem.

I have two current Tiki master instances on my localhost and in both, when I try to activate the module "Last actions", I get a system error:

"You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near 'order by `lastModif` desc LIMIT 10 OFFSET 0' at line 1

The query was:
select a.* from `tiki_actionlog` a join `tiki_actionlog_conf` c on a.`action` = c.`action` and a.`objectType` = c.`objectType` and (c.`status` = 'v') where order by `lastModif` desc

The built query was likely:
select a.* from `tiki_actionlog` a join `tiki_actionlog_conf` c on a.`action` = c.`action` and a.`objectType` = c.`objectType` and (c.`status` = 'v') where order by `lastModif` desc"

Jonny said in the Matrix chat that the query is missing the -+where+- clause.

In the RSS feed for articles, tha last person to edit the article is proclaimed as the author of said article.

The problem is when you create a tracker and you allow Rating on it.
Then you can add new items, but when you try to edit an existing item, the last field of the tracker is never saved.

this line is commented (line 152 of tiki-view_tracker_item.php)

{CODE()}
if ($xfields["data"][$i]['type'] == 's') {
//$ins_fields["data"][$i] = $xfields["data"][$i];
$fields["data"][$i] = $xfields["data"][$i];
}
{CODE}

so ))$ins_fields[0](( becomes an empty index in this array because the field 'Rating' is of type 's' (system).

Later in the function 'replace_tracker(...)' of trackerlib, ins_fields are parsed inside a loop from 0 to size of ins_fields - 1, so the last item is never seen.

I don't know exactly with somebody commented the line, but it works for me if I uncomment it.

[https://tiki.org/Community] user info popups show "Last Login" as "Never logged in" but on the user info page such as [https://tiki.org/user1553] it shows fine.

It's also not a problem on dev so i suspect an intertiki thing...

The tooltip info for site users such as page or post authors incorrectly reports the "last login" information as "never logged in". We can see this now at the Tiki project sites, and I'm seeing it at a Tiki 14 site also.

Apart from not being factually accurate, it probably doesn't make a good impression for the software to indicate that content is being authored by people who've never logged in.

{syntax type="tiki" editor="plain"}
Upgraded from 2.3 to 3.0

When assigning an module with LAST_ARTICLES on right column.

LAST ARTICLES only displays Articles that have NO Topic.

If I take an article and assign a topic to it, it will not show up anymore in LAST ARTICLES.

When I remove the Topic for that article, it will re-appear in LAST_ARTICLES.

last_insert_id() is used in SQL in a couple of places in TikiWIki. This is a mysql-specific function that breaks functionality when other databases are used.

For TikiWiki CVS HEAD (1.10):

lib/articles/artlib.php:152: $query = "select `subId` from `tiki_submissions` where `subId`=last_insert_id()";

lib/multilingual/multilinguallib.php:28: $query = "insert into `tiki_translated_objects` (`type`,`objId`,`traId`,`lang`) values (?,?,last_insert_id(),?)";

Also present in TikiWiki 1.9.x

Reported by Thrain - thanks.

If module last_tracker_comments is assigned to a lateral column, this fatal error message is shown when attempting to view Admin > Trackers (tiki-admin.php?page=trackers):

{CODE()}
Fatal error: Cannot redeclare class trackerlib in /home/httpd/tiki19/lib/trackers/trackerlib.php on line 11
{CODE}

BTW: Moreover, tiki-admin_trackers.php yields a 100% blank page, with no error message.

Using 1.9.cvs from yesterday.
-------------------
fixed in 1.9 cvs tiki-admin_include_trackers.php revision: 1.9.2.10;

Last modified or added item should be at number 1.

__This module requires parameters trackerId and name set__ appears in "Last visitors" and "Messages" if last_tracker_items modules is activated, when params are not set.

There is no tracker data in my test.

Fatal error when trying to authenticate against an LDAP server on IIS6 Windowns 2003 Server:

Fatal error: Call to undefined method Net_LDAP2_Error::getEntry() in D:\WWWROOT\wiki60\lib\auth\ldap.php on line 257

Hello all.

Almost by chance I noticed a behavior which seems wrong regarding the LDAP authentication on TikiWiki 2.0. I'm not sure if it was already present in 1.9.11 but I don't think so. We migrated last week.

Regarding the TW configuration:

- authentication method is "Tiki+PEAR::Auth"
- users cannot register and cannot change password
- "Create user if not in Tiki?" is on
- "Create user if not in Auth?" is off
- "Just use Tiki auth for admin?" is on
- The LDAP auth configuration paramters are correct, the auth itself works well, as it worked in 1.9.11. When TW connects to the LDAP server (OpenLDAP 2.1.30) the authentication works as expected.

This means that a Tiki account is created when LDAP users login for the first time. As expected, in presence of such a user, TW connects to LDAP, authenticates, creates Tiki account and logs the user in (I have some doubts in this last item though). However, when users log in again after this, I would expect that authentication is still delegated completely to the LDAP and is not done through Tiki. Instead, I have confirmed by looking at my LDAP logs that when TW finds a Tiki account, it authenticates the user through Tiki and never connects to the LDAP. This is not the expected behavior, because it means that passwords are being stored on the TW database and actually used for authentication. As a consequence, when a user changes his password on the LDAP, this is not "seen" by TW.

I'm pretty sure this is not the intended behavior also because if I go to Admin Users, both the "edit user" and the "add user" boxes show the following:

"No password is required
Tikiwiki is configured to delegate the password managment to LDAP through PEAR Auth."

And actually, the "edit user" box also says "Warning: changing the username will require the user to change his password" which is a contradiction since the password should be managed by LDAP and my TW is configured to disallow users from being able to change their passwords.

Paulo

LDAPv2 is obsolete, and the use of LDAPv3 is now standard practice. In fact, the [http://www.openldap.org/faq/data/cache/822.html|latest releases of OpenLDAP don't even support LDAPv2 properly anymore]. However, PHP's ldap_connect() and PEAR::Auth [http://www.openldap.org/lists/openldap-software/200204/msg00046.html|default to LDAPv2].

The patch to use LDAPv3 is attached. It shouldn't be difficult to make the LDAP protocol version a configurable preference.

With the switch from Pear Net_LDAP2 to Zend\Ldap, the LDAP authentication to the AD is broken in Tiki 19.1.
With exactly the same configuration as with Tiki 18.3, I get this error message in the Action Log:
{CODE(theme="default")}Error: 0x31 (Invalid credentials; 80090308: LdapErr: DSID-0C090400, comment: AcceptSecurityContext error, data 52e, v1db1): sAMAccountName=wiebe.oudshoorn,cn=users,dc=moba-bv,dc=local at line 262 in D{CODE}

I have done some research with WireShark to inspect the packages from and to the LDAP server, when someone logs in to the wiki:

Tiki 18.3:{img fileId="1287" thumb="box"}

Tiki 19.1:{img fileId="1288" thumb="box"}

It's very clear where this is going wrong. It's trying to do a bind request with only the username instead of username@domain.url (row 355 in 18.3 screenshot vs row 239 in 19.1 screenshot ).
Although LDAP bind type is set to 'AD', so according to lib\auth\ldap.php row 184 it should add the correct information to the bind request instead of performing a 'plain' bind.


My LDAP settings:
{img fileId="1289" thumb="box"}

Not detailed here as per security protocol.

Hi All,

I’m working on the Tikiwiki 2.2 with a LDAP authentication.

In the login option, I see it is possible to automatically give someone access in the Tiki if this person is in LDAP directory.

My question is: Is it possible to define access with a Distribution List group and not with the entire LDAP directory?

On another note, do you know why “LDAP Member is DN” can not be set to “yes?”

Thanks for your response

System environment:
Tiki 6
Windows Server 2008 64bit
Apache x64 2.2.11
PHP x64 5.2.5 (lib/smarty/libs/internals/core.is_secure.php patched to make it work)

LDAP authentication against AD does work once configured properly
BUT
Debugging the configuration was hard because turning on logging caused errors!
When logging is off, all is well. When logging is on and line 346 of lib/auth/ldap.php is commented out, all is well.
It seems that when logging is active, "$filter->asString()" on that line causes an error on our system. The same call is made on line 262 with a simpler filter and works OK.

Perhaps when checking groups, asString is returning too much for the logging system to handle?

There was an issue with the LDAP not syncing groups properly, and would thus cause a blank page to appear when logging into my site.

Essentially, the entire problem is attributed to a typo in the function name for the ldap_sync_groups function. The file ~/lib/userslib.php contains the function:

{CODE()} private function _ldap_sync_groups($user, $pass)
{...}{CODE}
The major problem is that this function name has a leading underscore (_) and causes an issue when it attempts to sync the groups with the LDAP.

Simply removing the underscore solves the whole problem. The function should be named as such:

{CODE()} private function ldap_sync_groups($user, $pass)
{...}{CODE}
This will make it so that when the file reaches the line:

{CODE()}$ret &= $this->ldap_sync_groups($user, $pass);{CODE}
It can successfully sync with the LDAP.

Hi,

We've been using the LDAP to authenticate our users ever since we created our site a couple years ago. We've run into a few road bumps along they way, but this time I can't seem to figure out the issue that is occurring with the LDAP. The main issue that I am seeing here is that the LDAP doesn't appear to be syncing with our groups.

If I attempt a log in on my normal admin account, it appears to allow me to log in as if it's recognizing that I am a user, but while it logs me in, the groups aren't being synced. This results in an error that says "You do not have permission to view this page." So I logout of that account and log back in with the default admin account (which seems to be the only account still working without the LDAP group sync). When I check the Users list, I can see that even my normal admin account has been completely removed from the groups I previously belonged to before my login attempt.

Therefore, this leads me to believe that the issue is with the ldap_sync_group functions somewhere inside the lib/userslib.php file. I've tried a couple of workarounds, but to no avail. Has anyone experience anything like this?

Please help, as this is completely breaking my Tiki installation!

Hello, I have serious problems upgrading to version 15.4.

I am using LDAP connection for authentication - everything works fine in 15.2 and 15.3, but since 15.4 I get a 500er Server Error after logging in with an LDAP account - admin login works fine.

I found the place in the code where the error is:

tiki_login.php :
} else
{
// Verify user is valid $ret = $userlib->validate_user($requestedUser, $pass, $challenge, $response);
if (count($ret) == 3) {
$ret[] = null;
}

The $userlib->validate_user($requestedUser, $pass, $challenge, $response); does not work here.....

Any ideas? It is not possible to use Tiki anymore without this error being fixed...

Thanks a lot
Greetings
Kai Mengel

The LDAP syncing is the major problem here. I have tiki 12.2 installed, and everything works fine with the system. But when I attempt the upgrade to 12.3 on my development site, run the composer and installer, and upgrade the database, the LDAP seems to break and I cannot log in to the site using any account at all -- not even the default admin account. When I get to the login screen after finishing the installer process, I enter my username and password and it returns with the error "Invalid Username or Password." Again, the same thing happens with the default admin.

I submitted a post on the forum asking if anyone else had the same problem and I had a response where someone was indeed experiencing this as well. He offered a solution where I go into the file ~/lib/auth/ldap.php and comment out an error checking routine on lines 235-240, and this actually allowed me to login to the upgraded version. However, when I did this, it essentially broke the login authentication system, and you could log in as any user no matter what password credentials were entered. So, while this temporary solution did allow me to login to the site, it did not work as anticipated, as I believe it broke the TLS and/or LDAP authentication itself.

Legacy mod theme Akwa causes blank screen on 2.0.