Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fixes #2024 - Adds the ability to receive POST data with a JSON Payload #2582

Merged
merged 17 commits into from
Sep 21, 2018

Conversation

karlcow
Copy link
Member

@karlcow karlcow commented Sep 19, 2018

This PR fixes issue #2024

Proposed PR background

This should be able to receive POST data with a JSON body for pre-populating the form.

  • Works as before and accept URL parameters both from GET and POST
  • Adds a POST JSON data for the form
  • Submit the data as before with multiform/part

Possible Follow up issues to fill.

  • Be stricter in what is possible to do in the POST data (JSON validation)
  • Be stricter on the form validation.

The next step will be to push this to staging so we can test it deeply and thoroughly.

→ nosetests 
..................................................................................................
----------------------------------------------------------------------
Ran 98 tests in 1.133s

OK

r? @miketaylr

@karlcow karlcow requested a review from miketaylr September 19, 2018 05:19
@miketaylr
Copy link
Member

Possible Follow up issues to fill.

Also, all the clients we control that create issues via this form need to be updated.

Copy link
Member

@miketaylr miketaylr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks great, just a few questions to make sure that I understand how this works. Haven't tested locally yet, but that's the next step once I have a few more answers. Then we can deploy this thing to staging.

tests/unit/test_helpers.py Show resolved Hide resolved
tests/unit/test_uploads.py Show resolved Hide resolved
webcompat/form.py Show resolved Hide resolved
webcompat/views.py Show resolved Hide resolved
webcompat/views.py Outdated Show resolved Hide resolved
webcompat/views.py Outdated Show resolved Hide resolved
webcompat/views.py Outdated Show resolved Hide resolved
tests/unit/test_helpers.py Show resolved Hide resolved
tests/unit/test_helpers.py Outdated Show resolved Hide resolved
webcompat/views.py Show resolved Hide resolved
@miketaylr
Copy link
Member

This branch is out-of-date with the base branch

Could you also rebase against master, that will make deploying to staging a tiny bit simper. 😻

@karlcow
Copy link
Member Author

karlcow commented Sep 19, 2018

Rebasing against master. Definitely!

This goes through the possible scenarios when requesting the form with a POST or a GET.
This will help us determine how we want to process the data when requesting.
This is handling a form_data object as a dictionary which is in charge of containing the data relative to the future Form()
…submission

The tests were not defining the type and were then sending url-encoded stuff, which is not what we do in the HTML.
This is a minimal test which could become more complete if we wanted.
A lot of the data can be collected at first request.
…ith a body

The new form interaction are two folds
1. GET with parameters or POST with a body
2. POST as a multipart form to GitHub
Just polishing things here and there.
@karlcow
Copy link
Member Author

karlcow commented Sep 19, 2018

Rebased and pushed. Let's see what travis said.
I haven't addressed the comment about form_data yet as our discussion is going on.

Copy link
Member

@miketaylr miketaylr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is great.

Only "unresolved" issue is #2582 (comment), which isn't really an issue. We can leave it as-is and file a follow up, or make a decision it's the right way, or change it as I described in my comment. No strong feelings.

@miketaylr
Copy link
Member

I've (temporarily? not seeing much pretriage activity...) deployed this branch to staging and when I try to file an issue:

502 Bad Gateway

2018/09/20 20:35:02 [error] 6998#0: *1839287 upstream prematurely closed connection while reading response header from upstream, client: xxx, server: staging.webcompat.com, request: "POST /issues/new HTTP/1.1", upstream: "uwsgi://unix:///tmp/uwsgi-staging.sock:", host: "staging.webcompat.com", referrer: "https://staging.webcompat.com/"

Trying to investigate more.

@miketaylr
Copy link
Member

Once I log in, I'm able to file reports just fine. Logging out, and trying to report anonymously I get the following stack trace:

Traceback (most recent call last):
 [snip]
  File "./webcompat/views.py", line 245, in create_issue
    json_response = report_issue(form)
  File "./webcompat/issues.py", line 30, in report_issue
    json_response = github.post(path, build_formdata(form))
  File "/.../staging.webcompat.com/env/local/lib/python2.7/site-packages/flask_github.py", line 280, in post
    data=data, **kwargs)
  File "/.../staging.webcompat.com/env/local/lib/python2.7/site-packages/flask_github.py", line 247, in request
    raise GitHubError(response)
flask_github.GitHubError: 401: Bad credentials

Let me ensure I'm using the right credentials, I did mess with that to help out a contributor, and maybe deployed the wrong thing to staging.

@miketaylr
Copy link
Member

OK, not a credentials thing.

It seems if I'm not logged in, and I click "report Anonymously", I get a 502.
If I log in and click "report Anonymously" it reports it as myself.

@miketaylr
Copy link
Member

miketaylr commented Sep 20, 2018

Copy link
Member

@miketaylr miketaylr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's add proxy=True to report_issue, then I'll re-deploy to staging.

@karlcow
Copy link
Member Author

karlcow commented Sep 21, 2018

https://github.com/webcompat/webcompat.com/pull/2582/files#diff-a50603a824fb762e9303ee20ff0f2945L237

proxy=True is missing for auth anon reports.

Do you remember why we are using proxy=True or False instead of form.get('submit_type') inside report_issue?

1. Addresses the PR review
2. Adds tests for case for the submit type is wrong
3. Makes the reporting request a bit stricter.
We could probably pass again form_data again later when we need it for more complex things.
@karlcow
Copy link
Member Author

karlcow commented Sep 21, 2018

@miketaylr this is working now for anonymous users. It can be deployed again on staging. :)

@miketaylr
Copy link
Member

Do you remember why we are using proxy=True or False instead of form.get('submit_type') inside report_issue?

No, I don't remember if this was an intentional design decision (to allow it to be used outside of a form submission context), or just like, the way we wrote it. :S

Copy link
Member

@miketaylr miketaylr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks great. Will do some quick testing on staging.

@miketaylr
Copy link
Member

All good in my testing. Let's mergeeeeeee 💯 🍰 🌵

@miketaylr
Copy link
Member

(ok, so the "Update branch" button does a merge commit, that's lame :P)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants