-
Notifications
You must be signed in to change notification settings - Fork 49
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
additionalHeaders not working as expected #37
Comments
@JuBan1 Thank you for your suggestions! After checking, I also confirmed that However, I am currently focused on resolving the JsBridge and other issues, so it may take some time before I can start working on this particular problem. If you are interested, you are welcome to submit a PR for the Android and iOS implementation. For the Desktop side, I think @DatL4g would be happy to provide assistance. |
I think a good first step would be to figure out what the goal should be. (1) and (2) are easy to implement, but are lacking. For my purposes I would need at least (3), but after thinking about it a little it might be a better idea to basically implement shouldOverrideUrlLoading. That allows users to intelligently add headers to all requests but also do things like intercept certain URLs or prevent certain domains. I'm thinking users can add an |
I agree with you. I think |
Adding a We had that problem before (user-agent) and we (or I) have to reimplement the default behavior in and make setting a Additionally this doesn't only break the ``onBeforeBrowse` implementation, it breaks all request handling methods. I don't have that much time currently as I'm in a release phase right now, best would be to add it directly to KCEF so we don't have to deal with it in this library, maybe you could add a PR if you have time or we have to wait until I have time again (could be anytime in December). |
Hey, thanks for tackling this @KevinnZou! I have a half-finished implementation as well, and I got stuck on the desktop implementation too. So that strengthens @DatL4g's point of moving it into KCEF if possible. Unfortunately I think I'm a little out of my depth there :) I pushed my implementation into a PR for inspiration. (Warning: nothing is finished in there!) I have had more luck with overriding Besides, I've discovered a few more problems:
The only thing I am happy about is the RequestInterceptor and how it is used. I think it is a good interface for users to work with. On a side note, (K)CEF provides a CEFRequestHandlerAdapter that has default-implementations for all methods, meaning you don't have to do that yourself |
@JuBan1 Thank you for your great work! I really appreciate your idea for RequestResult.Modify, it eliminates the need for users to manually reload the URL. I will incorporate your ideas into my implementation, as they are extremely helpful to me. Regarding the issues you mentioned, I will collaborate with @DatL4g to see whether the Authorization header problem can be solved. Additionally, I also observed that Generally, I think we should be able to support Android and iOS first. As for the Desktop side, I will attempt to address the Thanks for your contribution again! I will continue to update the progress here, and you are welcome to review it. |
@DatL4g Thanks for your explanation! I have submitted an issue to KCEF. I will try to solve it first and update the progress within that issue. |
@DatL4g I briefly looked at the implementation of
Can you provide more detailed instructions for this paragraph? I'm not sure where your default |
@JuBan1 Regarding |
@KevinnZou That's right, you have to dig a bit deeper, the The problem here is that this overrides the default behavior/methods since the So we basically need a extendable RequestContext class which defaults to Then we can add features like #12 again and much more |
@DatL4g Thanks for your explanation! I think I understood why we need an extendable RequestContext. However, I'm a bit concerned that I might make mistakes since I'm not very familiar with it. I want to ensure that the code modifications are done accurately. Thus, I would prefer to leave it to you to handle the changes when you have some free time. In the meantime, I will continue working on the JSBridge implementation. Please let me know if there's anything I can do to assist you. Thank you for your contribution again! |
I'm not sure if this mechanism makes sense for The request interceptor gives the impression that I can Allow/Reject/Redirect this request, but Reject/Redirect changes the webview's main url, not the request that triggered the interceptor. It seems to me that this is ultimately confusing and not very useful. I would say it's better to use
|
@JuBan1 Thanks for your suggestions! I understand your concern,
In my opinion, I would prefer the second option. For the first choice, developers are unsure which requests can be intercepted and which cannot, making it unsuitable for production use. The second option is not ideal, but it can at least intercept all requests. What do you think? |
@DatL4g Are there any updates? |
@JuBan1 I reported a bug regarding the Thus, regarding the previous discussion, we may have to make a choice:
Do you have any suggestions? |
Hi all, I have implemented a basic interception in the latest version 1.9.8. Please follow these instructions to conduct a test and let me know if you encounter any issues. |
The doc of
rememberWebViewState
states:It seems the bolded part isn't actually true. The headers are passed along via the initial
WebContent.Url
object, but discarded when navigating inside the webview or usingnavigator.loadUrl()
.I tried it by attaching an Authorization header to a request; the initial request worked, subsequent requests were rejected.
I can see a few options here:
navigator.loadUrl()
call. That would apply the headers to all requests created via the navigator, but not to requests created by the webview itself.My personal, related issue: I want to attach an Authorization header to all requests (if possible, only requests to a certain domain). I think at the moment this is impossible.
Tested using 1.6.0 and Android, but I think the current master works the same (except that additionalHeaders don't work for desktop at all in 1.6.0).
Thanks for stepping up to build and maintain an KMP webview! 💪
The text was updated successfully, but these errors were encountered: