Sam Saffron wrote:

Continuing the discussion from Styling the dang filter buttons:

I would like to offer our official position here.

The site customisation system is always going to be the only preferred, recommended and supported way of styling sites. It supports SCSS. We make no use of !important rules in our base stylesheets, the custom stylesheet shows up last in the cascade, everything can be overridden.

@awesomerobot used this system with great success to style http://discuss.howtogeek.com .

We have had bugs in the past in this system, any bugs you encounter need to be reported so we can resolve them.

If our current theming system lacks flexibility needed I would be happy to add more hooks and features (or accept PRs)

If you depart from using this, you are risking a world of pain. When we refactor our base CSS you are going to be stuck with an impossible merge. Upgrade is not going to be smooth. Debugging through issues you introduced is going to be WAY more complicated.

Posts: 7

Participants: 4

Read full topic

JP Gordon wrote:

Trying to create a post in the New Relic subcat and keep getting this error:

Posts: 6

Participants: 2

Read full topic

Lupine wrote:

Hi all,

One other requirement my league has is for an application people can install on their phones to get push notifications when posts are made to the forum, or they get PMs. Obviously, the intent for discourse is "good enough on mobile so no applications are required", but as far as I know, there isn't a mechanism to get facebook-style push notifications without one...

So I'm currently implementing a Tapatalk Discourse bridge. Previous threads have suggested core is quite hostile to this (and, honestly, deservedly so - this XMLRPC interface is evil), so I'm doing it as a service that runs in a separate process, consuming the discourse_api library. Which is skeletal, to say the least

Anyway, one night of hacking means I can view topics on my android mobile, using the "forum fiend" application. The code for it is at https://github.com/lupine/tapatalker - completely unorganised at the moment, I just wanted to get something running. Hopefully, I can get basic push notifications working by the end of the week... before insanity sets in

Posts: 16

Participants: 6

Read full topic

James Potter wrote:

Took a while to get this working, but I have this successfully running in production, with a Discourse instance hosted on a separate subdomain.

First add the SSO secret key (configured in the Discourse admin panel) and the base URL for your instance to your settings.py:

DISCOURSE_BASE_URL = 'http://your-discourse-site.com'
DISCOURSE_SSO_SECRET = 'paste_your_secret_here'

Now add a new app called discourse to your project and paste this into views.py:

import base64
import hmac
import hashlib
import urllib

from django.contrib.auth.decorators import login_required
from django.http import HttpResponseBadRequest, HttpResponseRedirect
from django.conf import settings

@login_required
def sso(request):
    payload = request.GET.get('sso')
    signature = request.GET.get('sig')

    if None in [payload, signature]:
        return HttpResponseBadRequest('No SSO payload or signature.')

    ## Validate the payload

    try:
        payload = urllib.unquote(payload)
        assert 'nonce' in base64.decodestring(payload)
        assert len(payload) > 0
    except AssertionError:
        return HttpResponseBadRequest('Invalid payload..')

    key = settings.DISCOURSE_SSO_SECRET
    h = hmac.new(key, payload, digestmod=hashlib.sha256)
    this_signature = h.hexdigest()

    if this_signature != signature:
        return HttpResponseBadRequest('Payload does not match signature.')

    ## Build the return payload

    params = {
        'nonce': base64.decodestring(payload).split('=')[1],
        'email': request.user.email,
        'external_id': request.user.id,
        'username': request.user.username
    }

    return_payload = base64.encodestring(urllib.urlencode(params))
    h = hmac.new(key, return_payload, digestmod=hashlib.sha256)
    query_string = urllib.urlencode({'sso': return_payload, 'sig': h.hexdigest()})

    ## Redirect back to Discourse

    url = '%s/session/sso_login' % settings.DISCOURSE_BASE_URL
    return HttpResponseRedirect('%s?%s' % (url, query_string))

Then you'll need to add a route in urls.py, like this:

from my_project.apps.discourse import views

urlpatterns = patterns('',
    url(r'^discourse/sso$', views.sso),
)

And bobs your uncle.

Posts: 1

Participants: 1

Read full topic

Oleander wrote:

Like the title says; that's the name of the queue being used by Discourse in sidekiq?

Posts: 2

Participants: 2

Read full topic

Sam Saffron wrote:

Discourse now ships with official hooks to perform auth offsite.

The Problem

Many sites wish to integrate with a Discourse site, however want to keep all user registration in a separate site. In such a setup all Login operations should be outsourced to a different site.

What if I would like SSO in conjunction with existing auth?

The intention around SSO is to replace Discourse authentication, if you would like to add a new provider see existing plugins such as: https://meta.discourse.org/t/vk-com-login-vkontakte/12987

Enabling SSO

To enable single sign on you have 3 settings you need to fill out:

Pasted image798x240 16.8 KB

enable_sso : must be enabled, global switch
sso_url: the offsite URL users will be sent to when attempting to log on
sso_secret: a secret string used to hash SSO payloads. Ensures payloads are authentic.

Once enable_sso is set to true:

• Clicking on login or avatar will, redirect you to /session/sso which in turn will redirect users to sso_url with a signed payload.
• Users will not be allowed to "change password". That field is removed from the user profile.
• Users will no longer be able to use Discourse auth (username/password, google, etc)

What if you check it by mistake?

If you check enable_sso by mistake and need to revert to the original state and no longer have access to the admin panel

run:

RAILS_ENV=production bin/rails c
irb > SiteSetting.enable_sso = false

Implementing SSO on your site

Discourse will redirect clients to sso_url with a signed payload: (say sso_url is https://somesite.com/sso)

You will receive incoming traffic with the following

https://somesite.com/sso?sso=PAYLOAD&sig=SIG

The payload is a Base64 encoded string comprising of a nonce. The payload is always a valid querystring.

For example, if the nonce is ABCD. raw_payload will be:

nonce=ABCD, this raw payload is base 64 encoded.

The endpoint being called must

1. Validate the signature, ensure that HMAC 256 of sso_secret,PAYLOAD is equal to the sig
2. Perform whatever authentication it has to
3. Create a new payload with nonce, email, external_id and optionally (username, name, return_url)
4. Base64 encode the payload
5. Calculate a HMAC 256 hash of the using sso_secret as the key and Base64 encoded payload as text
6. Redirect back to http://discourse_site/session/sso_login?sso=payload&sig=sig

Discourse will validate that the nonce is valid (if valid it will expire it right away so it can no longer be used) it will attempt to:

1. Log the user on by looking up an already associated external_id in the SingleSignOnRecord model
2. Log the user on by using the email provided (updating external_id)
3. Create a new account for the user providing (email, username, name) updating external_id

Security concerns

The nonce (one time token) will expire automatically after 10 minutes. This means that as soon as the user is redirected to your site they have 10 minutes to log in / create a new account.

The protocol is safe against replay attacks as nonce may only be used once.

Reference implementation

Discourse contains a reference implementation of the SSO class:

A trivial implementation would be:

class DiscourseSsoController < ApplicationController
  def sso
    secret = "MY_SECRET_STRING"
    sso = SingleSignOn.parse(request.query_string, secret)
    sso.email = "user@email.com"
    sso.name = "Bill Hicks"
    sso.username = "bill@hicks.com"
    sso.external_id = "123" # unique to your application
    sso.sso_secret = secret

    redirect_to sso.to_url("http://l.discourse/session/sso_login")
  end
end

Transitioning to and from single sign on.

The system always trusts emails provided by the single sign on endpoint. This means that if you had an existing account in the past on Discourse with SSO disabled, SSO will simply re-use it and avoid creating a new account.

If you ever turn off SSO, users will be able to reset passwords and gain access back to their accounts.

Future work

• We would like to gather more reference implementations for SSO on other platforms. If you have one please post to the Extensibility / SSO category.

• Add session expiry and/or revalidation logic, so users are not logged in forever.

• Create an API endpoint to log off users, in case somebody logs off the main site.

• Consider adding a discourse_sso gem to make it easier to implement in Ruby.

Updates:

2-Feb-2014

• use HMAC 256 instead of SHA256. This is more secure and cleanly separates key from payload.
• removed return_url, the system will automatically redirect users back to the page they were on after login

Posts: 20

Participants: 5

Read full topic

Stefan wrote:

Hello! I'm interested in having a social group functionality for Discourse that needs to work like this:

• every member can open a new group or join an exiting group;
• a group can be public (everybody can read and members can post), private (only members can read/post), exclusive (same as private but you can only join if you are invited);
• the group owner can moderate the content on it's own group;
• trust levels per group;
• invite to group functionality;
• per group categories that can be watched, tracked or muted.

Please send me a time and money estimate if you are interested in doing this.

Thanks!

Posts: 1

Participants: 1

Read full topic

Kieran Tracy wrote:

I've just noticed my automated backups started failing (about a week ago, by the date stamps.)

When I try a manual backup, I get the following error:

...
[2014-03-28 12:11:01] Updating dump for more awesomeness...
[2014-03-28 12:11:02] Creating archive: a-thoroughly-modern-void-2014-03-28-121100.tar.gz
[2014-03-28 12:11:02] Making sure archive does not already exist...
[2014-03-28 12:11:02] Creating empty archive...
[2014-03-28 12:11:02] Archiving metadata...
[2014-03-28 12:11:02] Archiving data dump...
[2014-03-28 12:11:02] Archiving uploads...
[2014-03-28 12:11:02] Gzipping archive...
[2014-03-28 12:11:02] Executing the after_create_hook for the backup
[2014-03-28 12:11:02] EXCEPTION: No such file or directory - /var/www/discourse/public/backups/default/a-thoroughly-modern-void-2014-03-28-121100.tar.gz
...

I can post more of the log if needed, but this seems to be the relevant bit.

I've been dutifully upgrading via /admin/docker at least once a day.

I'm going to try bootstrapping again a little later, but wondered if anyone had seen anything similar. It almost looks like a path issue - is the docker public/ the same as shared/ on the host?

Posts: 2

Participants: 1

Read full topic

Bernardo Kuri wrote:

I am currently seriously considering the possibility of merging two vbulletin forums into a shiny new discourse forum. It seems that DiscourseHosting might be able to help me with importing threads from at least one of those forums, so I should be OK in that respect.

I guess my actual question is: how would someone deal with overlapping users if I were to merge two forums together? Could I simply create discourse user accounts with tags or badges containing their old user names?

Finally, is there anything else that I should look out for if I go through with this?

Thanks in advance!

Posts: 3

Participants: 2

Read full topic

gsnow2k wrote:

First of all, I think Discourse is very nicely done. But I am wondering why Ruby on Rails and PostgreSQL were chosen as the framework and database server for Discourse.

What's the advantage of using Ruby, vs. using PHP, or Python? Why use Postgre, instead of MySQL? What's the long-term outlook of Ruby on Rails and Postgre? Can they keep up or outgrow other programming platforms?

Or, why not go with the .Net stack, using MVC and SqlServer? The debugging experience on .Net seems to be much more superior than the current choice, not mentioning the benefit of executing the compiled code.

As a new user to Discourse, I am just curious.

Posts: 2

Participants: 2

Read full topic

Arpit Jalan wrote:

The Discourse Docker Image makes it easy to set up Discourse on a cloud server. We will use Digital Ocean, although these steps will work on other similar services.

This guide assumes that you have no knowledge of Ruby/Rails or Linux shell. Feel free to skip steps you are comfortable with.

Create New Digital Ocean Droplet

Discourse requires a minimum of 1 GB RAM, however 2 GB RAM is strongly recommended. We'll use "discourse" as the Hostname.

Pasted image690x540 100 KB

Install Discourse on Ubuntu 12.04.3 LTS x64. We always recommend using the current LTS distribution.

digital-ocean-ubuntu.png867x600 45.8 KB

You will receive a mail from Digital Ocean with the root password to your Droplet. (However, if you use SSH keys, you may not need a password to log in.)

Access Your Droplet

Connect to your Droplet via SSH:

ssh root@192.168.1.1

(Alternately, use Putty on Windows)

Replace 192.168.1.1 with the IP address of your Droplet.

You will be asked for permission to connect, type yes, then the root password, which is in the email Digital Ocean sent you when the Droplet was set up. Enter it.

Install Git

apt-get install git

Generate SSH Key

We strongly recommend setting a SSH key because you may need to access the Rails console for debugging purposes. This cannot be done after bootstrapping the app.

ssh-keygen -t rsa -C "your_email@example.com"

(We want the default settings, so when asked to enter a file in which to save the key, just press enter. Via GitHub's SSH guide.)

Install Docker

apt-get update
apt-get install linux-image-generic-lts-raring linux-headers-generic-lts-raring

Reboot the server:

reboot

This will log you out from your SSH session, so reconnect:

ssh root@192.168.1.1

Finish installing Docker:

wget -qO- https://get.docker.io/ | sh

Install Discourse

Create a /var/docker folder where all the Docker related stuff will reside:

mkdir /var/docker

Clone the Official Discourse Docker Image into this /var/docker folder:

git clone https://github.com/discourse/discourse_docker.git /var/docker

Switch to your Docker folder:

cd /var/docker

Copy the samples/standalone.yml file into the containers folder as app.yml, so the path becomes containers/app.yml:

cp samples/standalone.yml containers/app.yml

Edit app.yml:

nano containers/app.yml

(We recommend Nano because it works like a typical GUI text editor, just use your arrow keys. Hit CtrlO then Enter to save and CtrlX to exit. However, feel free to choose whatever text editor you like. In the below screenshot we use Vim.)

Edit as desired, but at minimum set DISCOURSE_DEVELOPER_EMAILS and DISCOURSE_HOSTNAME.

We renamed DISCOURSE_HOSTNAME to discourse.techapj.com, this means that we want to host our instance of Discourse on http://discourse.techapj.com/. You'll need to modify your DNS records to reflect the IP address and preferred URL address of your server.

Mail Setup

Email is critical to Discourse. We strongly recommend configuring mail settings before bootstrapping.

• If you already have a mail server, put your existing mail server credentials in the app.yml file.

• Otherwise, create a free account on Mandrill (or Mailgun, or Mailjet), and put your mail credentials (available via the Mandrill dashboard) in the app.yml file. The settings you want to change are DISCOURSE_SMTP_ADDRESS, DISCOURSE_SMTP_PORT, DISCOURSE_SMTP_USER_NAME, DISCOURSE_SMTP_PASSWORD.

• Be sure you remove the comment character # from the beginning of these mail configuration lines!

Add Your SSH Key

If you successfully generated the SSH key as described earlier, get it:

cat ~/.ssh/id_rsa.pub

Copy the entire output and paste it into the ssh_key setting in the app.yml file.

Bootstrap Discourse

Be sure to save the app.yml file, and begin bootstrapping Discourse:

./launcher bootstrap app

This command may take some time, so be prepared to wait. It is automagically configuring your Discourse environment.

After that completes, start Discourse:

./launcher start app

Congratulations! You now have your own instance of Discourse, accessible via the domain name you entered in app.yml earlier.

Pasted image1273x538 88.5 KB

You can also access it by visiting the server IP address directly, e.g. http://192.168.1.1.

Log In and Become Admin

Sign into your Discourse instance. If you configured DISCOURSE_DEVELOPER_EMAILS and your email matches, your account will be made Admin by default.

If your account was not made admin, try SSH'ing into your container (assuming you entered your SSH key in the app.yml file):

./launcher ssh my_container
sudo -iu discourse
cd /var/www/discourse
RAILS_ENV=production bundle exec rails c
u = User.last
u.admin = true
u.save

This will manually make the first user an admin.

Post-Install Maintenance

We believe most small and medium size Discourse installs will be fine with the recommended 2 GB of RAM. However, if you are using the absolute minimum 1 GB of RAM, or your forum is growing you may want to set up a swap file just in case.

To upgrade Discourse to the latest version, visit /admin/docker, refresh the page a few times (yes, seriously) and then press the Upgrade button at the top. View the live output at the bottom of your browser to see when things are complete. You should see:

Killed sidekiq
Restarting unicorn pid: 37

Then you know it's complete. (Yes, we will be improving this process soon!)

If anything needs to be improved in this guide, feel free to ask on meta.discourse.org, or even better, submit a pull request.

Posts: 169

Participants: 38

Read full topic

Sam Saffron wrote:

Continuing the discussion from So, you want to help out with Discourse:

Almost all forum software out there supports "polls". They can be quite fun and allow you to easily gauge what people like / dislike.

@Hunter was asking for some sort of spec of how I would see this work, so here I go.

• Polls should be designed as a standalone plugin. This important cause it ensures our extensibility story is solid and allows us, further down the line, to upgrade poll functionality outside of core releases.

• I think polls should simple be an extension of markdown that only applies on the first post in a topic. Eg:

  <poll>
  - This is the first option
  - This is the second option
  - This is the third option
  </poll>

• Initial implementation should only allow one vote per option.

• Initial implementation should not allow for anonymous voting.

• Choices must be locked in after 5 minutes

• On initial render it should not display the results, you must either vote or click on "show results" to see them.

• Initial implementation does not need to worry about randomising options on first view

• Data for the polls should be stored in Topic or Post meta_data (an hstore column) or in PluginStore, a custom migration in a plugin is a major work to undertake which we can skip for now.

• Controller to receive voting should be registered by the plugin using a rails engine, example is my blog https://github.com/samsaffron/blog

Questions / ideas?

I would like to keep the first go at this rather simple with minimal features.

Posts: 64

Participants: 27

Read full topic

He Yiheng wrote:

i visit http://forum.example.com/admin/docker and try to upgrade, only one line comment display in Log:
$ cd /var/www/discourse/plugins/docker_manager && git fetch && git reset --hard HEAD@{upstream}

Posts: 1

Participants: 1

Read full topic

Ying Long wrote:

A poll is identified by its title prefix.
So if the prefix is configured as "aaa:" in one language, and "bbb:" in another, topic titled as "aaa: a new poll" will not be shown as a poll in the later.
It is terrible in multiple language forum.

Posts: 1

Participants: 1

Read full topic

Mikulas Dite wrote:

Creating a post (or pm) with the following link results in e500:
https://www.khanacademy.org/science/health-and-medicine/circulatory-system-diseases/heart-disease-and-stroke/v/strokes

Editing an existing post by adding this links fails silently, seemingly updating the post but failing to persist.

Started POST "/posts" for 79.98.75.249 at 2014-03-29 11:23:21 +0100
Processing by PostsController#create as */*
  Parameters: {"raw"=>"https://www.khanacademy.org/science/health-and-medicine/circulatory-system-diseases/heart-disease-and-stroke/v/strokes\n", "reply_to_post_number"=>"", "archetype"=>"private_message", "title"=>"https://www.khanacademy.org/science/health-and-medicine/circulatory-system-diseases/heart-disease-and-stroke/v/strokes", "target_usernames"=>"system", "auto_close_time"=>""}
Completed 500 Internal Server Error in 309ms

EOFError (end of file reached):
  lib/oneboxer.rb:36:in `cached_onebox'
  app/models/post_analyzer.rb:16:in `block in cook'
  lib/oneboxer.rb:76:in `block in apply'
  lib/oneboxer.rb:62:in `block in each_onebox_link'
  lib/oneboxer.rb:60:in `each_onebox_link'
  lib/oneboxer.rb:75:in `apply'
  app/models/post_analyzer.rb:14:in `cook'
  app/models/post_analyzer.rb:104:in `cooked_document'
  app/models/post_analyzer.rb:49:in `raw_mentions'
  app/models/post.rb:129:in `block (2 levels) in <class:Post>'
  lib/validators/post_validator.rb:38:in `max_mention_validator'
  lib/validators/post_validator.rb:9:in `validate'
  lib/post_creator.rb:216:in `save_post'
  lib/post_creator.rb:60:in `block in create'
  lib/post_creator.rb:56:in `create'
  app/controllers/posts_controller.rb:36:in `block in create'
  lib/distributed_memoizer.rb:28:in `memoize'
  app/controllers/posts_controller.rb:34:in `create'
  lib/middleware/anonymous_cache.rb:104:in `call'
  config/initializers/quiet_logger.rb:10:in `call_with_quiet_assets'
  config/initializers/silence_logger.rb:19:in `call'

Posts: 1

Participants: 1

Read full topic

Rikki Tooley wrote:

Is there any way to use the current category's colour in the site theming just using CSS? Like an SCSS variable or a class or something?

Posts: 2

Participants: 2

Read full topic

Sam Saffron wrote:

I just rolled out a template that "enables SSL" for your Docker based setup.

I would like to cover configuration here:

This guide assumes your container configuration file is /var/docker/containers/standalone.yml and that discourse docker is installed at: /var/docker

Step 1

Go to namecheap or some other SSL cert provider and purchase a SSL cert for your domain. Follow all the step documented by them to generate private key and CSR and finally get your cert. I used the apache defaults, they will work fine.

Keep your private key and cert somewhere safe.

Step 2

Get a signed cert and key and place them in the /var/docker/shared/ssl/ folder

Private key is:

/var/docker/shared/ssl/ssl.key

Cert is

/var/docker/shared/ssl/ssl.crt

File names are critical do not stray from them or your nginx template will not know where to find the cert.

Step 3

Add a reference to the nginx ssl template from your application yml configuration file:

templates:
  - "templates/cron.template.yml"
  - "templates/postgres.template.yml"
  - "templates/redis.template.yml"
  - "templates/sshd.template.yml"
  - "templates/web.template.yml"
  - "templates/web.ssl.template.yml"

Step 4

Tell your container to listen on SSL

expose:
  - "80:80"
  - "2222:22"
  - "443:443"

Step 5

Rebootstrap your image

./launcher destroy standalone
./launcher bootstrap standalone
./launcher start standalone

Step 6

Profit, you are done.

Troubleshooting

Be sure to read through the logs using

./launcher logs standalone

If anything goes wrong.

How this works

The template used is vaguely based on @igrigorik's recommended template with two missing bits:

• I disabled SPDY now until we upgrade the base image to NGINX 1.4.7 due to a buffer overflow in 1.4.6 (I am considering changing our base image to use mainline NGINX - at least optionally)
• I skipped OSCP stapling cause it involves a slightly more complex setup
• I had to skip session tickets setting which is not available until we use mainline

The image has rewrite rules that will redirect any requests on either port 80 or 443 to https://DISCOURSE_HOST_NAME , meaning that if you have a cert that covers multiple domains they can all go to a single one.

Customising this setup is very easy, see:

You can make a copy of that file and amend the template as needed.

The advantage of using templates and replace here is that we get to keep all the rest of the Discourse recommended NGINX setup, it changes over time.

Enjoy!

Posts: 9

Participants: 6

Read full topic

Gauri Singh wrote:

I want to add a one condition in post.handler like -

{{if post_number==1}}
      <h3 class="full-name">Testing</h3>
{{/if}}

It is correct ?

Posts: 2

Participants: 2

Read full topic

Ioann wrote:

Continuing the discussion from Beginners Guide to Deploy Discourse on Digital Ocean using Docker:

So I've successfully installed and launched Discourse. Now I have few questions:

1. Where I can find Discourse files? What folder?
2. How can I stop/reboot/launch it?
3. How can I setup mail?
4. How can I upgrade Discourse?

Maybe all this questions are stupid, but people like me is the most part of all forum admins in the web =/

P.S. Docker method of installing is so freaky simple that looks like WordPress-style no more needed.

Posts: 15

Participants: 6

Read full topic

The Dark Wizard wrote:

Trying to setup a category where users can only see their own threads, and admin can see all. What combination of permissions would this be?

You know like a "Contact Admins" section.

Posts: 3

Participants: 2

Read full topic