Skip to content

Proxito: use unresolver in 404 handler #10074

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

Merged
merged 23 commits into from
Mar 7, 2023
Merged

Conversation

stsewd
Copy link
Member

@stsewd stsewd commented Feb 27, 2023

  • Moved the logic around checking if an index redirect can be done and finding a custom 404 file into functions, so they can be re-used in both implementations.
  • Logic is the same
  • One small change is that instead of checking if the version slug is defined now we are checking if we were able to find a version object, otherwise looking for an index file or custom 404 page in a version that doesn't exist will be useless (this doesn't change the logic, just an optimization).

This is on top of #10037 and requires #10044. I'll update this PR once those are merged.

@ericholscher ericholscher linked an issue Feb 28, 2023 that may be closed by this pull request
@benjaoming
Copy link
Contributor

@stsewd heads up, I've added some commits here to make the refactor work, I'll take it for a test run and push changes directly unless you're working on it right now?

@benjaoming
Copy link
Contributor

The PR currently looks a bit crazy until refactor-unresolver also has merged in the latest main 👍

Base automatically changed from refactor-unresolver to main March 2, 2023 00:04

def test_redirect_prefix_crossdomain_with_newline_chars(self):
"""
Overridden to make it compatible with the new implementation.
Copy link
Member Author

Choose a reason for hiding this comment

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

We could also make the old implementation compatible, isn't a lot of code, but I'm not sure if we want to spend more time there... (but kind of already spent time debugging it :_)

Copy link
Member

Choose a reason for hiding this comment

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

"The old implementation", is the one we are going to delete, right?

Copy link
Member Author

Choose a reason for hiding this comment

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

yeah

Comment on lines +681 to +685
project = None
version = None
filename = None
lang_slug = None
version_slug = None
Copy link
Member Author

Choose a reason for hiding this comment

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

This is ready for review... but I don't like that we are defining lots of variables that are kind of related, this is kind of a copy/paste of the old implementation, but maybe there is a better way...

Copy link
Member Author

@stsewd stsewd Mar 3, 2023

Choose a reason for hiding this comment

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

They are mainly needed for custom redirects, maybe the answer is there... if we can simplify the redirects code.

Copy link
Member Author

Choose a reason for hiding this comment

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

And, yeah, we should be able to remove version_slug and lang_slug with #10112 :)

Copy link
Member

@ericholscher ericholscher Mar 6, 2023

Choose a reason for hiding this comment

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

I think we can do x = y = z = None, at least? But not a huge deal, I'm fine with the more explicit version, also :)

Copy link
Member

Choose a reason for hiding this comment

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

yeah, I don't like too much the one-line assignment too much because it's harder to read the name of the variables. But that's a personal preference 😄

@benjaoming benjaoming mentioned this pull request Mar 3, 2023
8 tasks
@stsewd stsewd marked this pull request as ready for review March 6, 2023 19:33
@stsewd stsewd requested a review from a team as a code owner March 6, 2023 19:33
@stsewd stsewd requested a review from humitos March 6, 2023 19:33
@stsewd stsewd requested a review from ericholscher March 6, 2023 19:33
@ericholscher
Copy link
Member

ericholscher commented Mar 6, 2023

Is this ready to review? How does it relate to #9657?

Copy link
Member

@ericholscher ericholscher 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 a useful refactor, but want to make sure we aren't losing important context/comments in the refactor. Probably just needs to be compared again current main, and adapted from all the previous reviews.

Really great work knocking down these refactors @stsewd 🎉

return HttpResponseRedirect(redirect_url)

return None

Copy link
Member

Choose a reason for hiding this comment

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

I didn't review the functions above too closely, since they are just copy/pasted from inside the views, right?

Copy link
Member Author

Choose a reason for hiding this comment

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

yeah logic is the same, copy/paste, just the variable names changed final_project -> project, version_slug -> version.slug and so.

Comment on lines 676 to 679
# We force all storage calls to use the external versions storage,
# since we are serving an external version.
if unresolved_domain.is_from_external_domain:
self.version_type = EXTERNAL
Copy link
Member

Choose a reason for hiding this comment

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

I wonder if there is a cleaner way to do this? Could we explicitly set a queryset manager or something here, instead of depending on the downstream code getting this passed in and interpretting it properly? Not 100% sure that makes sense, but would be good to be extra explicit to avoid issues around this.

Copy link
Member Author

Choose a reason for hiding this comment

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

The version that results from the unresolve_path() call already is validated to use the correct manager, this is more like an extra protection (and to reuse the same methods with the older implementation)

Copy link
Member

@ericholscher ericholscher Mar 7, 2023

Choose a reason for hiding this comment

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

Cool 👍 . Probably worth noting that in the comment as well (I might like comments too much, but mission-critical code is important note this stuff), since I thought this was SECURITY CRITICAL, instead of Be extra defensive...

Suggested change
# We force all storage calls to use the external versions storage,
# since we are serving an external version.
if unresolved_domain.is_from_external_domain:
self.version_type = EXTERNAL
# We force all storage calls to use the external versions storage,
# since we are serving an external version.
# The version that results from the unresolve_path() call already is validated to use the correct manager,
# this is here to add defense in depth against serving the wrong version.
if unresolved_domain.is_from_external_domain:
self.version_type = EXTERNAL

Comment on lines +681 to +685
project = None
version = None
filename = None
lang_slug = None
version_slug = None
Copy link
Member

@ericholscher ericholscher Mar 6, 2023

Choose a reason for hiding this comment

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

I think we can do x = y = z = None, at least? But not a huge deal, I'm fine with the more explicit version, also :)

Comment on lines +697 to +709
except VersionNotFoundError as exc:
project = exc.project
lang_slug = project.language
version_slug = exc.version_slug
filename = exc.filename
except TranslationNotFoundError as exc:
project = exc.project
lang_slug = exc.language
version_slug = exc.version_slug
filename = exc.filename
except InvalidExternalVersionError as exc:
project = exc.project
except InvalidPathForVersionedProjectError as exc:
Copy link
Member

@ericholscher ericholscher Mar 6, 2023

Choose a reason for hiding this comment

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

These could use comments explaining what the actual case here is. I can kind of tell from the explicit naming, but I think a bit more context is useful (eg. when might these things happen? Why do we only care about a subset of the variables in those cases?)

Copy link
Member Author

Choose a reason for hiding this comment

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

Put a comment at the top of the try, since an exception happened, we fill the other variables with the information that we have available.

Comment on lines +718 to +719
request.path_project_slug = project.slug
request.path_version_slug = version_slug
Copy link
Member

Choose a reason for hiding this comment

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

These variable names seem not super correct? Are we sure these were parsed from a path?

Copy link
Member Author

Choose a reason for hiding this comment

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

yeah, the names aren't correct, we sometimes pass the slug from the external version domain or the default version on single version projects. But this is what we expect in the middleware

Copy link
Member

Choose a reason for hiding this comment

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

Probably an area for further refactor, but not important in this PR. 👍

@stsewd
Copy link
Member Author

stsewd commented Mar 7, 2023

Is this ready to review? How does it relate to #9657?

This is ready, #9657 uses this branch as base, and it can be reviewed/merged separately.

Copy link
Member

@ericholscher ericholscher 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 good to merge after my comment suggestions are added in :)

Copy link
Member

@humitos humitos left a comment

Choose a reason for hiding this comment

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

Looks good to me. I left some small comments, tho.


def test_redirect_prefix_crossdomain_with_newline_chars(self):
"""
Overridden to make it compatible with the new implementation.
Copy link
Member

