-
Notifications
You must be signed in to change notification settings - Fork 279
BASIC Authentication scheme assume that crdential are encoded with ISO-8859-1 #1455
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
Comments
As a turn around, we can inject the charset preference with this turn around when generating the ChallengeRequest in the Authenticator class:
By the way it appears thet HttpBasicHelper ignore the parameters added to the ChallengeRequest, the following code is useless: cr.getParameters().add("charset", "UTF-8"); (I know that except "charset" and "realm" there is no other parameter existing for a BASIC but this could have been useful to manage them.) And to correctly decode the credential we can add the following code after retreiving the ChallengeResponse:
|
Thanks Marc for the detailled issue. This chartset parameters was added in 2015 with this RFC 7617 and never supported by Restlet Framework. As part of a branch that I'm working on right now, I have enhanced the code to support charset="UTF-8": Could you test this revised HttpBasicHelper.java class and let me know if it works as expected? Added @thboileau for visibility. |
Sorry for the delay... I am testing it today ! |
I am afraid that it does not work completely, On a request without challenge the server add correctly the charset parameter. On the client side the Client encode the credential in utf-8 correctly to. The problem come when the server get the request with the correct credential... the RFC 7617 is... let say... tricky, because the client request does not contain any information about the charset used to encode the raw value of the Authorization... so the HttpBasicHelper class the legacy charset. the AuthenticatorUtils.parseResponse method create the ChallenceResponse with the schema and the raw value and call the helper in a raw, so there is no way to add the parameter to the it before it is pass to the helper. |
Here is the test code I used, for the Client part:
Adding the charset parameter to the challenge response allow to the HttpBasicHelper to encode the crendential in UTF-8. (But the parameter is not sent through the HTTP call, as the RFC decribe it...) And for the server side:
|
* Added MultiPartFormDataRepresentation Added MultiPartFormDataRepresentation to Jetty extension to support generation and parsing. * Added support for the "charset" parameter in HTTP BASIC challenges See issue #1455 * Removed unused imports * Update changes.md * Update MultiPartFormDataRepresentation.java Added "location" parameter to help set a useful MultiPartConfig in addition to the default Jetty values * HttpBasic test refacto * HttpBasicHelper: fix potential NPE * HttpBasicHelper: fix potential NPE * Added tests cases for multipart * Added logic to duplicate MediaType along with the addition of parameter * Enhanced MultiPartFormDataRepresentation Cleanup behavior to generate random boundary just before its usage and only when needed. Added method to create a Part based on a Representation * Update MultiPartFormDataRepresentation.java Cleanup behavior to generate random boundary just before its usage and only when needed. Added method to create a Part based on a Representation * Fixed boundary setting issue and adjusted test case * Renamed MultiPartFormDataRep to MultiPartRep Eventually the logic could be reused for related media types * Update MultiPartRepresentation.java * Fixed multipart parsing logic Also added related unit test * Update changes.md * Update org.restlet.java/org.restlet.ext.jetty/src/main/java/org/restlet/ext/jetty/MultiPartRepresentation.java Co-authored-by: Thierry Boileau <thboileau@gmail.com> * Update org.restlet.java/org.restlet.ext.jetty/src/main/java/org/restlet/ext/jetty/MultiPartRepresentation.java Co-authored-by: Thierry Boileau <thboileau@gmail.com> * Update org.restlet.java/org.restlet.ext.jetty/src/main/java/org/restlet/ext/jetty/MultiPartRepresentation.java Co-authored-by: Thierry Boileau <thboileau@gmail.com> * Update org.restlet.java/org.restlet.ext.jetty/src/main/java/org/restlet/ext/jetty/MultiPartRepresentation.java Co-authored-by: Thierry Boileau <thboileau@gmail.com> --------- Co-authored-by: Jerome Louvel <374450+jlouvel@users.noreply.github.com> Co-authored-by: Thierry Boileau <thboileau@gmaiil.com>
I do not know if this is a deliberated choice or not, but we have discovered that the BASIC Authenticate HTTP header is decoded with the ISO-8859-1 charset avoiding the usage of non Latin character in the login and password when using this schema, in the org.restlet.engine.security.HttpBasicHelper class.
The code is coherent because the same charset is used to encode too, but it appears to give some problems to non-european people... As I said I do not know if this issue should be viewed as a bug or an enhancement request, but there is a optional parameter allowing for the server to indicate a preference for an UTF-8 encoding:
https://www.rfc-editor.org/rfc/rfc7617.html#section-2.1
It could be great if some parameter could be retrieved by HttpBasicHelper to insert this parameter and then use UTF-8 to encode and decode the header...
The text was updated successfully, but these errors were encountered: