I've been looking at different topics here and your docs on github, but I can't seem to find any details on running Discourse on AWS using RDS. I can see you have a "recommended" and pretty straight forward way of running Discourse with Docker and there are community AMIs as well. I am not particularly worried about how the application itself will be running, whether in a container of some sort (docker) or directly on the host. I am more worried about resilience and scalability - I'd like to run the app on stateless EC2 instances within an Autoscaling group and persisting in RDS (as PostgreSQL is supported now). Persisting on locally running PostgreSQL is flakey as instances come and go (we have Chaos Monkey killing them at random as well) and it does not scale.
Do you have an updated view or recommendation on how to go about installing Discourse on AWS using RDS?
Obviously, if there is not an answer to this, I will contribute here as part of my installation journey to achieve the setup we require.
When I try doing the 'git checkout latest-release' I get this error:
error: pathspec 'latest-release' did not match any file(s) known to git.
I'm a complete noob when it comes to any linux stuff, so I've just been following guides and using Google as a means of figuring things out as I go; I'm just not really understanding what to do to get around this problem. Thanks for any help!
Just want to let you guys know that i'm working on a sync between the gh and transifex version of the german translation files as announced in another topic.
In case of dups i prefer the transifex translation in comparison to gh. I will publish the used script if someone needs them for other translations (handwork will be needed since i don't want to write a parser myself and using yaml parsers).
Duh. Use the button/link on the ______ screen that you overlooked.
Change the title from "Poll: Foobar" to "Closed Poll: Foobar"
Close the topic.
I dunno. Good question.
I love the simplicity of the poll feature (start title with "Poll: " and include a list), but it's not clear to me how to close the poll. I searched meta.discourse.org and looked at the poll plugin, but didn't see an answer. I was assuming that I could click on something or make an edit that would show the poll with results in read-only form. It would be nice to be able to close the poll for voting without having to close the topic, since valuable discussion on the topic might continue beyond the time allotted for voting. I know the plugin is early in development, so this feature might not exist yet... or maybe I just missed it.
Maybe this just applies to @michaeld and his DiscourseHosting.com, but might as well cover all my bases.
I'm trying to put the email-in feature to the test, but something isn't working right.
I've set up my gmail in accordance with this guide and I have successfully sent an email-reply from a test user that popped up as a reply on the forum. But I am unable to create new threads, Before I started successfully receiving new threads I received the following errors:
Error 1:
This is an automated message to inform you that parsing the following incoming email failed. Please review the following message. Error - unknown encoding name - utf8
Error 2:
This is an automated message to inform you that parsing the following incoming email failed. Please review the following message. Error - ActiveRecord::Rollback
Both title and body can be artificially extended by appending <div></div>. Character entropy is still enforced properly though, after the markup has been removed from title.
This might be seens as a power user feature and frankly I quite like it, but it seems like a bug nevertheless.
I'm looking for a way to show an image, but link to something different like a video.
I can't seem to make this work with typical BB forum code, markdown or HTML.
Reason for this might be something that's not supported in one box, or maybe I just want to take more control over what is displayed and linked to... for instance just making the image much smaller or different.
EDIT: aww snap, I got it... nested markdown [](target_url)
Hi all. We're getting a weird bug on the 8tracks forums profile page, where it looks like parts of profiles are cached when navigating to a new profile from the activity feed.
In the activity feed below my profile information, I can click on other users' names to get to their profiles, so I click on SquaL. Note that my username and bio are still populating his profile info, but his photo and activity feed are correct, along with the URL at the top:
Tagging our dev @paydrobui We can't figure out what would be causing this on our end so thought we'd post here and see if it's on your end. I was able to repro this on both Chrome and Safari, even after resetting Safari.
If I use the Chrome context menu over an image and choose "Copy Image" to paste in discourse, I get huge images converted to png. As an example I'm pasting an image from discourse's blog. The original is a jpeg with 71Kb. The pasted image has 560Kb. I've seen much worse in my installation and I have all the dependencies for image_optim and image_sorcery installed. Is there a config to avoid converting to png or even disabling the copy/paste feature?
I noticed an issue with Transifex and the translation of empty string like: en.topic.notifications.title: ''
Transifex don't add this string to the translation strings, so when I export the yml, the line is not here. Maybe we need to add a rule to manage this case.
I'd like to see it be possible to subscribe to a forum for email updates and be able to unsubscribe to a particular thread while staying subscribed to a forum for email updates (either via individual emails or digest).
Also I'd like to see a subscription option of just new threads that made it easy then to follow selected new threads.
No, that's fine. I got used to PRs taking some time (not only in discourse, but in general) and you have also other things to work on. And clearly, not everything should be merged without discussion. The way the discussion turned on the other hand bothered me. Especially since it is totally unclear what will and what won't get merged into core and what the process is to figure that out.
As this was a discussion at least @codinghorror had participated in and I had before hand mention I'd want to build it. So I assumed I had a blessing for the approach taken. Obviously I was wrong.
Sure, I'm not saying this wasted time is on you. And I do understand the process better now: unless some of you previously stated publicly you want it in and you want it done that way, any time spend on it might very likely be wasted – especially if that is user facing. Fair enough. So the process then is, pinging you guys (I assume over discourse ) and wait for a blessing before putting any time towards it. Slows down progress and isn't very motivating, but sure, fine with me. (btw, I did that here, waiting to hear back .)
On a bigger scale, I (and many others) love to help and work on discourse, but from here, outside the core team, it is really hard to tell what to work on. Unless you take one of the specs you guys started creating and run with it, there is no way of knowing whether something is supposed to be a plugin, won't make it into core ever you or might actually be highly wanted for v1.0. Like the shared-edits, I wrote as a plugin and only learnt later, you'd love to have in the core (too/instead). Same goes the other way round for the email notification options.
Don't get me wrong, I do appreciate the specs and I think it is the right way to move forward, but it is also very slow as it requires a lot of time from you (from what I see, this lies with @sam only at the moment). But at least I am still missing the bigger picture. I'd highly appreciate a super rough list of features you were planning on having in v1, which ones you are working on and maybe also features you'd like to see but aren't working on. And then the community could (help) sketch those specs out together, it wouldn't be only on you and once you are happy with the spec (and gave your blessing), we can implement them without wasting our time. I think it worked quite well with Badges and we can do that with more.
Really, I'd love to help. It is just really hard to know on what to put the time at good use. So I don't even start anything bigger, though I'd love to do that.
That's why I am frustrated. Not because the PR took very long to just get rejected.
This topic is in extensibility, but it's clearly a support request. Except it's a support request for a plugin, so it's a little bit different.
I see a few options for categorization:
extensibility
support
new subcategory of support, like wordpress
Off Topic (but then, what site should it be on?)
Keep in mind that the resolution of the topic should not affect your opinion, because that isn't known when you categorize it. (It isn't known whether the problem is with the Discourse configuration or the Google-side configuration.)
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?
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:
Validate the signature, ensure that HMAC-SHA256 of sso_secret, PAYLOAD is equal to the sig
Perform whatever authentication it has to
Create a new payload with nonce, email, external_id and optionally (username, name, return_url)
Base64 encode the payload
Calculate a HMAC-SHA256 hash of the using sso_secret as the key and Base64 encoded payload as text
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:
Log the user on by looking up an already associated external_id in the SingleSignOnRecord model
Log the user on by using the email provided (updating external_id)
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.
As a Rails 3.X beginner, I'm trying to setup Discourse in an Ubuntu VPS for production.
In the database.yml page, it said
You may be surprised production is not here, it is sourced from application.rb using a monkey patch This is done for 2 reasons 1. we need to support blank settings correctly and rendering nothing in yaml/erb is a PITA 2. why go from object -> yaml -> object, pointless
How to config production database then? I checked application.rb but not sure which part to config.
bug?
.)
