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

Force resolver to use PUBLIC_DOMAIN over HTTPS if not Domain.https #4579

Merged
merged 7 commits into from Sep 5, 2018

Conversation

Projects
None yet
4 participants
@humitos
Member

humitos commented Aug 28, 2018

Argument require_https_domain added to force the resolver to use https URLs with PUBLIC_DOMAIN when the Domain is not https.

I found this while running tests on Corporate site since we don't serve documentation over plain HTTP there. So, we need a way to force the https protocol even when the project has a Domain object (but https=False). In this case, we force to use our PUBLIC_DOMAIN URL over HTTPS.

Force resolver to use PUBLIC_DOMAIN over HTTPS if not Domain.https
Argument ``require_https_domain`` added to force the resolver to use
https URLs with PUBLIC_DOMAIN when the Domain is not https.

@humitos humitos requested review from rtfd/core and davidfischer Aug 28, 2018

@agjohnson agjohnson modified the milestones: 2.8, 2.7 Aug 28, 2018

@humitos

This comment has been minimized.

Show comment
Hide comment
@humitos

humitos Aug 28, 2018

Member

OK, I updated this PR and the one under .com with a method as @agjohnson suggested to decide whether to use the custom domain or not.

Member

humitos commented Aug 28, 2018

OK, I updated this PR and the one under .com with a method as @agjohnson suggested to decide whether to use the custom domain or not.

humitos added some commits Aug 28, 2018

Refactor Symlink test cases to use override_settings properly
Doing `settings.SITE_ROOT = '/path'` may cause problems. For this
cases, `@override_settings` has to be used.

This commit refactors the code around Symlink tests to use the
decorator properly.

@humitos humitos requested a review from rtfd/core Sep 4, 2018

@davidfischer

This looks correct to me!

@ericholscher

The changes look good, but I don't see any tests for the new logic.

@humitos

This comment has been minimized.

Show comment
Hide comment
@humitos

humitos Sep 5, 2018

Member

There shouldn't be changes in the logic. This PR only makes the resolver extensible from corporate site.

After the changes in .org's resolver that David did around HTTPS some corporate tests start failing and when trying to fix them I realize that it was not possible with the current implementation of the resolver under .org.

So, I refactored it to be able to extend it from corporate.

Member

humitos commented Sep 5, 2018

There shouldn't be changes in the logic. This PR only makes the resolver extensible from corporate site.

After the changes in .org's resolver that David did around HTTPS some corporate tests start failing and when trying to fix them I realize that it was not possible with the current implementation of the resolver under .org.

So, I refactored it to be able to extend it from corporate.

@agjohnson

LGTM! We'll want to be very careful in QA pass and in deploying. Our resolver can be fragile and is used for a lot of not well tested cases.

@agjohnson agjohnson merged commit ef6a059 into master Sep 5, 2018

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details

@agjohnson agjohnson deleted the humitos/resolver/force-https branch Sep 5, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment