forum.coppermine-gallery.net
Dev Board => cpg1.4 Testing/Bugs => cpg1.4 Testing/Bugs: FIXED/CLOSED => Topic started by: donnoman on February 24, 2005, 07:58:42 am
-
I created a new group "special" I assigned a user to it, Log that user on, and not only does the user not see those items in the meta albums, they can't even see the album under the category its assigned.
Page generated in 0.272 seconds - 40 queries in 0.049 seconds - Album set : AND aid NOT IN (8) AND aid IN (-1) ; Meta set: AND cpg14x_pictures.aid IN (-1) ;
-
I created a new group "special" I assigned a user to it, Log that user on, and not only does the user not see those items in the meta albums, they can't even see the album under the category its assigned.
Page generated in 0.272 seconds - 40 queries in 0.049 seconds - Album set : AND aid NOT IN (8) AND aid IN (-1) ; Meta set: AND cpg14x_pictures.aid IN (-1) ;
I was able to reproduce this on another install, so its not a result of my latest changes. I'm going to go ahead and commit my fixes.
I reproduced the new bug, too.
The original issue seems to have been fixed. When logged out, images from private albums do not show up in random meta album.
-
Well for once, I'm reasonably certain this isn't something I broke.
I think there still may be issues with $META_ALBUM_SET, but $ALBUM_SET isn't correct right now either.
From what it looks like to me:
This line from functions.inc.php is part of the problem
$sql = "SELECT aid FROM {$CONFIG['TABLE_ALBUMS']} WHERE visibility != '0' AND visibility !='".(FIRST_USER_CAT + USER_ID)."' AND visibility NOT IN ".USER_GROUP_SET;
USER_GROUP_SET isn't getting the additional groups in "user_group_list".
ie:
This is the SQL line but this user is attached to 4 groups.
SELECT aid FROM cpg14x_albums WHERE visibility != '0' AND visibility !='10003' AND visibility NOT IN (2)
This is probably best addressed in the coppermine bridge file, I'd prefer a dev more familiar with bridging fool with it than me.
-
Hmm
[edit]
Try the latest coppermine bridge, version 1.13.
[/edit]
-
Using 1.13 still have the problem.
Album = 8 is assigned visibility = 5
My user Donnoman has user_group=5, user_group_list = 2,6,7
my group named "special" has an id of 5 and isn't shown.
album = 6 is shown, and does work and has visibility = 6
so slight improvement, but not fixed yet.
Page generated in 0.451 seconds - 94 queries in 0.156 seconds - Album set : AND aid NOT IN (8,36,37) ; Meta set: AND aid IN (6,38,39,7,1,2,3,4,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35) ;
-
OK. I know what the problem is.
-
I think I'm seeing the same bug? Basically I have two albums that are only viewable by administrators (myself and one other person) along with a special group of "friends" who are placed in the "friends" group. However, when a person from my friends group logs in, they cannot see the albums that I have allowed them to view. They cannot see anything that an unlogged in user can see when they should be able to. I just updated from CVS today thinking the problem might have been that my files were 4-5 weeks old, but it did not fix the problem. :(
-
Has this been fixed? The special group I created now can see its assigned albums.
-
Yes, this was related to another problem that was happening with the SMF bridge.
Omni and I addressed the coppermine.inc.php bridge and SMF, devs who work on the other bridges should read that thread, and check thier bridges.
http://forum.coppermine-gallery.net/index.php?topic=15067.0
-
Mine isn't bridged and I'm seeing that particular bug... is it a completely different issue or what?
Edit: updated the coppermine.inc.php file and it fixed the issue even though I don't have a bridged install.
-
Coppermine 1.4 uses the coppermine.inc.php "bridge" for it's core user code. When you select a different bridge, it supplants Coppermine's native code.
The problem that you experienced while you believed yourself to be technically "un-bridged" was actually a problem in the coppermine bridge file.
So as you found out, updating the bridge solved your problem.
-
Has this been fixed? The special group I created now can see its assigned albums.
Yes, but they can also see the albums which they are not supposed to see. :D
E.g. I am a member of "special" group only and I am also able to see the albums for "Registered Users".
-
I confirmed that, and did uncheck the "registered" group from the user's profile. However, is "special" not just a subset of "registered"? As admin, if you allow an album to be seen by registered users, should they not be viewed by any registered user?
However, it is an issue when a user in the banned group can access special-access albums. :-\\ Actually, the banned group shouldn't be able to even access the album. I changed the setting for a user using the checkboxes and dropdown menu to "banned" and the user can still log in.
-
I confirmed that, and did uncheck the "registered" group from the user's profile. However, is "special" not just a subset of "registered"? As admin, if you allow an album to be seen by registered users, should they not be viewed by any registered user?
The name "registered" is notional for a member being in a default group. If all groups are sub groups of registered then having album permissions does not make sense at all
-
The name "registered" is notional for a member being in a default group. If all groups are sub groups of registered then having album permissions does not make sense at all
However, it is an issue when a user in the banned group can access special-access albums.
Actually, the banned group shouldn't be able to even access the album. I changed the setting for a user using the checkboxes and dropdown menu to "banned" and the user can still log in.
I don't understand what you guys want done. I was under the same impression as Tranz. Doesn't registered mean "registered"? It's natural that a user gets the highest privileges available to them, so if the user is a member of more than 1 group, the one with the most privileges is used. Basically they should merge.
If you guys notice, the default "registered" group is added to ALL accounts in all the bridges. This is probably just realized, since coppermine, itself, is now bridged. The IF statement says that if they're not an administrator (in an administrators group) and the user logged in then the user is a registered user, and it adds that group automatically.
[edit]
All that said, most likely, what's happening is that the login process isn't checking the group permissions correctly...meaning that it's not overiding the normal process of merging the groups. My plan, after the 1.4 release, is to clean up and redo the group process then let everyone test it out. Right now, it's kind of unstable...everything seems to be pieced together. Please explain what you guys want done. If you want the highest level to be default then it'll be all-inclusive; there's no way to prevent it. If you want lowest, then it'll also be all-inclusive.
On that note, what exactly does the banned group do that the ban column (I forgot the actual name) in the user's table don't do? I don't think there should be a group just for this. If it's done this way then it'll be cleaner and easier to program. The extra group messes it up, IMO.
[/edit]
-
I don't think a banned user should be able to log in. As it is, a banned user is still able to log in, and access albums that are assigned to other groups.
-
I'm with omni and tranz on this.
surely registered is the basic group for membership, and albums viewable to 'registered only' should be viewable by all higher groups. All members are part of the registered group, whether thay have other group membership or not.
That has always been the case.
If you want to restrict viewing of any album to certain members only, then you have them in a special group, and edit the album properties accordingly.
-
IMO
The registered group should mean anybody who has an active user account that is not in the banned group.
Group rights should be merge, least restrictive wins.
banned should be like the "deny" right. It trumps all. game over, do not pass go, do not collect $200.
-
much more clearly put that my post, but I agree entirely.
-
Yes, but they can also see the albums which they are not supposed to see.
E.g. I am a member of "special" group only and I am also able to see the albums for "Registered Users".
Now, we can remove the registered group from being automatically included, which is what the bridge files do, since it's possible for the admin to uncheck it in the user administrator. This may solve what you are talking about. I don't know what other problems it may cause though.
It may take me a couple days to test it out. I'll have to let someone else commit it though. Right now, my test computer can't get on the internet, since I'm away on a business trip.
-
I guess simplest solution is that
#1) a member cannot be removed from the registered group and
#2) we should mention that the viewing permissions are inclusive and not atomic
-
OK, let's go for the method suggested by Tarique then. Who will implement the needed changes (at least the docs should be updated imo)?
Joachim
-
I will implment #1. Somebody please update the documents.
-
I've already done this. However, I cannot commit until Saturday. I'm away.
-
Oops!! I already commited.
I have removed registered as well as banned from the secondary group listings.
-
No problem. I'll download a nwe copy when I get back.
-
Aditya, what happens when bridged?
We've recently had some problems with editOnePic.php and images in an album where "registered" users should have been able to upload and maintain thier own pics. However the user was in a specific group of SMF.
I suspect the problem was that this user didn't come through the SMF bridge as being in both the "registered" and thier secondary group. Only thier secondary group. So what happened is that the user made a modification to the image, didn't notice the alb list was no longer populated then pressed submit.
It wrote the pic back to the table with an aid of zero, and the pic went MIA. I was able to manually re-assign the pic's aid with phpmyadmin, and I've fixed editOnePic to at least show the album thats currently assigned so this no longer happens. But if the user isn't getting the registered group, then they will likely have other problems.
-
In the code, registered is added automatically even in the bridges, so removing the "option" doesn't do anything.
-
as a normal "registered" user, I uploaded a pic to an album (worked fine) then I tried to go back in and edit it.
You don't have permission to access this page.
File: /home/cpg-contrib/public_html/editOnePic.php - Line: 24
USER:
------------------
Array
(
[ID] => 018eb1ee7a85ae957da115e8b620759e
[am] => 1
[lang] => english
[liv] => Array
(
[0] => 13
)
)
==========================
USER DATA:
------------------
Array
(
[user_id] => 12
[user_name] => brayd
[groups] => Array
(
[0] => 2
)
[disk_max] => 1024
[disk_min] => 1024
[can_rate_pictures] => 1
[can_send_ecards] => 1
[ufc_max] => 3
[ufc_min] => 3
[custom_user_upload] => 0
[num_file_upload] => 1
[num_URI_upload] => 1
[can_post_comments] => 1
[can_upload_pictures] => 1
[can_create_albums] => 0
[has_admin_access] => 0
[pub_upl_need_approval] => 1
[priv_upl_need_approval] => 1
[group_name] => Registered
[upload_form_config] => 3
[group_quota] => 1024
[can_see_all_albums] => 0
[group_id] => 2
)
==========================
Queries:
------------------
Array
(
[0] => SELECT extension, mime, content, player FROM cpg140_filetypes; (0s)
[1] => select * from cpg140_plugins order by priority asc; (0s)
[2] => SELECT * FROM cpg140_bridge (0s)
[3] => SELECT group_id FROM cpg140_usergroups WHERE has_admin_access (0s)
[4] => SELECT ID_MEMBER as user_id FROM `cpgcontrib`.smf_members WHERE ID_POST_GROUP in (1,101) (0s)
[5] => SELECT u.ID_MEMBER AS id, u.memberName AS username, u.passwd AS password, u.ID_POST_GROUP+100 AS group_id FROM `cpgcontrib`.smf_members AS u INNER JOIN `cpgcontrib`.smf_membergroups AS g ON u.ID_POST_GROUP=g.ID_GROUP WHERE u.ID_MEMBER='12' (0s)
[6] => SELECT MAX(group_quota) as disk_max, MIN(group_quota) as disk_min, MAX(can_rate_pictures) as can_rate_pictures, MAX(can_send_ecards) as can_send_ecards, MAX(upload_form_config) as ufc_max, MIN(upload_form_config) as ufc_min, MAX(custom_user_upload) as custom_user_upload, MAX(num_file_upload) as num_file_upload, MAX(num_URI_upload) as num_URI_upload, MAX(can_post_comments) as can_post_comments, MAX(can_upload_pictures) as can_upload_pictures, MAX(can_create_albums) as can_create_albums, MAX(has_admin_access) as has_admin_access, MIN(pub_upl_need_approval) as pub_upl_need_approval, MIN( priv_upl_need_approval) as priv_upl_need_approval FROM cpg140_usergroups WHERE group_id in (2) (0s)
[7] => SELECT group_name FROM cpg140_usergroups WHERE group_id= 2 (0s)
[8] => SELECT user_favpics FROM cpg140_favpics WHERE user_id = 12 (0s)
[9] => SHOW TABLES LIKE 'cpg140_cms_config' (0s)
[10] => SELECT * FROM cpg140_cms_config (0s)
[11] => DELETE FROM cpg140_banned WHERE expiry < '2005-03-25 23:36:53' (0s)
[12] => SELECT * FROM cpg140_banned WHERE (ip_addr='4.3.129.24' OR ip_addr='4.3.129.24' OR user_id=12) AND brute_force=0 (0s)
[13] => SELECT aid FROM cpg140_albums WHERE visibility != '0' AND visibility !='10012' AND visibility NOT IN (2) (0s)
[14] => SELECT COUNT(*) FROM cpg140_pictures WHERE approved = 'NO' (0s)
)
==========================
GET :
------------------
Array
(
[id] => 13
[what] => picture
)
==========================
POST :
------------------
Array
(
)
==========================
Page generated in 0.143 seconds - 15 queries in 0 seconds - Album set : AND aid NOT IN (5) ; Meta set: ;
editonepic line 24
if (!(GALLERY_ADMIN_MODE || USER_ADMIN_MODE)) cpg_die(ERROR, $lang_errors['access_denied'], __FILE__, __LINE__);
It looks like it doesn't think im in USER_ADMIN_MODE
[edit]Allow users to retain control over their pics in public galleries IS on in the config[/edit]
-
*bump*: what's the status of this issue?
Joachim
-
In the code, registered is added automatically even in the bridges, so removing the "option" doesn't do anything.
The above is true.
What donnoman is experiencing is most likely something different. So, lets split this thread and mark the original issue as done.
-
The other issue I spoke of was already fixed when I posted.
I just thought the problem may have been related to this post.
So I think the thread can be marked fixed, don't bother to split.