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

Fix #5466: Added check to enforce that all name of controllers end with "Handler" or "Page" #5878

Merged
merged 12 commits into from
Nov 28, 2018

Conversation

lilithxxx
Copy link
Contributor

@lilithxxx lilithxxx commented Nov 16, 2018

Fixes #5466
This PR adds a function to check all controller's name end with 'Handler' or 'Page'.
The controllers that are sub-classes of the base class which did not end with the words are changed accordingly.

This PR is a duplicate of #5641

Explanation

Checklist

  • The PR title starts with "Fix #bugnum: ", followed by a short, clear summary of the changes. (If this PR fixes part of an issue, prefix the title with "Fix part of #bugnum: ...".)
  • The PR explanation includes the words "Fixes #bugnum: ..." (or "Fixes part of #bugnum" if the PR only partially fixes an issue).
  • The linter/Karma presubmit checks have passed.
    • These should run automatically, but if not, you can manually trigger them locally using python scripts/pre_commit_linter.py and bash scripts/run_frontend_tests.sh.
  • The PR is made from a branch that's not called "develop".
  • The PR follows the style guide.
  • The PR is assigned to an appropriate reviewer.
    • If you're a new contributor, please ask on Gitter for someone to assign a reviewer.
    • If you're not sure who the appropriate reviewer is, please assign to the issue's "owner" -- see the "talk-to" label on the issue.

@seanlip
Copy link
Member

seanlip commented Nov 16, 2018

Hi @lilithxxx, FYI the travis build is still failing. Could you please investigate?

