Should there be a sane limit on Strings in NiFI?

["Peter Wicks (pwicks)" <pw...@micron.com>]

I noticed yesterday that automatic ellipsis was not working for relationship names in the Connection Creation window (PR submitted in NIFI-6512). As part of my test I started playing around with submitting fairly long names for relationships in RouteOnAttribute.  This all worked with out issue on relationships with greater than 1000 characters.

This led me to wonder how other parts of NiFi deal with very long strings in the UI, such as the breadcrumb trail.

To bring an already long story to a close, I submitted a 200MB string as a Process Group name using Chrome’s developer tools to do a custom PUT.  NiFi happily accepted the 104857600 character long name! Of course, this means each call to load that process group fails spectacularly in Chrome with the whole UI thread dead, but otherwise NiFi just keeps running.

This is what led me to wonder if maybe we should have some constraints on the maximum size of these UI visible strings.

Thanks,
  Peter

Re: Should there be a sane limit on Strings in NiFI?

[ski n <ra...@gmail.com>]

Yes, it makes sense. But it shouldn't be too short as well. For example I
easily have RouteOnAttribute relationships with 1000+ characters.
(currently around 4000 is the longest).

Raymond

Op do 1 aug. 2019 om 17:05 schreef Joe Witt <jo...@gmail.com>:

> Peter,
>
> It certainly makes sense to prevent authorized users from doing obviously
> unreasonable things in places where such filters could be applied.  This is
> a good example of such a thing.
>
> Thanks
>
> On Thu, Aug 1, 2019 at 10:52 AM Peter Wicks (pwicks) <pw...@micron.com>
> wrote:
>
> > I noticed yesterday that automatic ellipsis was not working for
> > relationship names in the Connection Creation window (PR submitted in
> > NIFI-6512). As part of my test I started playing around with submitting
> > fairly long names for relationships in RouteOnAttribute.  This all worked
> > with out issue on relationships with greater than 1000 characters.
> >
> > This led me to wonder how other parts of NiFi deal with very long strings
> > in the UI, such as the breadcrumb trail.
> >
> > To bring an already long story to a close, I submitted a 200MB string as
> a
> > Process Group name using Chrome’s developer tools to do a custom PUT.
> NiFi
> > happily accepted the 104857600 character long name! Of course, this means
> > each call to load that process group fails spectacularly in Chrome with
> the
> > whole UI thread dead, but otherwise NiFi just keeps running.
> >
> > This is what led me to wonder if maybe we should have some constraints on
> > the maximum size of these UI visible strings.
> >
> > Thanks,
> >   Peter
> >
>

Re: Should there be a sane limit on Strings in NiFI?

[Joe Witt <jo...@gmail.com>]

Peter,

It certainly makes sense to prevent authorized users from doing obviously
unreasonable things in places where such filters could be applied.  This is
a good example of such a thing.

Thanks

On Thu, Aug 1, 2019 at 10:52 AM Peter Wicks (pwicks) <pw...@micron.com>
wrote:

> I noticed yesterday that automatic ellipsis was not working for
> relationship names in the Connection Creation window (PR submitted in
> NIFI-6512). As part of my test I started playing around with submitting
> fairly long names for relationships in RouteOnAttribute.  This all worked
> with out issue on relationships with greater than 1000 characters.
>
> This led me to wonder how other parts of NiFi deal with very long strings
> in the UI, such as the breadcrumb trail.
>
> To bring an already long story to a close, I submitted a 200MB string as a
> Process Group name using Chrome’s developer tools to do a custom PUT.  NiFi
> happily accepted the 104857600 character long name! Of course, this means
> each call to load that process group fails spectacularly in Chrome with the
> whole UI thread dead, but otherwise NiFi just keeps running.
>
> This is what led me to wonder if maybe we should have some constraints on
> the maximum size of these UI visible strings.
>
> Thanks,
>   Peter
>