Privacy issue with profiles
In the community settings, I have configured “Who can view all member pages” to logged-in members only. This works partially, but not fully.
Current behavior:
- When logged out, the community feed is visible, but not all posts are shown. This how I want it. I have some groups visible for both logged in as logged out visitors.
- When a visitor clicks on a username under one of those visible posts, they are redirected to that user’s full profile page.
- On that profile page, all profile information is visible, without any restriction.
This means that even though member pages are set to “logged-in users only”, it is still possible to access full user profiles through a workaround by clicking a username from the public feed.
From a privacy and GDPR perspective, this is a serious concern.
Users may reasonably assume that their profile information is protected when member pages are restricted, but in reality it is still publicly accessible.
What is needed:
There should be a separate and explicit setting for user profiles, for example:
- Public
- Logged-in users only
- Administrators / moderators only
Without this, it is impossible to fully protect user profile data, even when privacy-related settings are enabled.
I want to strongly emphasize that this is not just a feature request, but a privacy issue that affects how safely communities can be run.
I hope this can be addressed or added to the roadmap.
100% agree.
Something alike happens with customers in fluentcart, as Mat reported a couple of months ago. Not sure how that ended though!
Cc: Shahjahan Jewel
I have the same issue and I have an automation that when a user is logged out it completely block the community and go to a landing page.
Shahjahan Jewel please check
I would like to add a fourth option: only see full profile when people are "befriended/connected".
Wilco Wietsma Nice one!
This is very important information, and hopefully the team will solve this bug soon.
Hi Gee Adriaansz I know this is not what you are talking about, but I do have a free snippet that acts like an add-on to give space visibility this extra needed layer of "logged in to see". I needed this for spaces that I want people to be logged in to see, without the extra friction of having to ask permission. it adds another setting for this in fcom settings.
Jeff Great! Till this is fixed by the team, I would love to use it if possible.
Shahjahan Jewel Again.... can you or your team please take a look and respond? I see other later posts getting a response while this is ignored?
Gee Adriaansz this is, actually, a crucial matter. And a potential GDPR issue if not handled properly by the controller.
So the stack capability to get this sorted is fundamental…
Jorge de los Reyes I agree... perhaps Tawsif Ahmed Riyad can take a look?
It always seems that when it comes to fixing the basics. Nobody from the the team responds...
Wilco Wietsma maybe they’re around: just well hidden, like good ninjas.
Jokes aside, this really needs to be fixed.
⚠️ When the merchant is unaware of the issue (which is likely in many cases), the liability exposure is very real and could easily translate into thousands of dollars in fines and damages.
Jorge de los Reyes true... but just a response like, we're working on it, thanks for making us aware of this issue, would be enough. Answering actively other posts and ignoring this post completely, really gives trust issues. For years and years I thought really high of the Ninjas and fully trusted them, but this is not the first time something important gets actively ignored. My trust is slowly declining 🙁 just confirming the issue is apparently not important enough.
Gee Adriaansz I know it's not what your comment is about - but did you manage to implement a workaround for the time being?
Gee Adriaansz Maybe create a support ticket? I noticed the same regarding upsell/downsell questions (fluentcart), because it disappeared from the public road map. After asking and tagging multiple times in the community without response, I did get an answer when opening a ticket.
Gee Adriaansz tbh, I’m honestly quite surprised that an issue affecting urgent GDPR compliance has been outstanding for over 15 days.
It has been commented several times, but communication needs enhancement. As you said, just knowing it reaches the “Inbox” or that it’s being addressed with proper care.
An update is coming soon, as I’ve read here recently. So the timing should be perfect for aiming this.
Shahjahan Jewel This is pretty harsh, not gonna lie. I just imported 4,000 users and discovered this flaw and now I have to figure out how to anonymize all of them :(
I saw that Raiyan Marzan liked the post, so the concern was seen by a dev. It remains to be seen when this will be settled because it is a little problematic.
Hello Gee Adriaansz, I have read your post and bookmarked it. I will address the issue with my team lead and give you an update in the upcoming days.
I solved this by scrubbing all of my existing users and creating a plugin that scrubs any new users. I targeted their Community profile database table directly and only modified their username and display_name.
From a privacy perspective, this is a serious concern. Users reasonably assume their profile data is protected when the directory is restricted, but in reality, it is publicly exposed.
What is needed natively: We really need a separate, explicit setting for user profiles (e.g., Who can view profiles: Public / Logged-in / Admin).
How We Solved It (The Logic) Since we couldn't easily block the profile URL without potentially breaking the feed UI or causing 404 errors, we decided to anonymize the identities instead. If we can't hide the page, we hide the user.
We built a custom plugin that enforces a strict naming convention for all users with the "Subscriber" role, renaming them to user{ID} (e.g., user452).
The tricky part was that FluentCommunity saves user data at various points during the request lifecycle. We found that simply hooking into user_register or fluent_community/space/joined wasn't enough. Often, the core plugin would save the original name after our script ran, overwriting our changes.
The Solution: "The Double Tap" To guarantee privacy, we implemented a "Double Tap" logic:
- Tap One: We hook into the standard join/register events to catch the user immediately.
- Tap Two (The Safety Net): We queue those User IDs and run the sanitization again on the PHP
shutdownhook. This ensures our anonymous naming convention is the very last thing written to the database, overwriting any data the plugin might have saved during the request.
We also built a retroactive "Scrubber" tool to loop through our existing user base and apply this naming convention to everyone historically. This solved our problem for our 4,000 existing users, anonymizes any new users but still allows them to change their profile to whatever they want.
Kyle Dee hey Kyle, the fcom display name is a field that is generated from the user's first name and last name fields. It's recreated every time the user saves their profile. A specific hook is fired when the profile is updated and you can alter the data when it saves. So unless you're intercepting that just now you might find the users display name becomes their firstname+lastname again when they update their profile.
It is serious. I had a Ford Canada privacy auditor instruct us to take the site down at one dealership last week. We are working on a workaround, so far, no luck in disabling hover and click on a username in the feed.
I hope all these privacy and in the end maybe even security type issues will be resolved. This is definitely not a small thing.....
Especially for people operating within the EU or other parts of the world with good privacy regulations. This could potentially lead to court cases and large fines!
The end question is, who is responsible? That's quite scary...
Shahjahan Jewel a response would be nice.
Just to let you know, we have added a new feature where you can configure who can see full profile.
Shahjahan Jewel Thank you, looking forward to the release, so we may submit our project to Ford for reconsideration.
Shahjahan Jewel I already set 'Full Profile View' to 'Only Logged-in Members' – but profiles are still visible to guests. Still not working.
Has the GDPR concern been addressed?
Owen Kane Most of them!
Still some current issues that are being addressed in the next update.
Jorge de los Reyes Many thanks for the update and your efforts to work with Fluent team.