-
Notifications
You must be signed in to change notification settings - Fork 94
Conversation
Remove duplication. Moved removed content into wiki.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
thanks for fixing this. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for your effort on implementation AND test cases! A couple minor questions below.
raise ValueError("The authority url must be of the format https://login.microsoftonline.com/your_tenant") | ||
elif len(path_parts) == 1: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The next line of normalization is needed for sure, but this elif ...
clause seems not really necessary, does it? In such case, can we omit this elif ...
line to emphasize the fact that there wouldn't be a third implicit code branch else ...
scenario to be considered/reviewed here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There can be a case when the length is 0, in which case we would want to handle it differently and not normalize it. So I think the elif ...
should be there.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We discussed offline and clarified understandings. Since the rstrip(...)
can handle case when length is 0 or more, the code could be written this conceptually different way:
if len(path_parts) > 1:
raise ValueError("The authority url must be of the format https://login.microsoftonline.com/your_tenant")
self._url = urlparse(self._url.geturl().rstrip('/'))
yet the actual behavior would be the same.
tests/test_authority.py
Outdated
|
||
@httpretty.activate | ||
def test_url_extra_slashes_change_authority_url(self): | ||
authority_url = self.nonHardCodedAuthority + '//' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Out of curiosity, do we purposely use double slash //
here (and the test case above)? It is rare to see //
because only the backslash \\
would need to be doubled in a string literal.
To be clear, I know the implementation in this PR happens to be able to handle multiple trailing slashes, which is a sweet side effect to have. But from the intention perspective, the expectation was to handle (at least) one trailing slash, and if we wrote our test cases with //
, it does not explicitly indicate that we can definitely handle /
.
PS: @stcheng also had confusion on //
, based on the github notification emails.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The number of slashes here actually don't matter because any number of slashes should be stripped. It just makes sure any number of slashes after the authority url are stripped before going further.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can change it real quick 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@henrik-me We could test both if we really want to. Personally I consider a test case for //
(or ///
, ////
, ..., for that matter) is optional, because: (1) we won't be able to cover all possible scenario anyway, (2) multiple adjacent slashes is not a valid url path in the first place, it seems not in our interest to have a formal extra test case here to demonstrate our SDK can handle it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What if we add a comment in the existing one which explains that it is designed to handle one or more slashes?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
tests should cover both good and bad scenarios. it's not all but ensuring we cover test cases ensuring we do not break the behavior we introduced (namely stripping of all / and ensuring there is always only 1 when we create the url. (I suppose I do not understand based on your comment Ray why we would even have changed the test in the first place)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Aside: I already gave sign-off.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
This relaxes the authority url check to allow customers to add slashes after the tenant.
It then normalizes the url by removing these extra slashes.
Solves #156