# שימוש ב-Discourse כספק זהות (SSO, DiscourseConnect)
**URL:** https://meta.discourse.org/t/use-discourse-as-an-identity-provider-sso-discourseconnect/32974
**Category:** Integrations
**Tags:** sso, discourseconnect, how-to
**Created:** [7 בספטמבר, 2015, 9:19am UTC](https://meta.discourse.org/t/use-discourse-as-an-identity-provider-sso-discourseconnect/32974 "2015-09-07T09:19:21Z")
**Posts on this page:** 20
**Page:** 4
### Author:  [@simon](https://meta.discourse.org/u/simon)
#### Post date: [14 במרץ, 2017, 12:09pm UTC](https://meta.discourse.org/t/use-discourse-as-an-identity-provider-sso-discourseconnect/32974/62 "2017-03-14T12:09:18Z")
> [@JagWaugh](#):
>
> Quick question on “Sync Existing Users by Email”: What does this do, and when?
It’s only for the case where there are existing users who have unlinked accounts on both WordPress and Discourse. The plugin uses the Discourse user\_id to link the accounts. Until they are linked, it needs some way to associate the accounts. The option allows that to be done through the email address. Once the accounts are linked, it isn’t used anymore.
If that option isn’t enabled, the only way for users with existing accounts on both systems to connect them is to click the ‘Link account with Discourse’ link on the user’s profile page.
For accounts that are created through Discourse, the issue never comes up.
The easiest way to see how it works is to try creating separate accounts on WordPress and Discourse using the same username and email, then try logging in through Discourse with the setting disabled. Delete and recreate the WordPress account and try logging in again with the setting enabled. You’ll see what it’s doing.
---
### Author:  [@JagWaugh](https://meta.discourse.org/u/JagWaugh)
#### Post date: [14 במרץ, 2017, 12:17pm UTC](https://meta.discourse.org/t/use-discourse-as-an-identity-provider-sso-discourseconnect/32974/63 "2017-03-14T12:17:16Z")
Excellent. We are using WP to serve ads with AWCP, so we have a few users who have created WP accounts already. I asked them to use the same username and email on the WP site, so will this automatically (or Simonmagically) link the two accounts if they’ve used the same username and email?
> [@simon](#):
>
> It’s only for the case where there are existing users who have unlinked accounts on both WordPress and Discourse. The plugin uses the Discourse user\_id to link the accounts. Until they are linked, it needs some way to associate the accounts. The option allows that to be done through the email address. Once the accounts are linked, it isn’t used anymore.
---
### Author:  [@simon](https://meta.discourse.org/u/simon)
#### Post date: [14 במרץ, 2017, 1:03pm UTC](https://meta.discourse.org/t/use-discourse-as-an-identity-provider-sso-discourseconnect/32974/64 "2017-03-14T13:03:43Z")
Yes, if that setting is enabled, the accounts will become linked when they click the ‘Login with Discourse’ link. You can also embed the login link to the WordPress site directly on your forum.
If that setting isn’t enabled, the login process can be a little confusing for users who have existing accounts.
The login process also isn’t great for users who register through WordPress but don’t have an account on the forum - when they complete their registration and go to the WordPress login page, they see the ‘login with Discourse’ link, but it won’t work for them until they create an account on Discourse. Generally, I think the best flow for this feature is to get users to login to the website directly from the forum.
A link with this structure can be embedded on your forum: (I think this can eventually be simplified a bit, we should be able to get rid of the `discourse_sso` parameter.)
`Login to the Website`
If a Discourse user clicks on this link on the forum, it will create an account for them on the website and take them to the ‘testing-avatar-url’ page:
---
### Author:  [@jetatomic](https://meta.discourse.org/u/jetatomic)
#### Post date: [20 במרץ, 2017, 6:48am UTC](https://meta.discourse.org/t/use-discourse-as-an-identity-provider-sso-discourseconnect/32974/65 "2017-03-20T06:48:29Z")
> [@iamntz](#):
>
> Finished linting, added documentation, I think I’m done.
Huge thank you for this, @iamntz. I hit refresh on the PR for weeks until it was merged.
Thanks to @simon for sticking with it as well.
Very nice work and very much appreciated.
---
### Author:  [@simevo](https://meta.discourse.org/u/simevo)
#### Post date: [21 ביוני, 2017, 1:02pm UTC](https://meta.discourse.org/t/use-discourse-as-an-identity-provider-sso-discourseconnect/32974/66 "2017-06-21T13:02:14Z")
Hi, is it possible to pass back & forth more than just the `return_sso_url` ?
For example if `return_sso_url="https://example.com/sso.php"` then discourse on successful login redirects to:
`https://example.com/sso.php?sso=...&sig=...`
but I would like to have:
`https://example.com/sso.php?sso=...&sig=...&redirect=/protected_page/42`
What is the right way to pass the `redirect` bit ? as a query parameter ? as a member of the payload data structure ?
---
### Author:  [@simevo](https://meta.discourse.org/u/simevo)
#### Post date: [25 ביולי, 2017, 9:52am UTC](https://meta.discourse.org/t/use-discourse-as-an-identity-provider-sso-discourseconnect/32974/67 "2017-07-25T09:52:08Z")
We have found a workaround by saving the desired additional **return url parameter** in a cookie on the client
[This](https://gitlab.com/simevo/calo.news/commit/090d4f2b5a5dd2f3da1f696751c020b961913baf) works for us:
1. when the user accesses a protected page and we need to check again with the [Discourse SSO](https://meta.discourse.org/t/13045?silent=true) provider whether she can access that, store the desired return URL in a cookie: `setcookie('redirect', $_SERVER['REQUEST_URI'], time()+60, "/", "", true, false);`
2. when the user accesses a protected page, and we let her through, clear the cookie: `deleteKey('redirect');`
3. when the SSO is successful and the RETURN\_URL gets called by Dicsourse SSO, check if the cookie is set and if so redirect:
```plaintext
if (isset($_COOKIE["redirect"])) {
$redirect = $_COOKIE["redirect"];
header("location: $redirect");
} else {
header("location: $home");
}
```
---
### Author:  [@Sakerdot](https://meta.discourse.org/u/Sakerdot)
#### Post date: [10 באוקטובר, 2017, 1:11pm UTC](https://meta.discourse.org/t/use-discourse-as-an-identity-provider-sso-discourseconnect/32974/68 "2017-10-10T13:11:51Z")
Hi, I created a Meteor package to use this protocol, you can find it here:
> **[The trusted source for JavaScript packages, Meteor.js resources and tools |...](https://atmospherejs.com/sakerdot/accounts-discourse)**
>
> The best way to discover reliable Meteor packages to install in your apps.
Any suggestions are welcome!
---
### Author:  [@meglio](https://meta.discourse.org/u/meglio)
#### Post date: [21 באוקטובר, 2017, 2:07am UTC](https://meta.discourse.org/t/use-discourse-as-an-identity-provider-sso-discourseconnect/32974/69 "2017-10-21T02:07:59Z")
Any known module for Drupal which would make a Drupal instance an SSO client?
---
### Author:  [@dgrant](https://meta.discourse.org/u/dgrant)
#### Post date: [1 בנובמבר, 2017, 12:25am UTC](https://meta.discourse.org/t/use-discourse-as-an-identity-provider-sso-discourseconnect/32974/70 "2017-11-01T00:25:39Z")
I would like to dispense with the wordpress login completely and have users register and login using discorse.
What I mean is that currently when a user visits the wordpress site they have to click login and then on the wordpress login page click Log in with Discourse. Is it possible to have wordpress check for a discourse login when the user visits the site and if the user is not logged when clicking the login button re-directed to the discourse login/registration page?
---
### Author:  [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [1 בנובמבר, 2017, 2:40am UTC](https://meta.discourse.org/t/use-discourse-as-an-identity-provider-sso-discourseconnect/32974/71 "2017-11-01T02:40:20Z")
You can switch it so that Discourse is the SSO master so that when people want to log in to WordPress they are redirected to Discourse.
---
### Author:  [@simon](https://meta.discourse.org/u/simon)
#### Post date: [1 בנובמבר, 2017, 3:54am UTC](https://meta.discourse.org/t/use-discourse-as-an-identity-provider-sso-discourseconnect/32974/72 "2017-11-01T03:54:09Z")
> [@dgrant](#):
>
> I would like to dispense with the wordpress login completely
I think that could work well, but you should keep the ability for admins to log in directly to the WordPress site. Password protecting the WordPress login form and creating a custom login form that only includes the Discourse login link might work. You can add a Log in with Discourse link to a page with the `[discourse_sso_client]` shortcode.
---
### Author:  [@frictionel](https://meta.discourse.org/u/frictionel)
#### Post date: [14 בינואר, 2018, 10:03pm UTC](https://meta.discourse.org/t/use-discourse-as-an-identity-provider-sso-discourseconnect/32974/73 "2018-01-14T22:03:55Z")
> [@ianmackinnon](#):
>
> sso seems to have a trailing newline which needs to be included when sent to the HMAC function, so it’s important to make sure that SSO consumer applications don’t strip whitespace from these query arguments.
Looks like something changed there. I had to remove the newline from the returned SSO string which I added intentionally at time of implementation, because otherwise the hash wouldn’t match in my php app. I believe this happened after updating to Discourse 1.9.
---
### Author:  [@simevo](https://meta.discourse.org/u/simevo)
#### Post date: [9 באפריל, 2018, 5:45pm UTC](https://meta.discourse.org/t/use-discourse-as-an-identity-provider-sso-discourseconnect/32974/74 "2018-04-09T17:45:02Z")
> [@techAPJ](#):
>
> You’ll find this query string will also contain a bunch of user information, use as you see fit.
Indeed the returned query string contains these fields:
- admin
- external\_id
- username
- groups
- email
- nonce
- name
- return\_sso\_url
- moderator
there is a problem with the `groups` field though: you’d expect it to be an array, but it actually is a string and it seems to contain only the primary group, except for staff members it is just “staff”.
Is this by design ?
---
### Author:  [@simevo](https://meta.discourse.org/u/simevo)
#### Post date: [11 באפריל, 2018, 7:24pm UTC](https://meta.discourse.org/t/use-discourse-as-an-identity-provider-sso-discourseconnect/32974/75 "2018-04-11T19:24:22Z")
OK I decided to troubleshoot this matter myself !
I’ll post my findings here in case that helps others.
First I log onto the docker app, and add this code:
```plaintext
p "====== sso.groups = ", sso.groups
```
after [this line](https://github.com/discourse/discourse/blob/master/app/controllers/session_controller.rb#L55), then I restart unicorn:
```plaintext
sv restart unicorn
```
when I force the SSO from the webapp, I can find the debug print in `log/unicorn.stdout.log`, it looks like this:
```plaintext
...
====== sso.groups = ["trust_level_0", "trust_level_1", "trust_level_2", "moderatori", "staff", "Soci"]
```
whereas in `log/production.log` I can see the sso parameter passed back to the webapp:
```plaintext
Redirected to https://webapp.example.com/sso.php?sso=bm9uY2U9MzViMmZjYTMwMGQwZWNmZDI5ZWYzNWE0MTIyMGIyMTIyYTczYTU3ZDFmYmEzZjhmMmNmNzAyZTgyZWJjNWViZTE5YmYyYWZkOWUxOGUzZDU1MzFmMWQ0ZjU3MmEwZWE5ZDJkYjM1Y...
```
when I decode that base64-encoded string, the groups parameter is passed correctly:
```plaintext
groups=trust_level_0&groups=trust_level_1&groups=trust_level_2&groups=moderatori&groups=staff&groups=Soci
```
and the values appear in the same order as in the ruby debug print above.
So it’s clear that Discourse is sending the groups array correctly !
The trouble must be on the receiving end; we are using a [modified form](https://gitlab.com/simevo/calo.news/blob/master/www/sso.php) of the [community contributed **PHP script**](https://gist.github.com/paxmanchris/e93018a3e8fbdfced039).
Turns out this code:
```php
$sso = $_GET['sso'];
$sso = urldecode($sso);
$query = [];
parse_str(base64_decode($sso), $query);
```
is not parsing the multiple **groups** fields as an array, rather it picks up the last value.
This is a [known](http://php.net/manual/it/function.parse-str.php#76792) [problem](https://stackoverflow.com/questions/6243051/how-to-pass-an-array-within-a-query-string) with PHP.
A quick fix is to make the query string compliant to what PHP expects, like this:
```plaintext
$query_string = str_replace('groups', 'groups[]', base64_decode($sso));
parse_str($query_string, $query);
```
---
### Author:  [@simevo](https://meta.discourse.org/u/simevo)
#### Post date: [2 במאי, 2018, 8:19am UTC](https://meta.discourse.org/t/use-discourse-as-an-identity-provider-sso-discourseconnect/32974/76 "2018-05-02T08:19:37Z")
Due to a recent update the workaround above is broke.
Now when I decode that base64-encoded string, the groups parameter is passed like this:
```plaintext
groups=trust_level_0%2Ctrust_level_1%2Ctrust_level_2%2Ctrust_level_3%2Ctrust_level_4%2Cmoderatori%2Cstaff%2Camministratori%2CSoci
```
The new workaround is:
```plaintext
$query_string = base64_decode($sso);
parse_str($query_string, $query);
$query['groups'] = explode(',', $query['groups']);
```
---
### Author:  [@Vaping\_Community](https://meta.discourse.org/u/Vaping_Community)
#### Post date: [18 במאי, 2018, 1:29pm UTC](https://meta.discourse.org/t/use-discourse-as-an-identity-provider-sso-discourseconnect/32974/77 "2018-05-18T13:29:02Z")
Can you add support for letter avatars ie. when a user doesn’t have an avatar, I can’t seem to get that image URL over SSO.
I am using [discourse SSO](https://meta.discourse.org/t/13045?silent=true) as the login for a PHP project with @paxmanchris code.
```
/letter_avatar_proxy/v2/letter/v/a3d4f5/120.png
```
~~I can’t seem to figure out how to logout using PHP either..~~
Figured it out
---
### Author:  [@Vaping\_Community](https://meta.discourse.org/u/Vaping_Community)
#### Post date: [19 במאי, 2018, 9:22am UTC](https://meta.discourse.org/t/use-discourse-as-an-identity-provider-sso-discourseconnect/32974/78 "2018-05-19T09:22:09Z")
Just noticed the
```
[avatar_url]
```
Has is returning an extra `/uploads/default/`
```
/uploads/default//uploads/default/original/2X/9/
```
---
### Author:  [@Vaping\_Community](https://meta.discourse.org/u/Vaping_Community)
#### Post date: [23 במאי, 2018, 12:32pm UTC](https://meta.discourse.org/t/use-discourse-as-an-identity-provider-sso-discourseconnect/32974/79 "2018-05-23T12:32:33Z")
`[avatar_url]`
Is still returning an extra `/uploads/default/` in the Avatar URL
```
/uploads/default//uploads/default/original/2X/9/
```
If you can tell me which file deals with that I can take a look?
---
### Author:  [@notriddle](https://meta.discourse.org/u/notriddle)
#### Post date: [12 ביוני, 2018, 2:09am UTC](https://meta.discourse.org/t/use-discourse-as-an-identity-provider-sso-discourseconnect/32974/80 "2018-06-12T02:09:39Z")
Added a mention that the hex string has to be lower case. Discourse compares the signature string with a lowercase hex signature; it does not decode the hex string and compare it with another decoded hex string.
---
### Author:  [@eatcodetravel](https://meta.discourse.org/u/eatcodetravel)
#### Post date: [7 בדצמבר, 2018, 11:39pm UTC](https://meta.discourse.org/t/use-discourse-as-an-identity-provider-sso-discourseconnect/32974/81 "2018-12-07T23:39:23Z")
Hello!
We are using Discourse as an SSO provider and we have the need to retrieve user custom fields as part of the payload we get from Discourse.
Is there a way to do this?
Thanks!
[Previous page](https://meta.discourse.org/t/use-discourse-as-an-identity-provider-sso-discourseconnect/32974.md?page=3)
[Next page](https://meta.discourse.org/t/use-discourse-as-an-identity-provider-sso-discourseconnect/32974.md?page=5)