Your API key is not valid on this domain

[Phil Bayfield]

I've having problems with a number of requests to the Disqus API, they are responding with:

{

    "code": 11,

    "response": "Your API key is not valid on this domain"

}

This seems to happen on all POST requests to blacklists and whitelists end points.

It works in the API console but not from Postman or Java.

Request is not coming from a website so there is no domain.

[Phil Bayfield]

It seems to work if I use the secret key rather than the public key, is this intentional?

I have tried a few things like sending a referrer (domain in the whitelist) and requesting the admin scope but neither work.

[Burak Yiğit Kaya]

On the API documentation page we usually document which keys can be used for that endpoint. If it only says "private" then you should be using your private key. If it says both public and private, I'd need you to share the endpoints and a sample request you are making to investigate the issue more.

--
You received this message because you are subscribed to the Google Groups "Disqus Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to disqus-dev+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
BYK

[Ryan Valentin]

Generically, this means that the referring domain you're making the request from doesn't match one of the domains you listed in your Disqus API application settings.

If you're making this request server-side, you should use your secret key or set the referrer and host headers manually. Also double-check the whitelisted domains in your API application settings.

Otherwise, like Burak said, we'd need the sample request to investigate more closely.

[Phil Bayfield]

Taking add to blacklist as an example the docs state "public key, secret key" - https://disqus.com/api/docs/blacklists/add/

However, I can't seem to get it to work with the public key, I'm making the requests from an Android app.

Here is an example:

POST https://disqus.com/api/3.0/blacklists/add.json

api_key=MmTKjpV8f1P3pG4ZAByubL57gs9KvZHTIqTHBWBmnFI7kGBEAKru14ezH3LuaNEX&access_token=9669c0e0bb8243ec9e733ad75a98a3f4&forum=philio&word=bannedword

I get a HTTP/400 with body:

{"code":11,"response":"Your API key is not valid on this domain"}

If I swap the api_key for the api_secret it works:

api_secret=t2HtBUE83QO17XSQrdT5GdZ2JSdr0w8UdA0UpEIgELjjan3eVCuc6QbLk4fSXO3I&access_token=9669c0e0bb8243ec9e733ad75a98a3f4&forum=philio&word=bannedword

Response:

{

    "code": 0,

    "response": [

        {

            "forum": "philio",

            "notes": "",

            "value": "bannedword",

            "conflictingWhitelistRemoved": false,

            "type": "word",

            "id": 7048065,

            "createdAt": "2014-10-21T20:52:47"

        }

    ]

}

When I tried setting a referrer header, I used a domain listed in the application settings.

[Burak Yiğit Kaya]

And now you have to regenerate your API keys since you exposed them here (the secret one). I did it for you since you've also exposed an access token. Please do not do this again, just redact them.

--

You received this message because you are subscribed to the Google Groups "Disqus Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to disqus-dev+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
BYK

[Burak Yiğit Kaya]

Yeah, the domain you specified does not match any valid URL. Are you setting referrer header that shows up as the domain entered? I think it works with the secret key because it bypasses the domain check (because it is the secret key and you are using the access token to identify as your own user).

--
BYK

[Phil Bayfield]

Probably should have mentioned that I reset that access token after posting for obvious reasons.

[Phil Bayfield]

It's just a test app so the key/secret aren't really an issue, but should have removed my access token!

I have tried setting the referrer header, but it makes no difference, it matches the app settings too. I guess the test console must be doing something different?

[Phil Bayfield]

Solved the problem, It turns out the problem was postman and it doesn't actually override the referrer header, but I got it working from Android.

I assume the recommended usage in a mobile app would be to avoid using the secret key as it can be reverse engineered?

[Burak Yiğit Kaya]

On Wed, Oct 22, 2014 at 12:36 AM, Phil Bayfield <ph...@bayfmail.com> wrote:

Probably should have mentioned that I reset that access token after posting for obvious reasons.

Hah, yeah. That said your private key was still the same (that's how I found the API app record) so I wanted to play safe just in case. If you think that was not a good move though, I'm open to feedback :)

I assume the recommended usage in a mobile app would be to avoid using the secret key as it can be reverse engineered?

Indeed. You should never reveal your secret key in a publicly accessible resource.

>Solved the problem, It turns out the problem was postman and it doesn't actually override the referrer header, but I got it working from Android.

Did you find a way to override it or simply used your secret key? (sorry not clear from the sentence above). If it doesn't override the referrer header, what is the referrer passed with the request? May be you can add the domain for that to the list?

Also, you probably know but there's this stupid typo with that header: http://en.wikipedia.org/wiki/HTTP_referer#Origin_of_the_term_referer - So may be you tried to override `referrer` where postman was sending `referer` and they got mixed or something?

Best,

--
BYK

[Phil Bayfield]

On Wednesday, 22 October 2014 07:14:37 UTC+1, Burak Yiğit Kaya wrote:

On Wed, Oct 22, 2014 at 12:36 AM, Phil Bayfield <ph...@bayfmail.com> wrote:

Probably should have mentioned that I reset that access token after posting for obvious reasons.

Hah, yeah. That said your private key was still the same (that's how I found the API app record) so I wanted to play safe just in case. If you think that was not a good move though, I'm open to feedback :)

Absolutely, it was late in the evening after a long day and I posted without thinking :)

 

I assume the recommended usage in a mobile app would be to avoid using the secret key as it can be reverse engineered?

Indeed. You should never reveal your secret key in a publicly accessible resource.

>Solved the problem, It turns out the problem was postman and it doesn't actually override the referrer header, but I got it working from Android.

Did you find a way to override it or simply used your secret key? (sorry not clear from the sentence above). If it doesn't override the referrer header, what is the referrer passed with the request? May be you can add the domain for that to the list?

Also, you probably know but there's this stupid typo with that header: http://en.wikipedia.org/wiki/HTTP_referer#Origin_of_the_term_referer - So may be you tried to override `referrer` where postman was sending `referer` and they got mixed or something?

What I meant was that I used the public key with referrer in Android and it worked without issue. Aware of the spelling issue of the referrer header and Postman uses it correctly miss-spelt but in fact the header never gets sent, I think it's some sort of security feature in Chrome to avoid referrer spoofing.

Best,

--
BYK

[Burak Yiğit Kaya]

On Wed, Oct 22, 2014 at 12:50 PM, Phil Bayfield <ph...@bayfmail.com> wrote:

What I meant was that I used the public key with referrer in Android and it worked without issue. Aware of the spelling issue of the referrer header and Postman uses it correctly miss-spelt but in fact the header never gets sent, I think it's some sort of security feature in Chrome to avoid referrer spoofing.

Gotcha. Also yeah I wouldn't expect Chrome to let you override the referrer header :)

Anyways, let me know if there's anything else that I can help with.

--
BYK