Not me. I’ve been using SSL and API works great.
It would appear my issue was that I was attempting to test things out with a self-signed certificate before getting a signed one. Apparently Discourse treats self-signed certificates as a security violation.
Everything treats self signed SSL as a security violation, and for good reason. There should be no expectation that this should work unless you happen to be a root certificate authority…
Yes, Discourse and every web service and browser in existence
Namecheap sells legit ones pretty cheap.
StartSSL issues free certificates, as long as you can live with a few minor limitations.
- No wildcard names,
- max. of 1 subdomain altname per certificate,
- must revoke certificate before being able to replace it, revocations are not free (only applies until two weeks before certificate expires).
At the risk of being that guy, I just wanted to clarify what I was saying. I have no expectation that Discourse ignore self-signed certificate errors. I understand what a self-signed certificate means, and why that would be A Bad Thing.
My particular use case is that I am doing some prototyping of getting an Intranet to talk to Discourse. Just to test things out, we created a self-signed certificate so we could have both our intranet and Discourse talking over SSL. Now, Discourse itself works fine with the self-signed certificate. The browsers, quite appropriately, throw up big scary warnings which (as a developer) I know I can safely ignore inside our firewall, since we created the certificate ourselves.
What was confusing me is that the Discourse API works fine over SSL with a self-signed certificate if you are logged in and are passing cookies to authenticate. If it didn’t, the Discourse user interface wouldn’t work at all. Also, unauthenticated requests to the API work fine too. For example, you can do the following:
> curl "https://example.com/user_actions.json?username=myusername&filter=4,5,6,7,9"
That will return data just fine (assuming you have public content in the system). However, as soon as you add an API key in, then Discourse returns a 403 error. For example:
> curl "https://example.com/user_actions.json?username=myusername&filter=4,5,6,7,9&api_key=618e6eb2670a5eb9579b26bea965e8cf9921870c90551091b11d7e5dee1948f9&api_username=myusername"
The confusing thing is, that when you add the API key, what would have worked just fine over clear text suddenly stops working.
Now, I’m not writing this up to have a whinge and beg the Discourse developers to add an extra configuration option (though that would be nice). I’ll get a signed SSL certificate in the near future and everything will be peachy (in theory). I just thought it would be worth documenting in case someone else runs into the same issue, since it is not obvious from the error messages that the issue is related to the self-signed certificate. It just looks like your API key has suddenly stopped working (which it hasn’t).
Are you sure that this is TLS related? I can see how an invalid certificate might throw an API client library, but
curl? No way. If
curl is told to accept the invalid certificate, Discourse shouldn’t care or know that the client made that choice.
As an experiment, I’ve temporarily renamed
/etc/ssl/certs so curl can’t verify any certificates, self-signed or not, but
curl "https://<my domain>/user_actions.js?username=jens&api_username=jens&api_key=<key>" -k -D - |less -S is still working just fine for me.
Is there a way to get the number of likes a reply or user has received? I searched through routes.rb and didn’t find anything related to likes given or received.
I’d like (ha) to be able to isolate the most liked replies.
For the first question, number of likes a user has recieved, watch the network tab on your user page.
That’s going to require a SQL query, I think.
Thanks, @riking. Is there any way to pass an SQL query via the API? Alternatively, what would be the best approach for accessing ‘top’ content (such as most liked, or most active user, that would require an SQL query) outside of Discourse?
Replying to my own question, one solution is here: Access Discourse DB from host
is there any way to assign a group permission to a category through the API? if so, how?
Could the search portion of the API be off? Using the syntax provided above (
curl -X GET -d term="new quotes category" http://localhost:3000/search.json), I get identical json output no matter what term I search for.
For example, when testing the search API against meta.discourse.org, I get the following:
[sys@tem ~] $ curl -X GET -d term="api" https://meta.discourse.org/search.json > v1.txt % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 37160 0 37152 100 8 90487 19 --:--:-- --:--:-- --:--:-- 90394 [sys@tem ~] $ curl -X GET -d term="json" https://meta.discourse.org/search.json > v2.txt % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 37161 0 37152 100 9 93812 22 --:--:-- --:--:-- --:--:-- 94055 [sys@tem ~] $ diff v2.txt v1.txt [sys@tem ~] $
I also get the same output if I search for a term I know should produce no results.
Replying to my own question, again. Correct search syntax is:
Note that syntax is temporary, going to change it to
https://meta.discourse.org/search.json?q=lorem as soon as I have a chance.
CORS is better than JSONP.
Unless you would like to support legacy browsers. Then you’d need to use JSONP.
Having some sort of auto-generated API documentation would be amazing, and is much more likely to stay up to date than this post.
Does anyone know if it is possible to fetch the most recent posts (not topics) for a given category?