Choose a reason for hiding this comment

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

"The old implementation", is the one we are going to delete, right?

Comment on lines +495 to +497
# If we were able to resolve to a valid version, it means that the
# current file doesn't exist. So we check if we can redirect to its
# index file if it exists before doing anything else.
Copy link
Member

Choose a reason for hiding this comment

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

What do you mean by "redirect ot its index file"? /en/latest/file/ -> /en/latest/file/index.html?

If that's correct, can you expand the comment with an example similar to the one I wrote?

Comment on lines +681 to +685
project = None
version = None
filename = None
lang_slug = None
version_slug = None
Copy link
Member

Choose a reason for hiding this comment

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

yeah, I don't like too much the one-line assignment too much because it's harder to read the name of the variables. But that's a personal preference 😄

@stsewd stsewd merged commit 8c462bd into main Mar 7, 2023
@stsewd stsewd deleted the use-proxito-v2-in-404-handler branch March 7, 2023 18:54
@benjaoming benjaoming restored the use-proxito-v2-in-404-handler branch March 8, 2023 10:21
@benjaoming benjaoming deleted the use-proxito-v2-in-404-handler branch March 8, 2023 10:22
@benjaoming benjaoming restored the use-proxito-v2-in-404-handler branch March 8, 2023 10:31
@benjaoming benjaoming deleted the use-proxito-v2-in-404-handler branch March 8, 2023 10:31
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.

Proxito: Next steps on Improve URL Handling
4 participants