juneau-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Bognar <jamesbog...@gmail.com>
Subject Re: Security
Date Tue, 14 Nov 2017 10:57:39 GMT
That’s awesome!

If you’re only using the JSON marshaling, you’ll only need to pull in
juneau-marshall.  There are no prereqs other than Java 7.

If you hit any snags, I’d be more than happy to help.

James



On Tue, Nov 14, 2017 at 5:00 AM Lukasz Lenart <lukaszlenart@apache.org>
wrote:

> Nice :) json-lib for the same JSON will throw OOM :P
>
> I think we (Struts) will switch to this implementation, thank you for all
> your answers and keep up the good work!
>
>
> Cheers
> Lukasz
>
> On 2017-11-13 15:48, James Bognar <jamesbognar@apache.org> wrote:
> > That fails in ~130ms with the following exception...
> >
> > org.apache.juneau.parser.ParseException: Parse exception occurred at
> > {currentClass:'Object',line:1,column:61}.  Remainder after parse: ':'.
> > at
> >
> org.apache.juneau.json.JsonParserSession.validateEnd(JsonParserSession.java:744)
> > at
> >
> org.apache.juneau.json.JsonParserSession.doParse(JsonParserSession.java:88)
> > at
> org.apache.juneau.parser.ParserSession.parseInner(ParserSession.java:509)
> > at org.apache.juneau.parser.ParserSession.parse(ParserSession.java:465)
> > at org.apache.juneau.parser.Parser.parse(Parser.java:423)
> > at org.apache.juneau.json.Temp.main(Temp.java:26)
> >
> >
> > If a StackOverflowError occurs, we catch it and rethrow a "Depth too
> deep.
> > Stack overflow occurred." parse exception.  That doesn't happen in this
> > case though since it's only 56-levels deep, and each level is only two
> > stack entries deep.
> >
> > If I do a repeated pattern like "{a:" x 2500, it causes a
> > StackOverflowError in about 160ms.
> >
> > It would be possible to add a max-depth setting just like what's
> available
> > on the Serializer side.  However, I don't think depth is a concern.
> We're
> > not consuming memory on each recursion, so stack-overflows should not
> cause
> > system instability.  My larger concern would be OutOfMemoryErrors caused
> by
> > parsing a very large string or many medium sized ones.
> >
> >
> >
> > On Mon, Nov 13, 2017 at 8:36 AM, Lukasz Lenart <lukaszlenart@apache.org>
> > wrote:
> >
> > > On 2017-11-10 18:47, James Bognar <jamesbognar@gmail.com> wrote:
> > > > However, we don't have any limiters in place to prevent you from, for
> > > > example, creating an infinitely long String field (other than the
> > > built-in
> > > > limitations on the StringBuilder class itself which is limited by an
> > > int).
> > > >
> > > > I'm thinking it can be solved at the REST servlet interface with a
> > > > BoundedReader (
> > > > https://commons.apache.org/proper/commons-io/javadocs/
> > > api-2.5/org/apache/commons/io/input/BoundedReader.html).
> > > > The parsers themselves wouldn't need to be changed.
> > > >
> > > > Thoughts anyone?  What would be an appropriate default size limit on
> the
> > > > input?  100MB?
> > >
> > > I'm not sure if this will help, try to parse this string:
> > >
> > > {{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{{}:1}
> > > :1}:1}:1}:1}:1}:1}:1}:1}:1}:1}:1}:1}:1}:1}:1}:1}:1}:1}:1}:1}
> > > :1}:1}:1}:1}:1}:1}}:1}:1}:1}:1}:1}:1}:1}:1}:1}:1}:1}:1}:1}:
> > > 1}:1}:1}:1}:1}:1}:1}:1}:1}:1}:1}:1}:1}:1}
> > >
> > > Regards
> > > Lukasz
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message