Category: User Administration (Registration, Login & Banning)

__DESCRIPTION__: We have deployed a platform with CAS JASIG, TIKIWIKI and JOOMLA. We have an issue with users that are already logged in JOOMLA and try to access TIKI.

__ISSUE__: CAS Autologin feature fails to complete.
_SINCE WHEN_: This issue has been at least since version 14.x
_PROCEDURE THAT FAILS_: If i try to access a restricted resource without explicitly login before.
1. Tiki redirects to CAS SERVER __(NORMAL CASE)__
2. CAS SERVER redirects back to Tiki __(NORMAL CASE)__
3. Tiki redirects back to TIKI main page __(NOT NORMAL)__

_NOTE_: The Autologin functions well only when we explicitly access _tiki-login.php_

By clicking on the column header in the list of users in order to change the order of listing, the page is blank (just a little square appears in the upper right)

Right now, there's no way to resend either the email to the admin to validate a user or resend the email to the user to validate their email address. If either of those emails fail to happen or they get sent to "spam", the user cannot log in.

If you go to "tiki-adminusers.php" and using the action menu {icon name="wrench"} try to assign a user to a group you will have the following error:

Error
Cannot add user xxxx@tiki.org to nonexistent group
This message will move to the top of the page after a few seconds.

If you do it from the the user record "tiki-adminusers.php?offset=0&numrows=25&sort_mode=login_asc&user=34" and use the button "Assign user to group" it will work.

{img fileId="1542" thumb="box"}{img fileId="1543" thumb="box"}{img fileId="1544" thumb="box"}

Since wiki page names should avoid special characters, we'll need to think about maybe using character substitutions in page names (a instead of à, _ instead of ') and use the description field for the exact format.

Please coordinate here: ((Character substitutions))

This should be migrated to the community site, and handled with ((doc:Organic groups)) and ((doc:User Trackers))

I am not able to get a tracker to collect registration data.

I have followed the steps here: https://doc.tiki.org/User-Tracker

I get these errors upon registering an account:

NOTICE (E_NOTICE): Undefined variable: registrationTrackerId
At line 1205 in lib/wiki-plugins/wikiplugin_tracker.php
NOTICE (E_NOTICE): Undefined variable: itemId
At line 1207 in lib/wiki-plugins/wikiplugin_tracker.php
NOTICE (E_NOTICE): Undefined variable: newItemRate
At line 1208 in lib/wiki-plugins/wikiplugin_tracker.php
NOTICE (E_NOTICE): Undefined variable: fieldsfill
At line 1210 in lib/wiki-plugins/wikiplugin_tracker.php
NOTICE (E_NOTICE): Undefined variable: fieldsfillseparator
At line 1210 in lib/wiki-plugins/wikiplugin_tracker.php
NOTICE (E_NOTICE): Undefined variable: fill_line_cant
At line 1210 in lib/wiki-plugins/wikiplugin_tracker.php
NOTICE (E_NOTICE): Undefined variable: fill_flds
At line 1211 in lib/wiki-plugins/wikiplugin_tracker.php
NOTICE (E_NOTICE): Undefined variable: fill_flds_defaults
At line 1211 in lib/wiki-plugins/wikiplugin_tracker.php
ERROR (E_WARNING): array_filter() expects parameter 1 to be array, boolean given
At line 157 in lib/core/Tracker/Field/Location.php

When I'm viewing the tracker on the "List Tracker" page, the item count is shown correctly, but when I click on the tracker to view the information collected, it shows zero results.

The user page where the tracker information collected is also throwing php errors.

Since this is vast project, we'll use a wiki page: ((CRM))

{syntax type="tiki" editor="plain"}
The registration email seems to give boxed char when mail templates are in french.

I had to add utf8_encode()
to LINE 2727 of lib/userslib.php
$mail_data = utf8_encode($smarty->fetch("mail/$mailTemplate.tpl"));
in order to correct the text display problem.


But when I debug with
$mail_data = mb_detect_encoding($smarty->fetch("mail/$mailTemplate.tpl"));

It return the tpl as already in UTF-8, but I had to utf-8 it again to correct it, can someone look into this?

This is a problem if you don't want Registered users to have this permission. (Often, we want Registered to have all the permissions of anonymous)

in tiki-admin.php?page=features
There is "Contact us" and "Contact Us (Anonymous)"

in tiki-admin.php?page=general, we have more related options
"Contact user:"
"Allow anonymous users to "Contact Us":"


All these options should be on Contact Us admin page (to be created)

Upgrade from 18.1 to 18.3, no configuration changes.

Each save in the control panels and when login/logout ends up with a page full of error messages. When pressing back, changes are nonetheless saved, but something like login out is not possible.
Please have a look at this full MySQL error log, from just one login action: https://drive.google.com/file/d/1eKmRTE_l9S90fGuONyWst0Xz7wgFwBmI/view?usp=sharing
This is already 80mb large, can you imagine each save action... quite interesting what is happening there. Hopefully someone has a clue?

{syntax type="tiki" editor="plain"}
1) Column colapsing is not remerbered whenever I change from one page to another.

2) And also have had some problems with their navigators saying "cookies must be on" when they are on, no matter wich browser is being used. This happends as they attemp to login. After many tries the user can login.


Using:
Tiki 6.1 fresh code install, on past 6.0 db updated to 6.1.

Removing an avatar results in an broken image link.

Reproduce:
* Hovering the mouse pointer on a user name reveals the user details.
* Create an avatar for that user.
* Hovering the mouse pointer on the user name now shows the user details including avatar.
* Delete the avatar.
* In place where the avatar was showing before, there's now a broken image in the user details.

Tiki site: http://list.vic-fontaine.com/
demo user/ password: smarty

Try creating a new user in tiki-admin_users.php.

Whether the password don't match or not you are asked to confirm the action. Is this really needed? Anyway if the passwords don't match you get an error after confirming the action and then the "Go Back" does not work... it is very troublesome.

Hi,

I'm filing this as 'Bug - Consistency' because the error message does not always display.

Two scenarios - when a new user is added:

1) ... than you immediately assign them to a group, this message is displayed. However, the user is assigned to the group correctly, so to resolve this problem the only thing that needs to be done is for the Error Message not be displayed.

{img fileId="1463" thumb="box"}

2) ... than the Admin User page is refreshed, no error message is displayed when assigning this new user to a group.

One other piece of information - since the new 'enter password' (e.g. Admin Password) for adding / editing users was added, a Firefox pop-up asking to 'Reconfirm submission' is regularly displayed:

{img fileId="1464" thumb="box"}

Maybe this is interfering?

Thanks,
Mike

{syntax type="tiki" editor="plain"}
When trying to log in using the top bar "Log in" module user gets CSRF error and is not logged in. Reproducible on tiki.org and dev.tiki.org. Not reproduced on doc.tiki.org. I feel it has something to do with the buggy cookie consent feature.

It does not happen when loggin in using the dev.tiki.org/login URL directly (instead of the top bar module).

You need to open new incognito window in Chrome/Firefox to "start fresh" and reproduce the issue.

Steps to reproduce in the attached screencast video.

https://dev.tiki.org/tiki-download_item_attachment.php?attId=514&display

A CSRF never ending loop happened to me earlier today, on dev.t.o.
I had logged in chromium-browser to dev.t.o as user "xavi" (no admin perms).

I needed to log in with my other user "xavidp" (the one with admin perms), so that I opened a private browsing window of chromium-browser. I went to visit the same page I had visited with the standard user where I had to fix some perms of that wiki page ( https://dev.tiki.org/Wish%20Report%20Tpl ). Clicked at "login" link at the top bar, which sent me to https://dev.tiki.org/login , provided the credentials, and then I got the message about CSRF at the url https://dev.tiki.org/tiki-login.php :
{QUOTE()}Error
Potential cross-site request forgery (CSRF) detected. Operation blocked. Reloading the page may help.
{QUOTE}

Every time I tried (F5, visiting somewhere else within dev.t.o) and attempting to log in, I got the same CSRF error message reproduced, and I couldn't log in as user "xavidp".

I had to open a new browser (Firefox, in this case), and login as "xavidp" was successful.

I wonder what was happening.

I tried again, at the time of reporting this issue, and I got the issue reproduced again.

FYI: I had seen other weird CSRF false positives in other contexts in a 20.x tiki I use at work (behind a firewall). I 'll keep an eye open to add more details when I hit this bug again in other use cases. But there is something wrong still in the code in 20.x.

Users should be able to add their own data in custom fields in tiki-user_preferences.php

Users could publish their phone number, their ICQ address, etc

Date validation (at Registration) is not validation the date field correctly. Validation only accept if day of the date is under 12. It seems it understand the number as as months not days. And it is not themonth field, since the month field popup menu is just next to the date field.

I checked all the date formats and reseted it to the Tiki default and the error still persists.

Sometimes, users forget their usernames and end up creating duplicate accounts.

Here are two things which would help:
1- Users should be able to have a password reset/reminder while only knowing their email. __fixed in 1.10__

2- In tiki-adminusers.php, the search box should work for emails also (not just usernames) __fixed in 1.10__


Related: [tiki-view_tracker_item.php?itemId=1069]
Also, in 1.9.x, usernames are CaSe SenSitive. __fixed in 1.10__

TikiWiki often has drop-down menus with many choices.

Ex.: drop-down list of users, or wiki pages, etc

That is ok for a few hundred. But what if you have 300 000 users or 300 000 wiki pages?

There should be a setting where beyond a certain number, the drop-down become a search box.

On a Tiki22 I user tracker information.
By default user will be member of the registration group.

{img fileId="1539" thumb="box"}

In the tracker I set a usergroup tracker.
New registered users show a blank value for the usergroup instead of the "default" registered.

{img fileId="1540" thumb="box"}

It may work otherwise (forcing the group registered to be selected) but this is counter intuitive and hurt the user experience as this are not done as help says it should.

In 1.10 now we can set to login as e-mail and display realname wherever possible. But the user wiki page by default is set to 'UserCreate<e-mail>. We should still allow user to create his page with 'UserCreate<username/real name>'.

The recommended behaviour should be if user chooses e-mail to be private or it could be if admin sets to disaply realname wherever possible, then it should use 'UserCreate<realname>' other cases it can be based on e-mail.

If you are using user tracker information, when you delete a user there is a new feature that ask you if you want to delete the user items in trackers and it displays a list of trackers.

"Delete user items from these trackers Warning: Experimental "

It shows the tracker used to store the user information giving the "wrong" impression that you are able to control if the user information will be deleted or saved.

The text is a bit confusing but no matter if you select a tracker or you don’t select it, user item in the tracker used to store the user information will be deleted.

Admin should be able to deactivate this option and it should not be set by default (erasing data cannot be default) as they are case you want to delete users but not the item created at their registration as it can lead to disrupt data cohesion on different area of your website (especially if you use on trackers and other created items relies on the user information data).

{img fileId="1057" thumb="box"}

I have encountered a few snags after upgrading from Tiki 1.9.11 to 2.0

One of the problems is that I am unable to register / add users, because of the following error message:

An error occured in a database query!
Unknown column 'email_confirm' in 'field list'

This happens on
tiki-register.php (registration) and tiki-adminusers.php (batch upload / add)

Is there a fix for this?