4 files changed, 65 insertions, 12 deletions
diff --git a/doc/integrations/Single-Sign-On/GitHub-Enterprise.md b/doc/integrations/Single-Sign-On/GitHub-Enterprise.md
new file mode 100644
index 000000000..6f6633846
--- /dev/null
+++ b/doc/integrations/Single-Sign-On/GitHub-Enterprise.md
@@ -0,0 +1,20 @@
+## Configuring GitHub Enterprise Single-Sign-On (unofficial)
+
+Note: Because the authentication interface of GitHub Enterprise is similar to that of GitLab, the GitLab SSO feature can be used to unofficially also support GitHub Enterprise SSO.
+
+Follow these steps to configure Mattermost to use Github Enterprise as a single-sign-on (SSO) service for team creation, account creation and sign-in using the GitLab SSO interface.
+
+1. Login to your GitHub Enterprise account and go to the Applications section in Profile Settings.
+2. Add a new application called "Mattermost" with the following as Authorization callback URL:
+  * `<your-mattermost-url>` (example: http://localhost:8065)
+
+3. Submit the application and copy the given _Id_ and _Secret_ into the appropriate _GitLabSettings_ fields in config/config.json
+
+4. Also in config/config.json, set _Enable_ to `true` for the _gitlab_ section, leave _Scope_ blank and use the following for the endpoints:
+  * _AuthEndpoint_: `https://<your-github-enterprise-url>/oauth/authorize` (example https://github.com/oauth/authorize)
+  * _TokenEndpoint_: `https://<your-github-enterprise-url>/oauth/access_token`
+  * _UserApiEndpoint_: `https://<your-github-enterprise-url>/api/v3/user`
+
+5. (Optional) If you would like to force all users to sign-up with GitHub Enterprise only, in the _ServiceSettings_ section of config/config.json set _DisableEmailSignUp_ to `true`.
+
+6. Restart your Mattermost server to see the changes take effect.
diff --git a/doc/integrations/Single-Sign-On/GitHub.md b/doc/integrations/Single-Sign-On/GitHub.md
new file mode 100644
index 000000000..56e2d1c72
--- /dev/null
+++ b/doc/integrations/Single-Sign-On/GitHub.md
@@ -0,0 +1,24 @@
+## Configuring GitHub Single-Sign-On (unofficial)
+
+Note: Because the authentication interface of GitHub is similar to that of GitLab, the GitLab SSO feature can be used to unofficially also support GitHub SSO.
+
+Follow these steps to configure Mattermost to use Github as a single-sign-on (SSO) service for team creation, account creation and sign-in using the GitLab SSO interface.
+
+1. Login to your GitHub account and go to the Applications section in Profile Settings.
+2. Add a new application called "Mattermost" with the following as Authorization callback URL:
+  * `<your-mattermost-url>` (example: http://localhost:8065)
+
+3. Submit the application and copy the given _Id_ and _Secret_ into the appropriate _GitLabSettings_ fields in config/config.json
+
+4. Also in config/config.json, set _Enable_ to `true` for the _gitlab_ section, leave _Scope_ blank and use the following for the endpoints:
+  * _AuthEndpoint_: `https://github.com/login/oauth/authorize`
+  * _TokenEndpoint_: `https://github.com/login/oauth/access_token`
+  * _UserApiEndpoint_: `https://api.github.com/user`
+
+6. (Optional) If you would like to force all users to sign-up with GitHub only,
+in the _ServiceSettings_ section of config/config.json set _DisableEmailSignUp_
+to `true`.
+
+6. Restart your Mattermost server to see the changes take effect.
+
+7. Tell the users to set their public email for GitHub at the [Public profile page](https://github.com/settings/profile). Mattermost uses the email to create account.
diff --git a/doc/integrations/Single-Sign-On/Gitlab.md b/doc/integrations/Single-Sign-On/Gitlab.md
index 1242fd13e..f0acc0e66 100644
--- a/doc/integrations/Single-Sign-On/Gitlab.md
+++ b/doc/integrations/Single-Sign-On/Gitlab.md
@@ -9,7 +9,7 @@ Follow these steps to configure Mattermost to use GitLab as a single-sign-on (SS
   
   (Note: If your GitLab instance is set up to use SSL, your URIs must begin with https://. Otherwise, use http://).
 
-3. Submit the application and copy the given _Id_ and _Secret_ into the appropriate _SSOSettings_ fields in config/config.json
+3. Submit the application and copy the given _Id_ and _Secret_ into the appropriate _GitLabSettings_ fields in config/config.json
 
 4. Also in config/config.json, set _Enable_ to `true` for the _gitlab_ section, leave _Scope_ blank and use the following for the endpoints:
   * _AuthEndpoint_: `https://<your-gitlab-url>/oauth/authorize` (example https://example.com/oauth/authorize)  
diff --git a/doc/integrations/webhooks/Incoming-Webhooks.md b/doc/integrations/webhooks/Incoming-Webhooks.md
index b5ae0fde2..7373892ad 100644
--- a/doc/integrations/webhooks/Incoming-Webhooks.md
+++ b/doc/integrations/webhooks/Incoming-Webhooks.md
@@ -1,6 +1,6 @@
 # Incoming Webhooks
 
-Incoming webhooks allow external applications, written in the programming language of your choice--to post messages into Mattermost channels and private groups by sending a specifically formatted JSON payload via HTTP POST request to a secret Mattermost URL generated specifically for each application.
+Incoming webhooks allow external applications, written in the programming language of your choice--to post messages into Mattermost channels, private groups and direct messages by sending a specifically formatted JSON payload via HTTP POST request to a secret Mattermost URL generated specifically for each application.
 
 A couple key points:
 
@@ -69,7 +69,7 @@ Additional Notes:
 
 1. For the HTTP request body, if `Content-Type` is specified as `application/json` in the headers of the HTTP request then the body of the request can be direct JSON. For example, ```{"text": "Hello, this is some text."}```
 
-2. You can override the channel specified in the webhook definition by specifying a `channel` parameter in your payload. For example, you might have a single webhook created for _Town Square_, but you can use ```payload={"channel": "off-topic", "text": "Hello, this is some text."}``` to send a message to the _Off-Topic_ channel using the same webhook URL
+2. You can override the channel specified in the webhook definition by specifying a `channel` parameter in your payload. For example, you might have a single webhook created for _Town Square_, but you can use ```payload={"channel": "off-topic", "text": "Hello, this is some text."}``` to send a message to the _Off-Topic_ channel using the same webhook URL. If an `@` symbol followed by a username is specified, then the message will be sent to that user's direct message channel
 
 1. In addition, with **Enable Overriding of Usernames from Webhooks** turned on,  you can also override the username the message posts as by providing a `username` parameter in your JSON payload. For example, you might want your message looking like it came from a robot so you can use ```payload={"username": "robot", "text": "Hello, this is some text."}``` to change the username of the post to robot. Note, to combat any malicious users from trying to use this to perform [phishing attacks](https://en.wikipedia.org/wiki/Phishing) a `BOT` indicator appears next to posts coming from webhooks
 
@@ -81,18 +81,27 @@ Additional Notes:
 
 ### Slack Compatibility
 
-As mentioned above, Mattermost makes it easy to take integrations written for Slack's proprietary JSON payload format and repurpose them to become Mattermost integrations. The following automatic translations are supported:
+Mattermost makes it easy to take integrations written for Slack's proprietary JSON payload format and repurpose them to become Mattermost integrations. For example:
+
+#### Connecting Mattermost to GitLab using Slack UI 
+
+GitLab is the leading open-source alternative to GitHub and offers built-in integrations with Slack. Rather than having to change code to support Mattermost, users can add Mattermost webhooks directly into the interface for Slack. 
+
+1. In GitLab, go to **Settings** > **Services** and select **Slack**.
+2. Paste in the incoming webhook URL provided by Mattermost from under **Account Settings** > **Integration** > **Incoming Webhooks**.
+3. Optionally set the **Username** you'd like displayed when the notification is made. Leave the **Channel** field blank
+4. Click **Save** then test the settings to confirm posts will be made to Mattermost
+
+#### Translating Slack's proprietary data format to Mattermost 
+
+The following describes the automatic translations Mattermost performance to process data coming from Slack: 
 
 1. Payloads designed for Slack using `<>` to note the need to hyperlink a URL, such as ```payload={"text": "<http://www.mattermost.com/>"}```, are translated to the equivalent markdown in Mattermost and rendered the same as you would see in Slack
 2. Similiarly, payloads designed for Slack using `|` within a `<>` to define linked text, such as ```payload={"text": "Click <http://www.mattermost.com/|here> for a link."}```, are also translated to the equivalent markdown in Mattermost and rendered the same as you would see in Slack
-3. Like Slack, by overriding the channel name with an @username, such as payload={"text": "Hi", channel: "@jim"}, you can send the message to a user through your direct message chat
-4. Channel names can be prepended with a #, like they are in Slack incoming webhooks, and the message will still be sent to the correct channel
+3. Like Slack, by overriding the channel name with a `@username`, such as `payload={"text": "Hi", channel: "@jim"}`, you can send the message to a user through your direct message chat
+4. Channel names can be prepended with a `#`, like they are in Slack incoming webhooks, and the message will still be sent to the correct channel
 
 To see samples and community contributions, please visit <http://mattermost.org/webhooks>.
 
-#### Known Issues in v1.1
-
-- The `attachments` payload used in Slack is not yet supported
-- Overriding of usernames does not yet apply to notifications (fixed on master) 
-- Cannot supply `icon_emoji` to override the message icon
-- Webhook UI fails when connected to deleted channel (fixed on master)
+#### Known Issues
+- Mattermost does not yet support Slack's feature of using _icon_emoji_ to override the message icon.