Bounty for developing Edgeryders form interface

Alright, can confirm this will work for our use case; I do have to add a line (via this plugin) to PostsController to allow it to skip CSRF checking via the api:

skip :verify_authenticity_token, only: :create, if: :is_api?

I’ll push that up soon.

2 Likes

Cool, I’ve been successful in making posts from the vue app to a local discourse instance with that plugin installed; I’ve pushed that plugin up to GitHub - gdpelican/permit-api-cors: Allow a Discourse instance to accept Api-Key in the CORS settings

Here’s a screenshot of an example post (open to feedback on title / formatting / etc):

One thing I wasn’t clear on was whether we are posting all of the responses in a single topic, or each response gets its own topic?

Next up: There’s CORS trouble with hitting the multisite endpoint as well (obviously 'localhost:8080 isn’t a great thing to put in your list of accepted origins), but I’m hoping I’ll be able to install that plugin locally as well and get an end-to-end test going soon.

@natalia_skoczylas, what’s the intention?

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

https://edgeryders.eu/c/rethinking-retirement-academy-of-life

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 communities.edgeryders.eu is not set to active, but the new edgeryders.eu account is set to active. Due to that, you should be able to use the returned edgeryders.eu 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 edgeryders.eu 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 communities.edgeryders.eu as well.

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

VUE_APP_DISCOURSE_USER_URL=http://communities.edgeryders.eu/multisite_account.json
VUE_APP_DISCOURSE_AUTH_KEY=<auth_key>
VUE_APP_DISCOURSE_DOMAIN=edgeryders.eu
VUE_APP_DISCOURSE_TOPIC_URL=http://edgeryders.eu/posts.json
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?

2 Likes

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 https://bio26testing.edgeryders.eu/ 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

VUE_APP_DISCOURSE_USER_URL=https://communities.edgeryders.eu/multisite_account.json
VUE_APP_DISCOURSE_TOPIC_URL=https://edgeryders.eu/posts.json

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 https://bio26.edgeryders.eu, 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 https://communities.edgeryders.eu/multisite_account.json. I guess that means my CORS settings on communities.edgeryders.eu 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:

    env:
      DISCOURSE_ENABLE_CORS: true
    

    (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 communities.edgeryders.eu admin backend:

    • https://bio26testing.edgeryders.eu
  3. Restarted the webserver that is serving communities.edgeryders.eu (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 communities.edgeryders.eu and edgeryders.eu. The final call to https://edgeryders.eu/posts.json 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 edgeryders.eu 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 edgeryders.eu 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 edgeryders.eu:

curl 'https://edgeryders.eu/t/about-the-survey-tests-category/11116' -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 http://edgeryders.eu:9292 (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 edgeryders.eu 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 ######…):

https://community.trustinplay.eu/t/rethinking-retirement-response-by-test02-ansorgs-de/628

 

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:

testuser100@example.com
testuser101@example.com
testuser102@example.com
...

The live setup will be similar, just that we’ll rename bio26testing.edgeryders.eu to bio26.edgeryders.eu 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