Issue with Edgeryders form

Yes, every Discourse site has its own CORS whitelist. I just added to “Allowed CORS origins” on now, so that part should work now.

The installation of James’ forms software is well documented here. About your question it says (emphasis mine):

4. Enable and configure CORS in Discourse

The following steps have to be done in both Discourse instances (SSO provider and SSO client).

[…] Add the CORS origin. Add the domain that will host this Edgeryders Form Vue.js application to the cors_origins setting via the Discourse admin panel.

1 Like

@matthias - Thanks for the explanation, I understand the process better.

On the last try, the GET call to returned the login page source code rather than the user API key. The call was made after being returned to the page following the login.

However, this was from a local server (not whitelisted) - so it may explain this issue.

As for James’ form, it is still returning this access control error - I have just tried it again:

Fetch API cannot load due to access control checks.

Is the address on the whitelist for sure? Thanks again for your help.

Yes, it’s certainly on the whitelist.

The best way to assist will be that you provide me with a cURL call of the failing request so I can reproduce this here. For that: in Firefox web developer tools go to tab “Network”, right-click on a request and choose “Copy → Copy as cURL”. It’s equivalent in Chrome AFAIK. Since that command may include a session cookie, send it by DM.

ok - two minutes.


Turns out that API endpoint has accidentally become access protected somehow.

Because it works when including a session cookie, as follows:

curl '{GET params as usual here}' -H 'Cookie: _t=bbeb……4a86'

(If that kind of command does not work like that for you, the API endpoint might now even be only accessible for admins. Didn’t test for that.)

With such a command, I don’t get the exact same error message when using curl, but I am served a document saying “You are being redirected”, with a link to the login page. Probably JavaScript recognizes from some response metadata that it’s an access protected page, and then tells you “Fetch API cannot load […] due to access control checks.” So this is not anymore about CORS.

We didn’t change the API endpoint, but we updated Discourse on the all sites except to the latest version a few days ago (and that broke other things already).

