Hi Denuwanthi and All,
When I do a POST request via, postman the special characters are rendered
> fine.
> Seems like this is happening with the ajax call
The reason for encoded payload is that when you perform jQuery $.ajax
default contentType is "application/x-www-form-urlencoded" which mean
%24 is the HTML block representation of $ [1]. Browser / AJAX library
should be doing this conversion before sending data to server. It might
have been transparent to us before, but since service logic itself is
handling the ByteBuffer now, it might be necessary to do the HTML decoding
separately.
Hi Denuwanthi,
The value seems to be url encoded.
Thanks,
On Fri, Mar 24, 2017 at 6:44 AM, Denuwanthi De Silva
wrote:
> When I do a POST request via, postman the special characters are rendered
> fine.
> Seems like this is happening with the ajax call
>
> On Fri, Mar 24,
When I do a POST request via, postman the special characters are rendered
fine.
Seems like this is happening with the ajax call
On Fri, Mar 24, 2017 at 5:02 PM, Denuwanthi De Silva
wrote:
> Hi,
>
> As discussed offline I used the msf4j Reuest object in my microservice
>
>
Hi,
As discussed offline I used the msf4j Reuest object in my microservice
@POST
@Path("/validatePassword")
public Response isValidPassword(@Context Request password) {
Then I tried retreving a char[] out of it as following
ByteBuffer fullContent =
Hi Jude,
I think you got me wrong. StringBuilder internally uses char[] to store
values (mutable sequence of characters [1] [2]). Therefore, we will not be
creating (and leaving behind) immutable String objects as long as we use
the StringBuilder properly.
However, if you accidentally call a
>
> We just need to avoid using any method that accepts or returns a String in
> StringBuilder,
> to avoid intermediate level Strings.
I believe you are well aware about why the Strings and other sort of
objects being discouraged to be used for passwords and other valuable
information. It
Yes. That seems to address the requirement.
We can accept InputStream as a parameter and then use the input stream to
read characters into a StringBuilder. I hope this was what you were
suggesting and this is supported with MSF4J.
We just need to avoid using any method that accepts or returns a
Hi All,
AFAIU char[] is not compliant with neither QueryParam nor FormParam
according to [1]. Therefore from MSF4J (as a JAXRS engine) IMHO we couldn't
support char[].
What if we use StringBuilder instead of String. Then we can delete the
StringBuilder as we want. WDYT?
[1] -
Hi,
I have a micro service which calls a password validation back end.
For that, it passes the password as microservice parameter.
Due to security concerns we need to pass password as a char array instead
of a String[1].
The password value is retrieved using jquery input field call and passed
10 matches
Mail list logo