Also please include a reference in this PR to the other PR (and close one of them so that there's just a single point of focus ).

Thanks!

@codecov-io
Copy link

codecov-io commented Nov 16, 2018

Codecov Report

Merging #5878 into develop will not change coverage.
The diff coverage is n/a.

Impacted file tree graph

@@           Coverage Diff            @@
##           develop    #5878   +/-   ##
========================================
  Coverage    45.53%   45.53%           
========================================
  Files          517      517           
  Lines        30335    30335           
  Branches      4562     4562           
========================================
  Hits         13812    13812           
  Misses       16523    16523

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update cf4939c...af4b4e1. Read the comment docs.

@lilithxxx
Copy link
Contributor Author

@seanlip made the changes, PTAL

"""
def get(self):
"""Handles GET requests."""
text = 'example'
Copy link
Member

Choose a reason for hiding this comment

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

text is vague -- consider file_contents instead.

@@ -107,8 +107,8 @@ def test_editable_collection_handler_get(self):
response = self.testapp.get(
'%s/%s' % (
feconf.COLLECTION_EDITOR_DATA_URL_PREFIX,
self.COLLECTION_ID))
self.assertEqual(response.status_int, 302)
self.COLLECTION_ID), expect_errors=True)
Copy link
Member

Choose a reason for hiding this comment

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

I don't understand why your PR is causing the underlying behaviour here to change. Conceptually this PR is supposed to be just a renaming, so this looks like an unintended consequence.

Can you dig into this and find out why it changed? Tests are supposed to protect against this sort of thing; when a test fails, it may be due to an error in the newly-introduced code.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@seanlip Isn't this an expected behaviour? This test checks that non-editors cannot access the editor data handler due to them not being whitelisted. Hence if we dont add expect_errors there's an app error of not being authorised.

Copy link
Member

@seanlip seanlip Nov 17, 2018

Choose a reason for hiding this comment

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

But why did your PR in particular cause this behaviour to change?

(I think 302 typically represents a redirect to the login page. So it's not necessarily wrong. But the more pertinent question is the one above.)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It seems the error occurs when modifying EditableCollectionDataHandler in collection_editor by adding GET_HANDLER_ERROR_RETURN_TYPE. There seems to be some kind of authorisation problem.

Copy link
Member

Choose a reason for hiding this comment

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

OK, that's a good start. Can you continue digging into this and tracing what exactly happens, then explaining that in this comment? It's important that we understand what exactly we are modifying, especially with something so crucial as rights management -- we need to get that right.

So, perhaps explain what the flow was like before, and then explain what the flow is now after your modification.

Thanks!

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Hi @seanlip. The error is occurring in this line. For NotLoggedInException its matching if the error_return_type is 'json' or not as there is no payload for GET requests. This error does not occur in other classes as there are either tests for logged in users only or for controllers rendering HTML

Copy link
Member

@seanlip seanlip Nov 23, 2018

Choose a reason for hiding this comment

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

Ah, ok, thanks for checking! That's a good find.

Looking at that part of the code, I think the logic is not quite correct. Could we modify it so that we return the HTML error page response only if the request is GET and the handler type is HTML, otherwise we return the JSON response?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@seanlip Upon changing that piece of code other error pops up like here and here.
I think the above ^^ is expected and the error that now shows should be changed. If the user is not logged in the error that should be displayed is error 401 and not 302.

Copy link
Member

@seanlip seanlip Nov 24, 2018

Choose a reason for hiding this comment

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

I agree that 401 errors make sense in both these cases. But they should be JSON responses, right? I'm not sure how this conceptually conflicts with the last comment I made.... could you please explain?

(Note that my last comment talks about the form of the response -- HTML vs JSON -- and does not suggest any changes to the response status codes.)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

done

@oppiabot
Copy link

oppiabot bot commented Nov 17, 2018

Hi @lilithxxx. Due to recent changes in the "develop" branch, this PR now has a merge conflict. Please follow this link if you need help resolving the conflict, so that the PR can be merged. Thanks!

@oppiabot
Copy link

oppiabot bot commented Nov 25, 2018

Hi @lilithxxx. Due to recent changes in the "develop" branch, this PR now has a merge conflict. Please follow this link if you need help resolving the conflict, so that the PR can be merged. Thanks!

@lilithxxx
Copy link
Contributor Author

@seanlip made changes. PTAL

elif return_type == feconf.HANDLER_TYPE_HTML:
method = self.request.environ['REQUEST_METHOD']

if(return_type == feconf.HANDLER_TYPE_HTML and
Copy link
Member

Choose a reason for hiding this comment

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

Missing space before '('

@apb7 -- shouldn't the linter catch this?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

done

self.values.update(values)
if 'iframed' in self.values and self.values['iframed']:
self.render_template(
'pages/error/error_iframed.html', iframe_restriction=None)
else:
self.render_template('pages/error/error.html')
else:
logging.warning('Not a recognized return type: '
'defaulting to render JSON.')
if return_type != feconf.HANDLER_TYPE_JSON:
Copy link
Member

Choose a reason for hiding this comment

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

What if the return type is DOWNLOADABLE (say)?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

done

file_contents = 'example'
self.render_downloadable_file(
file_contents, 'example.pdf',
'text/plain')
Copy link
Member

Choose a reason for hiding this comment

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

Move to end of previous line.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

done

@lilithxxx
Copy link
Contributor Author

@seanlip made changes. PTAL

@seanlip
Copy link
Member

seanlip commented Nov 27, 2018

@lilithxxx, why are you force pushing? Please don't do that. It messes up the history and makes it harder to review things.

Otherwise, the PR LGTM, and I have no further comments. Thanks!

@lilithxxx
Copy link
Contributor Author

Actually there were conflicts so I had to force push. I won't do that again

@seanlip
Copy link
Member

seanlip commented Nov 27, 2018

Thanks for explaining! For future reference, see notes in step 5 here for how to merge code -- you should address the conflicts directly when you're doing the merge, by searching for "<<< HEAD" say. See https://help.github.com/articles/resolving-a-merge-conflict-using-the-command-line/ for more details.

(And yep, never force-push again, please. Thanks!)

@seanlip seanlip merged commit d7c44b2 into oppia:develop Nov 28, 2018
@lilithxxx lilithxxx deleted the new_base branch December 1, 2018 20:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add check to enforce that all subclasses of BaseHandler end with "Handler"
3 participants