We’ll get the issue about this API endpoint fixed ASAP, within 1-2 days (now tracked as #241). Until then, you could add the cookie header equivalently to the curl command above to be able to work with this endpoint. Of course before live use, the issue has to be fixed as you’d not want to have an auth cookie of your own login inside the software.


(In other news, I just refined the API manual sections about multisite_account.json and about multisite_account_api_key.json.)

1 Like

Thanks @matthias

@owen This is now fixed, the endpoint is now accessible again.


@matthias @daniel - I am still getting CORS issues, from

Access to fetch at ' HIDDEN' from origin '' has been blocked by CORS policy: The 'Access-Control-Allow-Origin' header has a value '' that is not equal to the supplied origin. Have the server send the header with a valid value, or, if an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.

I have double checked the configuration and the instructions and I believe there is nothing wrong on my end… Can you check why this is happening?

I’m not able to reproduce the error. In the backend cors origin was allowed from “”. I removed the trailing “/” which might not be valid - at least for requests ( ). If you still get the error please post a curl request that triggers the error. I already tried requests with Postman but they seem to work fine.

@Daniel - the account creation part now works, however I am getting a 403 error calling posts.json (forbidden) that prevents the topic being created - pasted as a curl request below.

curl '' \
  -H 'Connection: keep-alive' \
  -H 'Api-Key: 111977e6...' \
  -H 'User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_16_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/84.0.4147.89 Safari/537.36' \
  -H 'Content-Type: application/json' \
  -H 'Accept: */*' \
  -H 'Origin:' \
  -H 'Sec-Fetch-Site: cross-site' \
  -H 'Sec-Fetch-Mode: cors' \
  -H 'Sec-Fetch-Dest: empty' \
  -H 'Referer:' \
  -H 'Accept-Language: en-GB,en-US;q=0.9,en;q=0.8' \
  --data-binary $'{"title":"Rethinking retirement - response by owen4","raw":"**We don\'t seem to discuss retirement much with others. How much do you think about your own retirement? What do you think about? And what do you avoid thinking about?**\\n\\nTest 1\\n\\n**How about work, hobbies, family life, leisure, pleasure... Which activities from your present life would you like to keep doing? Which things would you like to never do again?**\\n\\nTest 1\\n\\n**Great, now that you\'ve chosen what stays and what to leave behind - start to imagine your future self. The \'dream you\'. How do you get there? Which new skills and what knowledge do you want to acquire?**\\n\\nTest 1\\n\\n**Imagine your housing situation and the people around you (or their absence). Who are you surrounded by in your retirement?<br />Where and how would you like to live?**\\n\\nTest 1\\n\\n**If you know people who have retired, was there something to learn from their experience and approach? Could you share their impressions?**\\n\\nTest 1\\n\\n**How do you imagine sustaining yourself financially? Maybe you have a plan, a tip, or an idea, that you would like to share?**\\n\\nTest 1\\n\\n\\n\\n**name:** owen4\\n**age:** 31","category":"250"}' \
1 Like

Good. :slight_smile: The api key is active. To create a post send it as a post request like curl -X POST ' ... See for required parameters. To create a post e.g. topic_id is required.

1 Like

(Edited your post to hide the API key since I did not know if that’s @owen’s own key or just a throw-away key. In any case ideally do not post API keys publicly but rather in DMs, and just post the first few characters publicly.)

1 Like

@daniel Thanks - unfortunately I’m getting the same 403 and I’m not sure why…

The payload looks like this:

{"title":"Rethinking retirement - response by owen","raw":"test_post 1","category":250,"topic_id":19987}

topic_id is there, so I don’t believe this is the issue.

curl '' \
  -H 'Connection: keep-alive' \
  -H 'Api-Key: 0e82...' \
  -H 'User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_16_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/84.0.4147.89 Safari/537.36' \
  -H 'Content-Type: application/json' \
  -H 'Accept: */*' \
  -H 'Origin:' \
  -H 'Sec-Fetch-Site: cross-site' \
  -H 'Sec-Fetch-Mode: cors' \
  -H 'Sec-Fetch-Dest: empty' \
  -H 'Referer:' \
  -H 'Accept-Language: en-GB,en-US;q=0.9,en;q=0.8' \
  --data-binary '{"title":"Rethinking retirement - response by owen","raw":"test_post 1","category":250,"topic_id":19987}' \

test_post 1

It needs to be a post request like curl -X POST - then it shall work.

fetch("", {
    method: 'post',
    headers: { 'Api-Key': apiKey, 'Content-Type': 'application/json' },
    body: getPayload()

this is the javascript equivalent of curl -X POST… unless I’m missing something?

the same function was working back in November… but I can try it with a different http request.

Hmm, your curl request worked for me when it was sent as a post request and the topic-id adapted to this topic (13926). Your API key is also active. Let me know the error if it’s not working.

It’s the same 403 forbidden error :frowning:

after reading some discussions I understand that the topic_id parameter is optional, for adding a post to an existing topic. if not present, it should create a new topic - this was how the form was intended to work (see an example response here)

Regardless when including topic_id or only the category_id to post in, both return the 403 error.

The body payload is like this:

var payload = {
      title: 'Rethinking retirement - response by owen',
      raw: 'test_post 1',
      category: 237

So it should post a new topic in category 237 (campfire).

@gdpelican may be able clarify how this should work, if available.

Update - in this example, different header parameters are used:

curl -X POST "" \
-H "Content-Type: multipart/form-data;" \
-F "api_key=theGeneratedAPIKeyForanAdmin" \
-F "api_username=anAdmin" \
-F "title=This is an API created topic" \
-F "raw=This is the end of the world as we know it, and I feel fine."

The two parameters api_key and api_username are not in the header of the form’s call, only Api-Key - so I will test with these two.

Found this - all non-HTTP header based authentication was dropped. So the right way to do it is to supply the API-Key in the header. Does a curl request work for you - or do you always get 403 errors?