I’m a bit confused about this, I suspect (hope?) it’s a bug because it seems quite bad!
One of my staff members noticed that if you google for his email address, our forum’s about page comes up. If you look at the google cached version it shows this (I’ve blacked out email addresses but each black blob is the user’s email address):
I’m not sure how to test if the update has fixed it or not since I can’t see email addresses on the live site, just through the cached google version… do you have any suggestions for checking that?
All updated, but checking with fetch as google is still showing the email addresses. I’ll go through and add full names to each of our staff, I guess, and see if that helps…
edit
Seems I can’t edit names… it’s not set to sso overrides names so I’m not sure why that is!
However, in checking the settings, I did turn “enable names” back on (we’d turned it off) and it does seem that those fields are filled with email addresses. It probably ought not to load that data if “enable names” is off though?
further edit
Ah, for some reason I have to go to each user’s preferences rather than doing it from Admin of that user.
Should I create a new bug report for full name info being loaded and therefore scraped by Google?
I did update before posting my last post here (we’re now on v1.7.0.beta4) and it was still happening - I’ve since gone in and changed all the “full names” for staff to their usernames so that their email addresses aren’t accessible.
This is googlebot’s render of the page as it currently exists.
Surely showing full names somewhere while the “enable names” option (“Show the user’s full name on their profile, user card, and emails. Disable to hide full name everywhere.”) is off a bug? I had to re-enable that option (we had it disabled) and turn off “sso overrides name” in order to view and edit each staff member’s full name… (the field looked blank in their profiles, even under admin view, with the option disabled).
It doesn’t actually show full names to most people though - the about page looks like this to me (and still the previous post’s image to Google):
Does the sso default to filling that field with email? We don’t think we send any sso info for that field but perhaps we do and that needs fixing on our side (we’re sorting that out at the moment - explicitly sending character name [already used for “username”] to “full name” as well).
So you’re talking about two distinct things at once. Let’s break it down for clarity:
My SSO is acting weird
Enable SSO verbose logging and see the SSO field in the user admin screen to help debugging.
Full names
If Full Names are being displayed in the /about page when disabled by a setting that says they must disappear everywhere that’s something we need to fix.
Yes, both of those things are true. Apologies for causing confusion! We can fix the SSO thing (and if it turns out it’s seemingly randomly populating the “full name” field with email addresses I’ll raise a separate report about that).
My main concern at the moment is that it is sort of displaying full names in /about with the option to use them anywhere disabled (ie they should be hidden everywhere according to the option text).
More investigation - looks like for some reason we’re piping email into “full name” without realising we were doing it, so going to fix that.
However, the bug that does seem to exist is that the about page shows whatever’s in the “full name” box even with the option disabled in settings. Weirdly, I would have thought this fix - https://github.com/discourse/discourse/pull/3121 - should have prevented it from happening but as in my previous post we’re on latest beta (as of a day or so ago) and still getting it (you can see it if you switch user agent to google and visit https://forum.skysaga.com/about). So I’ve renamed this thread to be more accurate about the issue, and if anyone has any suggestions that’d be great!
Apologies for any inaccuracies—this is from memory, from over a year ago: When implementing my SSO I found that if the SSO payload omitted or left the “name” field empty, that there was some code in Discourse itself that would populate it with a value inferred from the user’s email. The workaround was to have the SSO explicitly populate the “name” field as a copy of the username.
Because names-off does not seem to be the most-tested configuration, I’d recommend a bulk sync of you users from your SSO and looking in the db table to verify that you’ve clobbered all the email-derived names, just in case there are any future bugs that leak the name field.
Sounds like the SSO population of “full name” might be a bug (the docs suggest that both username and name are optional, but it’s unclear about the designed behaviour if either is left blank). Could someone staff-y maybe clarify what the desired behaviour is and whether I should report this as a bug separately?
