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

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

Merged
merged 7 commits into from Sep 5, 2018

Conversation

@humitos
Copy link
Member

@humitos 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.

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 and davidfischer Aug 28, 2018
domain = custom_domain.domain
elif self._use_subdomain():
domain = self._get_project_subdomain(canonical_project)
else:
domain = getattr(settings, 'PRODUCTION_DOMAIN')

protocol = 'http'
Copy link
Contributor

@davidfischer davidfischer Aug 28, 2018

Choose a reason for hiding this comment

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

I don't believe this logic is quite right. If require_https_domain=True, the protocol should be https. It doesn't matter whether there's a custom domain or the public domain is used.

Loading

Copy link
Contributor

@davidfischer davidfischer Aug 28, 2018

Choose a reason for hiding this comment

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

Maybe this flag should just be require_https. I don't know what _domain signifies.

Loading

Copy link
Member Author

@humitos humitos Aug 28, 2018

Choose a reason for hiding this comment

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

You are right! I'm fixing this.

Loading

@humitos humitos force-pushed the humitos/resolver/force-https branch from 5037210 to 1d7ac4a Aug 28, 2018
use_custom_domain = any([
(custom_domain and not require_https),
(custom_domain and require_https and custom_domain.https),
])
Copy link
Contributor

@davidfischer davidfischer Aug 28, 2018

Choose a reason for hiding this comment

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

I don't think this logic is correct for .org (it is for .com). On .org, the canonical domain should be used regardless of HTTPS, correct? If the user specifies that their custom domain is canonical, all our links should use that I think.

Loading

Copy link
Contributor

@agjohnson agjohnson Aug 28, 2018

Choose a reason for hiding this comment

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

aye, this logic seems to be for the .com case, where we require https if you use a custom domain. perhaps this needs to be another method on the resolver, similar to _use_subdomain()

Loading

Copy link
Member Author

@humitos humitos Aug 28, 2018

Choose a reason for hiding this comment

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

In .org require_https will be False (the default). So this will enter because of the first condition. In that case, we will use the custom domain no matter what protocol we decide to use later in the next if.

On the other hand, if you are referring to the canonical attribute of the Domain object, we weren't considering it on this resolver at least. Actually, I'm not sure if it should be considered or not. I'm not sure how that attribute works.

Loading

@agjohnson agjohnson added this to the 2.8 milestone Aug 28, 2018
@agjohnson agjohnson removed this from the 2.8 milestone Aug 28, 2018
@agjohnson agjohnson added this to the 2.7 milestone Aug 28, 2018
@humitos
Copy link
Member Author

@humitos 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.

Loading

humitos added 2 commits Aug 28, 2018
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.

use_https_protocol = any([
# Rely on the ``Domain.https`` field
custom_domain and custom_domain.https,
Copy link
Contributor

@davidfischer davidfischer Aug 29, 2018

Choose a reason for hiding this comment

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

I believe the logic on this line should be self._use_custom_domain(custom_domain) and custom_domain.https. Correct?

Loading

Copy link
Contributor

@davidfischer davidfischer Aug 29, 2018

Choose a reason for hiding this comment

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

I mean, functionally, it works but from a logic perspective I think the above is better.

Loading

@humitos humitos force-pushed the humitos/resolver/force-https branch from d3a4e0c to 301cd2f Sep 4, 2018
@humitos humitos requested a review from Sep 4, 2018
Copy link
Contributor

@davidfischer davidfischer left a comment

This looks correct to me!

Loading

Copy link
Member

@ericholscher ericholscher left a comment

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

Loading

@humitos
Copy link
Member Author

@humitos 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.

Loading

Copy link
Contributor

@agjohnson agjohnson left a comment

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.

Loading

@agjohnson agjohnson merged commit ef6a059 into master Sep 5, 2018
1 check passed
Loading
@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
Labels
None yet
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

4 participants