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 <denuwan...@wso2.com>
wrote:
> 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 = BufferUtil.merge(password.getFullMessageBody());
> char[] passwordText = Charset.defaultCharset().decode(fullContent).array()
>
>
> But the returned contains different values for special characters.
>
> For example, the actual password I gave was ABCabc01*$*
> Then the value retreved in the microservice is ABCabc01
>
> *%24*
> Is there a way we can handle this?The password is sent from frontendside
> to backedn via an ajax call
>
> var password = $("#newPassword").val();
> $.ajax({
> type: "POST",
> url:
> "/admin-portal/root/apis/passwordUtil-micro-service/validatePassword",
> data: {newPassword: password},
>
>
>
>
>
> Thanks
>
> On Thu, Mar 23, 2017 at 9:54 PM, Ayoma Wijethunga <ay...@wso2.com> wrote:
>
>> 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 method such as
>> stringBuilder.toString() or stringBuilder.append(String str) you will end
>> up creating a immutable String in the memory. This is what I was trying to
>> imply with my sentence.
>>
>> We should not really depend on garbage collection for any data structure
>> storing passwords. If we are going to depend on GC for Arrays, there is no
>> point of *not* using String. Instead, since "char" is a mutable
>> primitive, it's possible to change the value to as desired (where as
>> Strings are immutable). Therefore, after storing password in a char[] or a
>> StringBuilder (which internally uses a char[]) you should clear the data,
>> before leaving the reference for GC to pickup, to make sure memory is
>> clean.
>>
>> However there is one issue associated with using StringBuilder for
>> password storage. StringBuilder has a mechanism used to grow the char[]
>> used internal, when such expansion is required
>> (AbstractStringBuilder.expandCapacity). This can leave behind arrays
>> that are not properly cleared in memory. This too can be addressed by
>> setting proper initialCapacity when creating StringBuilder.
>>
>> Anyhow, during offline discussion we identified that why Thusitha
>> suggested StringBuilder here was because, MSF4J by default
>> supports StringBuilder as a parameter type. However, with further checking
>> we identified that this StringBuilder is creating using Strings in MSF4J
>> level. Therefore, instead of going through the StringBuilder approach, we
>> will be directly using Byte stream of the request to ready passwords out
>> into char[] which is much clearer and does not introduce any immutable
>> Strings.
>>
>> [1] https://docs.oracle.com/javase/7/docs/api/java/lang/Stri
>> ngBuilder.html
>> [2] http://developer.classpath.org/doc/java/lang/StringBuild
>> er-source.html
>>
>> Best Regards,
>> Ayoma.
>>
>>
>> On Thu, Mar 23, 2017 at 9:19 PM, Jude Niroshan <jude.nirosha...@gmail.com
>> > wrote:
>>
>>> 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 simply not to retain any information anywhere in heap or
>>> other intermediate volatile memory. Arrays can be quickly garbage collected
>>> and that valuable information can not be extracted again.
>>>
>>> http://stackoverflow.com/q/8881291/4506140
>>>
>>> Hope it helps :)
>>>
>>> Regards,
>>> Jude
>>>
>>>
>>> On Thu, Mar 23, 2017 at 3:42 PM, Ayoma Wijethunga <ay...@wso2.com>
>>> wrote:
>>>
>>>> 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 String
>>>> in StringBuilder, to avoid intermediate level Strings.
>>>>
>>>> Best Regards,
>>>> Ayoma.
>>>>
>>>> On Thu, Mar 23, 2017 at 3:17 PM, Thusitha Thilina Dayaratne <
>>>> thusit...@wso2.com> wrote:
>>>>
>>>>> 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] - http://docs.oracle.com/javaee/7/api/javax/ws/rs/FormParam.html
>>>>>
>>>>> Thanks
>>>>>
>>>>> On Thu, Mar 23, 2017 at 3:10 PM, Denuwanthi De Silva <
>>>>> denuwan...@wso2.com> wrote:
>>>>>
>>>>>> 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 as a char array.
>>>>>> Then it is passed to the microservice via an ajax call. But the
>>>>>> micorservice method Params does not support char[] type[1].
>>>>>>
>>>>>> Is there a way we can handle this without involving String type in
>>>>>> the intermediate level?
>>>>>>
>>>>>>
>>>>>>
>>>>>> [1]https://nvisium.com/blog/2016/03/31/secure-password-strings/
>>>>>> [2]https://jersey.java.net/apidocs/2.7/jersey/javax/ws/rs/Qu
>>>>>> eryParam.html
>>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> --
>>>>>> Denuwanthi De Silva
>>>>>> Senior Software Engineer;
>>>>>> WSO2 Inc.; http://wso2.com,
>>>>>> Email: denuwan...@wso2.com
>>>>>> Blog: https://denuwanthi.wordpress.com/
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Thusitha Dayaratne
>>>>> WSO2 Inc. - lean . enterprise . middleware | wso2.com
>>>>>
>>>>> Mobile +94712756809 <+94%2071%20275%206809>
>>>>> Blog alokayasoya.blogspot.com
>>>>> About http://about.me/thusithathilina
>>>>> <http://wso2.com/signature>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Ayoma Wijethunga
>>>> Software Engineer
>>>> Platform Security Team
>>>> WSO2, Inc.; http://wso2.com
>>>> lean.enterprise.middleware
>>>>
>>>> Mobile : +94 (0) 719428123 <+94+(0)+719428123>
>>>> Blog : http://www.ayomaonline.com
>>>> LinkedIn: https://www.linkedin.com/in/ayoma
>>>>
>>>> _______________________________________________
>>>> Dev mailing list
>>>> Dev@wso2.org
>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>>
>>>>
>>>
>>
>>
>> --
>> Ayoma Wijethunga
>> Software Engineer
>> Platform Security Team
>> WSO2, Inc.; http://wso2.com
>> lean.enterprise.middleware
>>
>> Mobile : +94 (0) 719428123 <+94+(0)+719428123>
>> Blog : http://www.ayomaonline.com
>> LinkedIn: https://www.linkedin.com/in/ayoma
>>
>> _______________________________________________
>> Dev mailing list
>> Dev@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>>
>
>
> --
> Denuwanthi De Silva
> Senior Software Engineer;
> WSO2 Inc.; http://wso2.com,
> Email: denuwan...@wso2.com
> Blog: https://denuwanthi.wordpress.com/
>
--
Denuwanthi De Silva
Senior Software Engineer;
WSO2 Inc.; http://wso2.com,
Email: denuwan...@wso2.com
Blog: https://denuwanthi.wordpress.com/
_______________________________________________
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev
