-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Feature/support multiple auth headers in gb #11556
Feature/support multiple auth headers in gb #11556
Conversation
WordPress/src/main/java/org/wordpress/android/ui/utils/AuthenticationUtils.kt
Show resolved
Hide resolved
You can test the changes on this Pull Request by downloading the APK here. |
@@ -147,6 +147,8 @@ public AztecLoggingException(Throwable originalException) { | |||
private static final String TEMP_VIDEO_UPLOADING_CLASS = "data-temp-aztec-video"; | |||
private static final String GUTENBERG_BLOCK_START = "<!-- wp:"; | |||
|
|||
private static final String AUTHORIZATION_HEADER_NAME = "Authorization"; |
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.
Would it make sense to reuse the AUTHORIZATION_HEADER_NAME
from AuthenticationUtils
here instead of declaring a new variable?
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.
Yes, but AztecEditorFragment
is part of the Editor submodule, so It has no access to AuthenticationUtils
. This is not super elegant, but my understanding is that we slowly but surely switch towards block editor, so I decided not to add any new logic related to it. But maybe there is some simple way to fix it, that I'm missing?
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.
Yes, but
AztecEditorFragment
is part of the Editor submodule, so It has no access toAuthenticationUtils
.
Right, I forgot about that minor detail. 🤦♂
String token = mAccountStore.getAccessToken(); | ||
if (mSite.isPrivate() && WPUrlUtils.safeToAddWordPressComAuthToken(url) | ||
&& !TextUtils.isEmpty(token)) { | ||
authHeader = "Bearer " + token; | ||
authHeaders.put(AuthenticationUtils.AUTHORIZATION_HEADER_NAME, "Bearer " + token); | ||
} |
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.
In AuthenticationUtils
when safeToAddWordPressComAuthToken
is false
we try to use HTTP auth credentials, and it's not clear to me why we don't do that here. Similarly, we're checking mSite.isPrivate()
here, but we don't check that in the AuthenticationUtils
.
I know this isn't anything you changed, I'm just curious if you know why there's the difference. If you do know why they are different, it might be useful to move this logic into a method in AuthenticationUtils
with some explanation about why the two methods are different. This is not anything that needs to block this PR.
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'm not 100% sure about the difference there, but as far as I'm aware, AuthenticationUtils
is mostly used with image loading, and requests that actually get to it are subject to isPrivate()
check since it's related to Photon/https (I have only surface level of knowledge there).
I'm not sure why we are not using HTTP auth credentials in the block editor, but since it's not broken I would rather not touch 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.
I'm not sure why we are not using HTTP auth credentials in the block editor, but since it's not broken I would rather not touch it :)
I think that makes sense. Obviously it would be nice to figure out the cause of the inconsistency, but I don't think it's something we have to do now.
I think this looks good @khaykov . 👍 I just had a couple of small comments, and they may not even require any changes. Also, it's not clear to me why we're making this change, would you mind explaining a bit about why we're making this change? |
…ss-Android into feature/support-multiple-auth-headers-in-gb # Conflicts: # libs/gutenberg-mobile
You can trigger optional UI/connected tests for these changes by visiting CircleCI here. |
@mchowning Thanks for taking a look at this one! I'm doing it so we can add an extra header for the upcoming private Atomic sites support. A cookie is used there to retrieve private media, but in an unorthodox way (same as a token, without using Set-Cookie header, so we can't use a cookie jar). |
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.
Looks good! Nice work! 👍
Just a reminder that we need to update the gutenberg-mobile submodule ref now that the GB-side changes have been merged. |
Updated the GB reference 👍 |
Double checked with the update, and everything is working great! |
This PR addresses changes in GB side to allow multiple headers to be passed to editor's `OkHttpHeaderInterceptor.
GB sitde changes are here.
To test:
PR submission checklist:
RELEASE-NOTES.txt
if necessary.