phpBB • Free and Open Source Forum Software

When you manage a specific user and then select the "Permissions" form from the pull down it displays a nice table but immediately after that it shows the following stuff:

ACL_TYPE_GLOBAL_A_AAUTH
ACL_TYPE_GLOBAL_A_ATTACH
ACL_TYPE_GLOBAL_A_AUTHGROUPS
ACL_TYPE_GLOBAL_A_AUTHUSERS
ACL_TYPE_GLOBAL_A_BACKUP
ACL_TYPE_GLOBAL_A_BAN
ACL_TYPE_GLOBAL_A_BBCODE
ACL_TYPE_GLOBAL_A_BOARD
ACL_TYPE_GLOBAL_A_BOTS
ACL_TYPE_GLOBAL_A_CLEARLOGS
ACL_TYPE_GLOBAL_A_EMAIL
ACL_TYPE_GLOBAL_A_FAUTH
ACL_TYPE_GLOBAL_A_FORUM

After that it is just a train wreck of partial tables, no idea what that stuff is but I am pretty sure it is not right.

Tested on a clean RC1 install, couldn't find this issue already logged.

What browser are you using?

I am using Firefox 2.0, but it does the same in IE 6.0.

Have you cleared the forum cache?

I had this problem on a fresh install of RC1, would I need to clear the "forum cache"? Also, is forum cache the same as:

Purge the cache
Purge all cache related items, this includes any cached template files or queries.

If so, then the answer is yes I have cleared the cache and it hasn't made a difference.

Here is a screen shot of what I am talking about, if it helps.

Okay, after figuring out that this is a PostgreSQL specific issue I dumped all of the SQLs fire off when editing permissions and found that this query:

SELECT auth_option, is_local, is_global
FROM phpbb_acl_options
WHERE auth_option LIKE '%\_' AND is_global = 1
ORDER BY auth_option;

was the culprit, and it should be written as:

SELECT auth_option, is_local, is_global
FROM phpbb_acl_options
WHERE auth_option LIKE '%\\_' AND is_global = 1
ORDER BY auth_option;

This is normally done via $db->sql_escape, but it was not being called for this case. So attached is a patch that I believe will fix this, I also found a few other cases of the same mistake and hopefully fixed those too.

Hi, sorry, I can reproduce. I do not believe that the escape plays into this (or are you absolutely certain?), nor do I believe this to be PSQL specific.

As to your patch: two problems: db_escape won't escape LIKE clauses properly and it would introduce a mild security issue due to the double quotes used.