Bounty for developing Edgeryders form interface

They get their own topics - they will be collected in this category, right now under development, but soon to be open to everyone

1 Like

Hey @matthias, could you confirm or deny for me that users created via multisite_account.json are set to ‘active’ or not? They’ll need to be based on this line in Discourse:

I believe there’s an option in the discourse api to pass active or not when creating an sso user, but I’m not sure if we’re using it or not:

Right now it’s done this way:

So the new “master account” over at our SSO provider site is not set to active, but the new account is set to active. Due to that, you should be able to use the returned API key immediately.

1 Like

Alright, I think this is ready for an initial test run; I’ve gotten it posting to a local discourse instance using the multisite-accounts plugin and mimicing the setup we’ll have in production as closely as possible.

Three things will need to happen on the instance:

  1. Set the DISCOURSE_ENABLE_CORS env to something truthy if it’s not already
  2. Add the domain hosting the vue app to the cors_origins site setting on the admin panel
  3. Install the permit-api-cors plugin

Steps 1 and 2 will need to be repeated on as well.

Here’s the env we’ll want to set for the vue app:

VUE_APP_DISCOURSE_CATEGORY=343 (<-- this will be changed to 339 for the actual category)

Let me know what snags you run into, and if it successfully gets going, what additional design / styling / functionality work should be done?


I’ll get this done as soon as I can carve out the time. Could still be 2 days from now since we’re all squeezed right now to finish some website and communications materials for parallel projects …

Hey @matthias what’s the ETA on this one? I’m aware of the tight deadline and want to make sure we’re not in a position where the conference is looming and things aren’t working properly :slight_smile:

Thanks for your concern! ETA was yesterday, but the E was wrong. :expressionless: Now I’m having a bit of time again, so let me try and get it done right now …

Are you around for the next 1-2 hours in case I have questions about installing your work?

For sure, fire away :boom:

The env file naming in your Vue.js application is automatically including the deployment environment? So should I name the file .env.production probably? If so, how does it get to know about what deployment environment it’s in?

(I’ve set up the Vue.js application on now. Not sure yet about the env part though. Anyway, now to finishing the changes to Discourse …)

I believe vue will take the values in .env.[ENV_NAME] over the defaults, so yes a .env.production file should work.

It looks like the env is getting loaded alright now, although it seems we need https for the protocol on the urls rather than http


Thanks for having a look. Made the switch to https:// URLs now.

Ok @gdpelican … we’re getting closer to success here, but it’s still a bit of way to go :slight_smile: I followed all your instructions, and:

Now when testing, in the last step I get a red error message “TypeError: Failed to fetch” on screen, and “Failed to load response data” in the web dev tools’ “Network” tab for the request to I guess that means my CORS settings on are not yet accepted.

So far I have:

  1. Created a file app.yml in the root of the Discourse project file tree and put in the following:


    (We’re running Discourse standalone, without Docker. So we don’t have the app.yml file by default.)

  2. Added the following entry the “cors origins” setting in the admin backend:

  3. Restarted the webserver that is serving (Puma in our case).

Documentation about where to put the DISCOURSE_ENABLE_CORS setting is scarce. Did you find something that I missed?

Logging off to sleep now :sleeping: I’ll look into this again first thing in the morning.

I was going off of the message that comes along with the cors_origin site settings:

There’s a touch of documentation in the code about this, although I’ll have to admit I had to dig for it as well, maybe this helps?

1 Like

Thanks, that helped! :slight_smile: The setting was even already in the discourse.conf file, waiting to be enabled. Just not named DISCOURSE_ENABLE_CORS

Now the user is created alright, on both and The final call to still fails, indicating another CORS problem. On this now …

Ok, I got past the CORS problem … means, the browser is sending the final posts.json request now. Also, when I simulate a CORS pre-flight request with curl, I get the expected response incl. Access-Control-Allow-Headers: […] Api-Key, Api-Username. Which means your plugin is running, as it’s adding these two values.

So far, so good. But I get a “403 Forbidden” response for the actual POST request to posts.json.

tl;dr: That must be a bug in the version of Discourse running and happens for all authentication with an Api-Key: header. It does not happen on our Communities sites (listed in the top-right menu “Communities” above), which is running a very recent Discourse version. Solution: I’ll make a test environment on a Communities sites, and get our Discourse guy to update the installation upon his return. If he’ll not get back in time, we’ll also have to place @natalia_skoczylas’s responses into a Communities site at first. Really don’t have the time myself right now for a full Discourse update :expressionless:

