Is there a way to force new users to upload an avatar? I see even on this installation that there is a recommendation shown on the right side, but I would like to enforce this that user can’t do anything up until a picture is provided.
There is no option to require a custom avatar prior to posting that I’m aware of. Would likely need to be a custom plugin.
3 Likes
Ah. Is that possible on the hosted solution though? Any way to make this a setting?
Yeah, a custom plugin won’t work on our hosting (except for Enterprise tier). I don’t see a site setting being added for this at the moment, I can’t recall previous requests for this.
What’s the use case? Why do you need your users to have an avatar prior to posting?
1 Like
We’re trying to replace all our communication tools with discourse. That means from slack, google groups, email, … and connect it within discourse. The challenge is when you tens or hundreds of users without pictures, it’s hard to guess who that is.
There is additional issue, that countries like Slovakia & Czech Republic enforce unified first names so you have 15 million people called 200 names. You can easily end up with hundreds of Peters in a single company and you start running into the challenge identifying a source of the post. A picture is not going to solve it, but will at least help to identify people.
3 Likes
Your best bet would be to use sso and have it provide the Avatars.
2 Likes
Not a great alternative. I would hope that this could be achieved directly. Can’t see a reason why it couldn’t be a feature. But if a plugin is the only option, that’s fine. I can write it. Will just have to cancel our subscription and deal with the headache of a hosted solution.
Sorry. It sounded like you were in a corporate environment where sso would be a good solution.
Requiring an avatar would keep lots of people from ever participating, so few communities would want it.
You might check out the custom wizard plugin. I’m pretty sure (but not positive) that it would let you force users to get an avatar. It too withe require enterprise level, though.
If you do end up self hosting, I can provide installation and/or maintenance support.
I’m in, but dislike SSO greatly.
Understood.
Appreciate it
1 Like
This kind of requirement is really an identity management thing, which is why SSO is being suggested.
The other benefit from the approach others have suggested is that if you were ever to move from Discourse or integrate another product then you wouldn’t need to also ask for avatars to be made mandatory in that product too.
1 Like
I realize that. On the other hand, SSO is a single point of failure for both security and usability. So you have to juggle between these two downsides. Also you change platform at best every couple of years, so changing an avatar is not a huge ask.
1 Like
How is a well-established SSO/IdM less robust than Discourse?
1 Like
What do you mean by robust and how does that relate to what I said above?
Isn’t it the other way around?
A proper SSO increases security and usability:
-
User doesn’t need to re-type passwords for each login, since Discourse will re-use their section from the SSO, which he will in most cases be already logged because of the intranet portal, email, main site, etc
-
Users doesn’t need to create another username and password, so less password reuse.
-
Users don’t need to enter all their details on every tool, neither update their info everywhere.
-
Account suspension when’s user is terminated happen in just one place, less human error.
There is even The SSO Wall of Shame:
8 Likes
So if a user loses access to that one account, what happens? And SSO tends to be connected to an email provider, so your surface of attack is much higher as an attacker will be ready for it more than any other application. It’s true that the user will probably use the same email with all of the services, but it increases the time required to move between services and there is more chance that this behavior is going to be caught earlier as passwords will have to be reseted.
Definitely the largest benefit of SSO.
So SSO isn’t typically attached to an email provider, they’re just the large public examples that most users recognise.
Good examples of well structured SSO and identity management would be stuff like UKfed, which provides SSO to every higher education and research body in the UK:
https://www.ukfederation.org.uk/
SSO doesn’t make an underlying identity any more or less of a vector, arguably it’s another line of defence for a compromised identity.
1 Like
That’s great.
- you leave the body, all your identities are gone
- you get kicked out, all your identities are gone
- a disgruntled employee, all your identities are gone
- someone gets into the system, all your identities are gone
There is a reason why you should not outsource your identity to 3rd party, don’t re-use passwords, make them long and keep them private.
I didn’t come here to argue on usefulness of SSO. You want to use SSO, do it. I just want a simple checkbox that will force each new user to upload an avatar. I don’t think I’m asking for so much considering that there is a setting for literally everything else. Yes, there might not be many communities that will elect to use it, but some might (ours would). We don’t use 90% of other settings, that didn’t stop you to put them there.
If you are happy with a “soft” disable this is doable in a theme component, which is usable in our hosting environment and way easier to maintain anyway. This means protection is client side, not server side. This matters not cause people can upload a blank image with one black pixel and plenty of other bad examples if you put the protection server side
Simplest way to do this would be to override behavior of the reply button to check if current user has a letter avatar and then pop open a modal asking to upload an avatar. Something like that
6 Likes
I didn’t say outsource, you can run your own SSO to achieve this. Points 1/2 are irrelevant, points 3/4 are risks you take running all software, SSO and Discourse doesn’t increase your risk or attack surface.
I’m not sure where the vitriol is coming from but there’s really no need to make a straw-man argument against SSO, it’s there for precisely these reasons.
1 Like
I really tried to explain myself to you. We’re not going to change each other’s mind. Waste of time continuing discussion on SSO.
Thanks Sam. Still would prefer this to be a setting so I don’t have to alter the behavior that will then prevent new updates of the theme whenever needed or override my functionality each time you deploy new code.
If there is a chance to add this option, I would be very appreciative.