Ok taking care of the Form params with CustomFormEncodingProvider
by stepping on the populateMap.
public class CustomFormEncodingProvider extends FormEncodingProvider
Trying this now..
The queryHandler is less clear which base class to use for a provider,
could you tell which one handles it by default?
Try the custom RequestHandler filter
Also, please email me when the core utils' fixes are released
(if you are the one to know this)
2.2.6-SNAPSHOT should be available shortly
Thanks,
-Vitaly
Sergey Beryozkin-2 wrote:
It looks to me that there are two places at least where this needs to be
fixed:
1. the JAXRSUtils line 926 - the key needs to be decoded
currently:
queries.add(values[0], value);
fix would be:
queries.add(HttpUtils.urlDecode(values[0]), value);
Yes, fixed on mainline
2. Somewhere in the JAXRS UNMARSHAL phase we need to decode form params
looks like before or inside the JAXRSInInterceptor.
Do you mean form parameter names ? If yes then it's also fixed now. The
values are already decoded by default.
Do you know how can I replace JAXRSUtils with my version until the Fix is
made in CXF itself?
Why would you need to do it ? Registering custom RequestHandler will
wprovide a temp fix for the issue with decoding query names.
There're couple of workarounds for dealing with encoded form parameter
names too. The simplest one is to register a custom JAX-RS
provider for handling form submissions (see FormEncodingProvider). A more
involved approach is to register a servlet filter and
consume the request body and set form name/value pairs as http request
parameters, something Spring Security does for ex in some
cases...
cheers, Sergey
Thanks,
-Vitaly
Sergey Beryozkin-2 wrote:
Thanks Sergey,
Could you tell how to register a custom requestFilter - I have not done
that
yet..
You can register it as a regular jaxrs:provider.
cheers, Sergey
Sergey Beryozkin-2 wrote:
Hi,
If you're referring to the fact that you can not use say a JAXRS
QueryParam("principal.password") then yes, it's a bug which will be
fixed shortly...At the moment only the values are decoded (by
default).
Assuming it is the case, the workaround is to register a
custom RequestFilter which will replace the current Message's
QUERY_STRING
as needed for QueryParam("principal.password") (or for
QueryParam("")) work well . Is it something you'd consider ?
cheers Sergey
Example Flex code using HTTPService:
var params:Object = {};
params["principal.username"] = this.idUsername.text;
params["password"] = this.idPassword.text;
svcRequest.url = this.idUrl.text + "/services/v1/rest/Auth/login";
svcRequest.send(params);
The above produces this HTTP request on the wire:
GET
/services/v1/rest/Auth/login?principal%2Eusername=dude&password=1234
HTTP/1.1
The CXF server side expecting principal.username fails to undecode
and
as
a
result principal
object is not initialized.
Any ideas?
Thanks,
-Vitaly
--
View this message in context:
http://old.nabble.com/Adobe-Flex-HTTPService-escapes-dot-with--2e-breaking-CXF-logic-on-the-server-tp26719627p26719627.html
Sent from the cxf-user mailing list archive at Nabble.com.
--
View this message in context:
http://old.nabble.com/Adobe-Flex-HTTPService-escapes-dot-with--2e-breaking-CXF-logic-on-the-server-tp26719627p26728068.html
Sent from the cxf-user mailing list archive at Nabble.com.
--
View this message in context:
http://old.nabble.com/Adobe-Flex-HTTPService-escapes-dot-with--2e-breaking-CXF-logic-on-the-server-tp26719627p26731299.html
Sent from the cxf-user mailing list archive at Nabble.com.
--
View this message in context:
http://old.nabble.com/Adobe-Flex-HTTPService-escapes-dot-with--2e-breaking-CXF-logic-on-the-server-tp26719627p26732567.html
Sent from the cxf-user mailing list archive at Nabble.com.
