Forum Replies Created
-
@henrywright Brajesh has confirmed and posted a patch, check the ticket.
I can view anyones messages when logged out. If I log in I think it shows me my own messages, not sure, the main issue is that someone could easily harvest every single message from a buddypress site. Users are not tech savy and will presume that correspondence is relatively secure so there may be sensitive data stored. Or at worst it would give enough information for an attacker to social engineer the additional data they need.
With standard buddypress (no modifications) you can freely view anyone’s messages without even logging in. Personally I think that is not very good security/privacy, whatever you want to call it.
I made a ticket as I don’t think that “private messages” should be publicly viewable
(https://buddypress.trac.wordpress.org/ticket/6504#ticket)What privacy/security checks would you recommend for people who don’t want users private data publicly viewable?
@henrywright How would you do the security check? If I follow current way buddypress does things with loading the template part for the tab any logged out user can just modify the javascript and get into any profile page they like. It’s first time I’ve done this so appreciate the advice.
what harm could come from a visit to a simple profile tab?
You could see hidden data that user did not want displayed. I believe if you hold data and say it is private then you should attempt to secure it. You could also view their messages and private groups.
The thing I am struggling to understand is how buddypress functions work on the post request. I wrote some test code and data is correctly populated from displayed user. Does buddypress read a referrer value somewhere on every ajax post?
I just started implementing this in my theme. I was going to try to hook into bp_filter_request() but it doesn’t use nonces so I am not sure if it is secure for loading tabs that may have restricted visibility.
I couldn’t see anything on trac. Is this being worked on at the moment?
@shanebp Thanks for the reply.
[…]in any relational table, if an item is assigned to a group ID and that group ID no longer exists in the table that holds group IDs, then that data will not be displayed, ie. orphaned.
I deleted through the admin panel so I am not sure what was deleted, that was what I meant by asking if is was standard behaviour. Possibly what I should have said is; when a user deletes a group by using the ‘bp-profile-setup’ page to click on the ‘delete group’ button, is buddypresses default behaviour to just drop the group and leave the profile data in the table or does it also iteratively remove the profile fields?
I can see the reason why you would want to leave the data in the table (and also reasons why you wouldn’t). I had a quick look at the code but I am not familiar enough with it yet to pinpoint the exact code block.
If fields are not deleted then I guess any fields directly referenced would still be visiable on the site. That may be misleading to user as they may assume deleting a group would also remove fields. However you wouldn’t want a group to be deleted by accident and then a large amount of data be lost. I would guess a system of deleting the group and then updating each profile field to explicitly notify calling functions that their parent has been deleted would be appropriate in the circumstance.
I have used a relational database before but I am unfamiliar with the logic employed by buddypress to interact with it.
The behaviour I was was getting was weird. When I deleted a group and created it again no fields were showing. Then when I added a field, it had a value immediately after creating so something weird was going on so I thought I would ask to see if you knew if the profile data gets deleted when a user clicks delete group in admin panel.
I am starting again now so will pay closer attention to all data as it goes into fresh tables but sometimes it is harder to see to absence of data compared to the addition of new data.
Why? BP will always create a Base group.
I am running a multisite where individual user blogs can create their own fields (https://codex.buddypress.org/themes/guides/segregated-x-profile-fields-for-multisite/).
As the article says:
This code will not create dummy content, so for every new site you will need to create a Profile Fields group and add profile fields to it manually.
When I create new site there are no field groups made at all which I assumed is what it was talking about. Also I wanted to have a default set of groups but allow subsite to edit them. If they want to get default groups back they can just delete all their groups and default will be restored. I could add a separate button for that but I just figured I’d do it like this, no particular reason, I am still in early stages of project.
I think there were other errors at play so starting from scratch with a little more understanding will hopefully enlighten me. I will be duplicating tables this time instead of using meta table.
@henrywright Thanks Henry, studying it now 🙂
@shanebp I was just trying to make things consistent on subsites. This function will run on new install or if 0 groups are detected. I guess it doesn’t matter its just a bit of a smell that tells me I am probably doing something wrong somewhere.Is it standard behaviour for when a group is deleted via admin the profile data is left orphaned?
This is my first site of this type. I am not sure if I should be having separate process to check for orphaned data.
It turns out the plugin I was using should have made independant tables anyway so I have to start again and work out what went wrong.
Thanks for the help.
Yeah something weird is going on as when I create a new field it automatically has the data of a previous field I have deleted.
I am guessing when I segmented the fields it caused an issue with the delete process. It deletes from admin panel but sometimes it says “there was an error deleting” so I guess part of the data remains.
I am going to have to get to grips with buddypress schema.
I discovered reason. I didn’t know about the setting in user profile for display name. If this is changed then the method works correctly.
This works:
/*** * @var $bp BuddyPress */ global $bp;It’s just for network admin. Needs code changed for subsite. I think the issue might be that until a user is activated they are not associated with any subsite. This makes it hard to filter it.
Quite a few knock on issues as well. I think I will play it by ear and disable add user for subsites admin panel.
Thankyou thankyou thankyou!
Spent hours stepping through code trying to figure it out and gave up in the end but that plugin works perfectly.
Do you know if it can work on subsites as well?
I have same issue. Did you find any solution?
D’oh!
For some reason my IDE had excluded it from scope. This was why nothing was working. I added it back and its all good now.
Thanks. I was getting all sort of conflicting advice but realised my mistake. I copied parts of legacy folder to my theme and it’s all simple to edit now. The fact default is called legacy and legacy is called default confused me so I had not taken right approach but it’s my fault for not reading carefully enough.
Thanks
I phrased it bad. What class type is $bp? I can then use phpdoc @var to enable autoprediction.
Figured it out. I added “bp_moderate” to a new role and that role can see it now.
It dawns on me there are several other things like this I will need to update 🙁
Capabilities were a red herring! It uses manage_options whhich subsite admins have so its not a cpability issue.
There must be an explicit
is_super_admin()somewhere.I searched in the xprofile folder but no
is_super_adminanywhere.I now feel like I am searching for a needle in a haystack.
OK, so buddypress doesn’t use capabilities. How the hell am I meant to make this work?
I ran the code but I cannot work out if it has worked because “wp-admin/users.php?page=bp-profile-setup” is only available to super admin.
Does anyone know what capability it uses?
I’ve been staring at the code for a while and it’s starting to make sense.
I’m not great with databases but looking at the function I gather it changes a few fields into primary keys that point to the data table so fields can be individual.
It runs the table modification code on the
dbdelta_create_querieshook.The wordpress codex seems to say that this action will happen anytime a database or a table is created.
Am I right in saying that this only ever has to be run once? Can I just run it once on admin init then remove it and add the
modify_bp_global_xprofiles_tablenamesat runtime or have I misunderstood it?(Edit link is not working for some reason so double posting)
Another issue I have is how do I update existing sites to use the new tables?
