Alexandre Angelim wrote:
I'd like to propose exposing like and favorite buttons to everyone as an incentive to signups.
I've just came upon the project and I have no data to support that this is beneficial, other than that a lot of famous sites do it, like Youtube and Stackoverflow.
I believe that If someone is willing to show appreciation for finding helpful content, he would be more inclined to sign up to let the author knows he helped someone.
What do you think?
Posts: 2
Participants: 2
David García-Navas wrote:
So, could we upload an image stored on our Android phone or iPhone?
I only see this:...but how do i drag or paste on a little mobile device?
Is it a planned feature?
Posts: 13
Participants: 9
Leung Aaron wrote:
This is a really important feature... Users should be able to upload pictures when they are using their smartphones, no matter they post new threads or reply to other threads, or between PMs.
Posts: 3
Participants: 2
Lowell Heddings wrote:
We have a user on the HTG forum who decided that they hated all of their old posts... and has gone on a deleting spree, which leaves weird holes in topics, and then keeps pushing old topics to the first page for no reason.
The problem is that by default all posts can be edited or deleted for up to 1 year... and while sure, I can change that default (and already did), it also means that other useful forum members can't do any editing after the much shorter window that I imposed.
My idea is that the delete window should be tied to the trust level. So level 1 users would only have a shorter window for editing and deleting, and as the trust level increases, they would have more ability to edit older posts.
It's not a critical feature, but it does seem like something logical that might be included at some point.
Posts: 6
Participants: 3
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:
enable_sso: must be enabled, global switchsso_url: the offsite URL users will be sent to when attempting to log onsso_secret: a secret string used to hash SSO payloads. Ensures payloads are authentic.Once
enable_ssois set to true:
- Clicking on login or avatar will, redirect you to
/session/ssowhich in turn will redirect users tosso_urlwith 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_ssoby mistake and need to revert to the original state and no longer have access to the admin panelrun:
RAILS_ENV=production bin/rails c irb > SiteSetting.enable_sso = falseImplementing SSO on your site
Discourse will redirect clients to
sso_urlwith a signed payload: (say sso_url ishttps://somesite.com/sso)You will receive incoming traffic with the following
https://somesite.com/sso?sso=PAYLOAD&sig=SIGThe 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
- Validate the signature, ensure that HMAC 256 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 256 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=sigDiscourse 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 endTransitioning 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: 19
Participants: 4
Kane York wrote:
Mock: https://meta.discourse.org/uploads/default/3922/e4f815b6c21508f7.png
Someone asked recently about a list of features in Discourse. Well, I was having a discussion with someone else about Discourse and the forum FAQ came up.
The phpBB default FAQs look like this: http://tasvideos.org/forum/faq.php#14
Now, these aren't frequently asked questions - it's really a usage guide. A usage guide would suffice for a list of the features.
We should have a usage guide, too - just don't name it FAQ. Name it "Usage Guide".
I would want it to cover what the
button is able to do, what
means, and yes - how to create a topic.
What the "Your topic is similar to..." popup means.
How to invite more people to a private message.
A glimpse of what the admins see when you flag a topic.
So - a guide for basic and advanced usage of Discourse.
Although the best way to use it is to type paragraphs
Posts: 1
Participants: 1
Alexandre Angelim wrote:
I've noticed that Discourse has some flexibility to customize stylesheets and headers, but I'd like to know how developer oriented admins are doing when they feel the need to hook up HTML snippets in a certain point/container.
I'm a SpreeCommerce (http://guides.spreecommerce.com/developer/view.html) user and they came with a simple enough solution to use Deface (https://github.com/spree/deface) in order to allow template customization. The idea is to insert hooks in html elements making it easier for the developer to reach them and attach whatever he wants before, after, inside or around it.
I know the bulk of templates is being done using handlebars for ember, but I don't think it would invalidate the method with minor tweaks. If we find a way to override those views before handlebars is compiled, we'd be ok.
The overrides are done in separate files in a non obtrusive manner, so core updates wouldn't cause conflict(at least not a lot).
I understand this project doesn't preach forking, as SpreeCommerce does, but I think it would be a good first step to allow discourse forums to differentiate themselves. It would also create incentives for third-party companies to work in project customizations.
Posts: 3
Participants: 2
Michael wrote:
I've tried long and hard to figure this out on my own before posting on here so I apologize in advance if this is easy. I'm still new to Rails but know my way around it.
I already have an existing Rails application running. I'm adding Discourse as a second Rails application and followed the guide for Docker. I'm up to the point where I need to run ./launcher start app. However in doing so I get the following error.
Error: Cannot start container d9541419a93f: listen tcp 0.0.0.0:80: bind: address already in use 2014/03/20 22:18:08 Error: failed to start one or more containersI'm assuming that I need to configure my nginx for this to work properly, correct? So I copied over /etc/nginx/sites-available/arsiamons.io to /etc/nginx/sites-available/forums.arsiamons.io. Here's what I got in there
upstream unicorn { server unix:/tmp/unicorn.discourse.sock fail_timeout=0; } server { listen 5000 deferred; server_name forums.arsiamons.io; root /var/www/discourse/public; location ^~ /assets/ { gzip_static on; expires max; add_header Cache-Control public; } try_files $uri/index.html $uri @unicorn; location @unicorn { proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header Host $http_host; proxy_redirect off; proxy_pass http://unicorn; } error_page 500 502 503 504 /500.html; client_max_body_size 4G; keepalive_timeout 10; }If helps here's what I have inside the arsiamons.io file
upstream unicorn { server unix:/tmp/unicorn.arsiamons.sock fail_timeout=0; } server { listen 80 default deferred; server_name arsiamons.io www.arsiamons.io; root /home/skylab/apps/arsiamons/current/public; location ^~ /assets/ { gzip_static on; expires max; add_header Cache-Control public; } try_files $uri/index.html $uri @unicorn; location @unicorn { proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header Host $http_host; proxy_redirect off; proxy_pass http://unicorn; } error_page 500 502 503 504 /500.html; client_max_body_size 4G; keepalive_timeout 10; }As a basic guide for myself, I usually follow these steps to get my Rails apps going.
What am I missing exactly? Your help is greatly appreciated. Thanks!
Posts: 8
Participants: 5
Evaryont wrote:
The install guide doesn't currently tell you how to start the Discourse docker image at boot. (My VPS provider had a momentary hiccup and had to reboot my node. It came up, but Discourse didn't.)
Anyone have a convenient init script?
Posts: 5
Participants: 3
Sander Datema wrote:
I was wondering what to enter in app.yml to get it to support multisite. And will the
/admin/dockerscript migrate the multisite databases as well?
Posts: 3
Participants: 3
Daniel Watkins wrote:
This seems like a separate issue from the UTF-8 URL Problem ტესტი that @Giorgi was seeing, so I've split it out to a separate topic:
Posts: 2
Participants: 2
Ted Strauss wrote:
I'm looking for an overview of privacy, privilege, & trust features in Discourse.
This would be an overall description of how an admin can control and restrict what users are allowed to see. I looked on the main Discourse site and was surprised to find very little about this.
It would be especially helpful if this information was organized into (1) how these features work out of the box, (2) what is the range of configuration options, and (3) bleeding edge features, if any.
There are a lot of posts looking into specific features. Maybe as a first step i'll compile some of those below.
Posts: 5
Participants: 4
Marco Ceppi wrote:
There's been some recent confusion as to who did what on our Discourse install. I wasn't able to determine if there was or not, but having a way to see what actions a moderator has taken against a user (similar to edits on a post, etc) would be helpful to build an audit log to verify facts and settle disputes.
Posts: 7
Participants: 5
Will wrote:
What I mean by this is that it would be nice to be able to distinguish whether an admin or mod is participating in a conversation as a regular user or in their official capacity. It looks like this sort of functionality is half-way there; I imagine this looking graphically something like the way "Topic Lock" messages or "This topic is now pinned" messages are displayed with a colored background when the mod or admin to denote that this is "Word From On High" as opposed to the opinion of a site user who happens to be a mod.
I imagine the UI for this might be some kind of megaphone button that would also tint the background of the post editor. (Or, using font-awesome, fa-bullhorn. Maybe fa-bell or fa-gavel.)
Posts: 1
Participants: 1
Briancguy wrote:
I want to request fewer features.
I know that most discourse forums so far are probably engineer / technically focused (at least as far as the admins and I suspect many of the users - if the early beta sites are any indication). The downside of this is that I think Discourse is more complex in some areas than it needs to be for widespread adoption.
Here is the screen shot of my forum dashboard after 3 months of use. My users are virtually all non-technical, at a health-related web site - the type of site that I think is much more representative of the broader user base than the main Discourse beta sites so far.
I recommend Discourse deprecate / remove the features of "Starred" and "Bookmark" because I don't think many regular users are going to use them and they make the interface more complex than it needs to be (which hurts adoption, and use of the forum software).
I know in startups that there is a strong tendency for feature creep - and that you are continually bombarded by new feature requests, and that the most feature requests frequently come from the more technical users. My recommendation to the discourse team is to try to get in better touch with the non-technical users because success with that user base is what will really drive successful adoption for the platform.
Posts: 11
Participants: 7
Mike wrote:
I've upgraded a couple times already in the past. I believe I ended up upgrading twice today though. The first time seemed successful then later I saw the upgrade button was still there, so clicked it again and am now getting a 502 bad gateway nginx error.
I did try doing a launcher destroy, bootstrap, and start app, but am still getting the error.
Any tips on where I can look to see what the problem is?
Posts: 5
Participants: 3
Patrick Burrows wrote:
Continuing the discussion from Using discourse as blog software:
I agree that making it "the blog" is a bad idea.
But making it the blog's comment engine is not (have a discourse thread at the bottom of the page) Especially for sites which have both comments AND forums.
It would allow for users to use the same account for article comments and forum posts.
It would allow users to have a single profile page to go to and see responses to posts both in forums and in article comments.
Posts: 24
Participants: 12
J Steiner wrote:
I run a private, invite-only forum, and have my security settings set like this:
And when I click on an active user's name, or even the "Admin" link in the dropdown from my avatar, this is all I see:I can view the admin screen for users who've not yet been approved, interestingly enough; but not active / approved users.
If I turn off the "Admins must approve all users before they gain access" option, then all user admin screens load correctly.
Posts: 4
Participants: 4
Sam Saffron wrote:
We are interested in having a wiki style topic, but do not need this for version 1 of Discourse.
That said if the community would like to contribute a PR in this department we would be more than happy to review, and if good merge.
The spec for v0 of the feature.
- Add a column to posts
wikinot nullable bit, default 0.- Any post that has
wiki=1 is editable by all logged on users.- Add admin post action (like like/flag etc), when clicked it brings up an admin menu
- Admin menu allows you to wiki / unwiki a post
- Every change in state is logged in post_revisions with the name of the admin who changed it
- Any posts that are wiki have a visual cue like PM or Group on the side to denote they are wiki
- Accounts properly for existing states like hidden / deleted, I don't want people editing deleted / hidden posts or posts they have no access to.
More context:
- long term admin menu will have more options like, hard delete post, change owner etc.
- longer term we may add a new permission for editing OP or posts in a category, which will allow better fidelity.
That is it, nothing else for v0.
cc @lightyear
Posts: 6
Participants: 4
arajvanshi wrote:
I have seen bulk invitation feature in many places such as LinkedIn where you can invite multiple friends to LinkedIn using your gmail (or other email, facebook etc.) address book.
This feature doesn't seem to exist here. Any plans on this feature? I think this can help a lot for generating critical mass for any forum in a short time.
Posts: 3
Participants: 3
button is able to do, what 
means, and yes - how to create a topic.