@gdpelican please have a little more patience while I create a testing environment on one of the Communities websites …


Details about investigating the error

But I get this as a response to the posts.json query:

  • status code: 403 Forbidden

  • response content:

      "errors": ["You need to be logged in to do that."], 
      "error_type": "not_logged_in"
  • server access log entry by Discourse:

    Started POST "/posts.json" for [IP address] at 2019-10-25 12:50:48 +0200
    Processing by PostsController#create as JSON
    Parameters: {"title"=>"…", "raw"=>"…", "category"=>"339", "post"=> {"raw"=>"…"}}
    Completed 403 Forbidden in 1ms (Views: 0.1ms | ActiveRecord: 0.0ms)

This happens with all requests that use Api-Key: header for authentication, regardless of the API route / endpoint. Even a simple GET request to an access protected topic is failing on

curl '' -H 'Api-Key: [redacted]' | less

Things that are not causing this:

  • Wrong API key. Because the same API key works, for GET requests, when appended as a GET parameter.

  • Reverse proxy setup. Our Discourse site is reverse proxied by Apache, but the same behavior is seen when accessing the Discourse Puma server directly at (note: HTTP only; also note: works with curl, but does not show anything in the browser as JS and other static assets are served by the Apache reverse proxy). So I can exclude that this is because the Api-Key: header would get lost during the proxying.

The error, as tested with the above simple curl GET query for an access protected topic, does not happen on our more recent Discourse installation running the Communities sites. So it must be due to a bug in Discourse, and needs an update of the installation.

1 Like

That’s done now, and lo and behold, it works :partying_face: Great work @gdpelican, and a ton of thanks, also in the name of @natalia_skoczylas.

I created one test topic via the forms software, and it’s preserved here (with my test responses showing as ######…):


Our testing setup is now like this:

Necessarily, the target category is public, as the new users are not members of any groups that would allow them to post in a hidden category. Due to this, let’s be a bit careful when testing to not spam everyone else on the platform. (Just a bit careful. 30 posts are still ok, just not 300.)

Also when testing, please use consistent naming for the e-mail addresses and also so that it expresses that these are for testing purposes only. That will help me delete all test users in the end. The e-mail addresses do not have to exist, so you can for example use a scheme like this:

The live setup will be similar, just that we’ll rename to and maybe move it from our server to Netlify hosting.


Next step: I added a few issues on Github I found during my testing, for @gdpelican to work on. @natalia_skoczylas should do thorough testing now and report everything that should be changed, either in this thread or as a Github issue. No need to report spelling mistakes etc. though, this is our part to adapt when we install the live version. Also @nadia may want to have a look to see how a similar form can be used for the H2020 projects.

1 Like

Cool, thanks for the hard work here! I’ve addressed all of the feedback thus far with the exception of the error messaging; those changes should be on the edgeryders-form master branch now. I’ll grab the error messaging one once I’m back at the machine which has my local discourse instance set up, ETA 2 days or so.

Feel free to open new issues / concerns as you find them :slight_smile:

1 Like

Alright, I’ve pushed some more changes here.

  • Added ability to swap between data files via env. You can now set the VUE_APP_LANG param in .env.production to either en or sl to swap between data/en.json and data/sl.json files, which have differing translations in them. I haven’t been keeping up on my Slovenian, so there’s some copy changes that will want to be made / audited in there.

  • Added an MIT license; I’m not bothered with any restrictions on this software.

  • Fixed the autofocus; now navigating to a slide should always focus the text area to allow for easier typing.

  • Added a PDF of the map to link to; I will circle back and make this a nicer experience

  • Added error handling for network requests; later today I will put in the ones for errors on the discourse side (It’s a trickier thing than it looks, but I believe I have it figured out now.)

I’m unable to repro the api_key undefined error that @natalia_skoczylas experienced, but want to have a full pass at the error messaging before seeing if that happens again, should be good to redeploy tomorrow.


@matthias, have you deployed the latest version?

First time I filled it out, I got this:



Changed email address, pressed submit again, went trough with an error message.


Resulted in this post.

Tried again, and this time no errors. Resulted in this post.

UPDATE: Ah, perhaps this is because the email I used the first time was already registered in the database? I might have used that email for a test user at some point. I guess it’s related to this issue.