# Integratie in een aangepast authenticatiesysteem waar e-mails niet uniek zijn?

**URL:** https://meta.discourse.org/t/integration-into-custom-auth-system-where-emails-are-not-unique/306489
**Category:** SSO
**Tags:** email
**Created:** [2 mei 2024 om 15:50 UTC](https://meta.discourse.org/t/integration-into-custom-auth-system-where-emails-are-not-unique/306489 "2024-05-02T15:50:43Z")
**Posts on this page:** 1
**Showing post:** 31

<div class="post-metadata">

### Author: ![simon](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/simon/32/339122_2.png) [@simon](https://meta.discourse.org/u/simon)
#### Post date: [5 mei 2024 om 19:35 UTC](https://meta.discourse.org/t/integration-into-custom-auth-system-where-emails-are-not-unique/306489/31 "2024-05-05T19:35:39Z")

</div>

> [@jonbarrow](#):
>
> I’ve installed Discourse on a local machine for testing, using [Install Discourse for development using Docker](https://meta.discourse.org/t/install-discourse-for-development-using-docker/102009) as my guide. I couldn’t seem to find any other guides on how to set it up for local testing?

There’s a list of installation methods here: [Set up a local Discourse Development Environment?](https://meta.discourse.org/t/set-up-a-local-discourse-development-environment/182882). I have a non-Docker development site (using the Ubuntu guide). If it’s possible for you to do, I think you’ll get the best results with the non-Docker approach. One of the reasons I use it is to not have to deal with networking issues for API requests between Discourse and other applications that I’m developing locally. It’s faster than Docker too.

> [@jonbarrow](#):
>
> `avatar_force_update` seems to not be respected? Or at least, not for admin users?

It should be. Make sure that the application that you’re generating the SSO payload on isn’t converting the boolean value `true` to `1`. That’s a common problem. To get around it, you can set any boolean values in the SSO payload to the strings `"true"` or `"false"`. Discourse will interpret them correctly. Check that first to see if it’s the issue. It could be something else. The code that handles `avatar_force_update` is kind of complex, but readable: [discourse/app/models/discourse\_connect.rb at 187204705323b650d61ed25862eb1a0c733aa63c · discourse/discourse · GitHub](https://github.com/discourse/discourse/blob/187204705323b650d61ed25862eb1a0c733aa63c/app/models/discourse_connect.rb#L361-L375).

Edit: For the issue of boolean values in the SSO payload, I guess it’s more accurate to say that in the process of generating the SSO payload, the environment is going to convert the boolean values true/false to strings. Discourse is expecting the strings to be `"true"` or `"false"`, other programming environments may deal with them differently. For example:

PHP:

```php
wp> strval(true)
=> string(1) "1"

```

as opposed to Ruby:

```ruby
irb(main):001> true.to_s
=> "true"

```

Python (I’m not sure how Discourse handles this one):

```python
>>> str(True)
'True'

```

---

_[View the full topic](https://meta.discourse.org/t/integration-into-custom-auth-system-where-emails-are-not-unique/306489)._