Did 1.4.0 introduce a "breaking change" ?

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Did 1.4.0 introduce a "breaking change" ?

Andre
Folks,

I was looking at the upgrade process from 1.3.x to 1.4.0 and it seems to me
we introduced a breaking change around the authorizations?

When I look at the 1.4.0 authorizers.xml and its version 1.3.0 there's a
massive discrepancy on the XML tree and the existing 1.3.x version does not
seem to work out of the box on 1.4.0 ?

Looking at the docs I couldn't find evidence of the migration being fully
documented? I suspect users may be able to find their way by adjusting the
instructions for the 0.x upgrade, but shouldn't we have clear instructions
on the upgrade from 1.3.x to 1.4.0?

Cheers
Reply | Threaded
Open this post in threaded view
|

Re: Did 1.4.0 introduce a "breaking change" ?

Matt Gilman
Andre,

While 1.4.0 introduces a more granular authorizers configuration, the existing 1.3.0 configurations should still be valid. What was breaking for you?

Matt

Sent from my iPhone

> On Oct 30, 2017, at 10:24 PM, Andre <[hidden email]> wrote:
>
> Folks,
>
> I was looking at the upgrade process from 1.3.x to 1.4.0 and it seems to me
> we introduced a breaking change around the authorizations?
>
> When I look at the 1.4.0 authorizers.xml and its version 1.3.0 there's a
> massive discrepancy on the XML tree and the existing 1.3.x version does not
> seem to work out of the box on 1.4.0 ?
>
> Looking at the docs I couldn't find evidence of the migration being fully
> documented? I suspect users may be able to find their way by adjusting the
> instructions for the 0.x upgrade, but shouldn't we have clear instructions
> on the upgrade from 1.3.x to 1.4.0?
>
> Cheers
Reply | Threaded
Open this post in threaded view
|

Re: Did 1.4.0 introduce a "breaking change" ?

Andre
Matt,

I did some investigation and it seems like if you simply copy the old
authorizers.xml into the new setup NiFi fails with

ERROR [main] o.s.web.context.ContextLoader Context initialization failed
org.springframework.beans.factory.BeanCreationException: Error creating
bean with name 'niFiWebApiSecurityConfiguration': Injection of autowired
dependencies failed; nested exception is
org.springframework.beans.factory.BeanCreationException: Could not autowire
method: public void
org.apache.nifi.web.NiFiWebApiSecurityConfiguration.setOtpAuthenticationProvider(org.apache.nifi.web.security.otp.OtpAuthenticationProvider);
nested exception is
org.springframework.beans.factory.BeanCreationException: Error creating
bean with name 'otpAuthenticationProvider' defined in class path resource
[nifi-web-security-context.xml]: Cannot resolve reference to bean
'authorizer' while setting constructor argument; nested exception is
org.springframework.beans.factory.BeanCreationException: Error creating
bean with name 'authorizer': FactoryBean threw exception on object
creation; nested exception is java.lang.Exception: The specified authorizer
'managed-authorizer' could not be found.

And similar errors for JWT as well.

Given that populating the new authorizers.xml with the <authorizer> element
from the old authorizers.xml seems to solve the issue, seems to me like we
expect the file to contain references to the new authorizers syntax
despite using the legacy syntax?

Doesn't seem to be a show stopper but I reckon we should document it.

Cheers



On Tue, Oct 31, 2017 at 1:43 PM, Matt Gilman <[hidden email]>
wrote:

> Andre,
>
> While 1.4.0 introduces a more granular authorizers configuration, the
> existing 1.3.0 configurations should still be valid. What was breaking for
> you?
>
> Matt
>
> Sent from my iPhone
>
> > On Oct 30, 2017, at 10:24 PM, Andre <[hidden email]> wrote:
> >
> > Folks,
> >
> > I was looking at the upgrade process from 1.3.x to 1.4.0 and it seems to
> me
> > we introduced a breaking change around the authorizations?
> >
> > When I look at the 1.4.0 authorizers.xml and its version 1.3.0 there's a
> > massive discrepancy on the XML tree and the existing 1.3.x version does
> not
> > seem to work out of the box on 1.4.0 ?
> >
> > Looking at the docs I couldn't find evidence of the migration being fully
> > documented? I suspect users may be able to find their way by adjusting
> the
> > instructions for the 0.x upgrade, but shouldn't we have clear
> instructions
> > on the upgrade from 1.3.x to 1.4.0?
> >
> > Cheers
>
Reply | Threaded
Open this post in threaded view
|

Re: Did 1.4.0 introduce a "breaking change" ?

Matt Gilman
Andre,

Based on the error, it looks like you've retained your existing
authorizers.xml but upgraded the nifi.security.user.authorizer property in
your nifi.properties. These two are related. The authorizers.xml
file defines the available Authorizers (and now UserGroupProviders and
AccessPolicyProviders). The nifi.security.user.authorizer property in
nifi.properties defines which authorizer to use (via the identifier) from
the authorizers.xml file. If you want to retain your existing
authorizers.xml you'll want to keep that property unchanged as well.

I'll add a note in the migration guide to make sure this is clear.

Thanks

Matt

On Tue, Oct 31, 2017 at 12:05 AM, Andre <[hidden email]> wrote:

> Matt,
>
> I did some investigation and it seems like if you simply copy the old
> authorizers.xml into the new setup NiFi fails with
>
> ERROR [main] o.s.web.context.ContextLoader Context initialization failed
> org.springframework.beans.factory.BeanCreationException: Error creating
> bean with name 'niFiWebApiSecurityConfiguration': Injection of autowired
> dependencies failed; nested exception is
> org.springframework.beans.factory.BeanCreationException: Could not
> autowire
> method: public void
> org.apache.nifi.web.NiFiWebApiSecurityConfiguration.
> setOtpAuthenticationProvider(org.apache.nifi.web.security.
> otp.OtpAuthenticationProvider);
> nested exception is
> org.springframework.beans.factory.BeanCreationException: Error creating
> bean with name 'otpAuthenticationProvider' defined in class path resource
> [nifi-web-security-context.xml]: Cannot resolve reference to bean
> 'authorizer' while setting constructor argument; nested exception is
> org.springframework.beans.factory.BeanCreationException: Error creating
> bean with name 'authorizer': FactoryBean threw exception on object
> creation; nested exception is java.lang.Exception: The specified authorizer
> 'managed-authorizer' could not be found.
>
> And similar errors for JWT as well.
>
> Given that populating the new authorizers.xml with the <authorizer> element
> from the old authorizers.xml seems to solve the issue, seems to me like we
> expect the file to contain references to the new authorizers syntax
> despite using the legacy syntax?
>
> Doesn't seem to be a show stopper but I reckon we should document it.
>
> Cheers
>
>
>
> On Tue, Oct 31, 2017 at 1:43 PM, Matt Gilman <[hidden email]>
> wrote:
>
> > Andre,
> >
> > While 1.4.0 introduces a more granular authorizers configuration, the
> > existing 1.3.0 configurations should still be valid. What was breaking
> for
> > you?
> >
> > Matt
> >
> > Sent from my iPhone
> >
> > > On Oct 30, 2017, at 10:24 PM, Andre <[hidden email]> wrote:
> > >
> > > Folks,
> > >
> > > I was looking at the upgrade process from 1.3.x to 1.4.0 and it seems
> to
> > me
> > > we introduced a breaking change around the authorizations?
> > >
> > > When I look at the 1.4.0 authorizers.xml and its version 1.3.0 there's
> a
> > > massive discrepancy on the XML tree and the existing 1.3.x version does
> > not
> > > seem to work out of the box on 1.4.0 ?
> > >
> > > Looking at the docs I couldn't find evidence of the migration being
> fully
> > > documented? I suspect users may be able to find their way by adjusting
> > the
> > > instructions for the 0.x upgrade, but shouldn't we have clear
> > instructions
> > > on the upgrade from 1.3.x to 1.4.0?
> > >
> > > Cheers
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: Did 1.4.0 introduce a "breaking change" ?

Andre
Matt,

Yes. It seems to be the case. Reason being the Config Mgmt techniques used
to populate the files are different.

Cheers

On Wed, Nov 1, 2017 at 12:07 AM, Matt Gilman <[hidden email]>
wrote:

> Andre,
>
> Based on the error, it looks like you've retained your existing
> authorizers.xml but upgraded the nifi.security.user.authorizer property in
> your nifi.properties. These two are related. The authorizers.xml
> file defines the available Authorizers (and now UserGroupProviders and
> AccessPolicyProviders). The nifi.security.user.authorizer property in
> nifi.properties defines which authorizer to use (via the identifier) from
> the authorizers.xml file. If you want to retain your existing
> authorizers.xml you'll want to keep that property unchanged as well.
>
> I'll add a note in the migration guide to make sure this is clear.
>
> Thanks
>
> Matt
>
> On Tue, Oct 31, 2017 at 12:05 AM, Andre <[hidden email]> wrote:
>
> > Matt,
> >
> > I did some investigation and it seems like if you simply copy the old
> > authorizers.xml into the new setup NiFi fails with
> >
> > ERROR [main] o.s.web.context.ContextLoader Context initialization failed
> > org.springframework.beans.factory.BeanCreationException: Error creating
> > bean with name 'niFiWebApiSecurityConfiguration': Injection of autowired
> > dependencies failed; nested exception is
> > org.springframework.beans.factory.BeanCreationException: Could not
> > autowire
> > method: public void
> > org.apache.nifi.web.NiFiWebApiSecurityConfiguration.
> > setOtpAuthenticationProvider(org.apache.nifi.web.security.
> > otp.OtpAuthenticationProvider);
> > nested exception is
> > org.springframework.beans.factory.BeanCreationException: Error creating
> > bean with name 'otpAuthenticationProvider' defined in class path resource
> > [nifi-web-security-context.xml]: Cannot resolve reference to bean
> > 'authorizer' while setting constructor argument; nested exception is
> > org.springframework.beans.factory.BeanCreationException: Error creating
> > bean with name 'authorizer': FactoryBean threw exception on object
> > creation; nested exception is java.lang.Exception: The specified
> authorizer
> > 'managed-authorizer' could not be found.
> >
> > And similar errors for JWT as well.
> >
> > Given that populating the new authorizers.xml with the <authorizer>
> element
> > from the old authorizers.xml seems to solve the issue, seems to me like
> we
> > expect the file to contain references to the new authorizers syntax
> > despite using the legacy syntax?
> >
> > Doesn't seem to be a show stopper but I reckon we should document it.
> >
> > Cheers
> >
> >
> >
> > On Tue, Oct 31, 2017 at 1:43 PM, Matt Gilman <[hidden email]>
> > wrote:
> >
> > > Andre,
> > >
> > > While 1.4.0 introduces a more granular authorizers configuration, the
> > > existing 1.3.0 configurations should still be valid. What was breaking
> > for
> > > you?
> > >
> > > Matt
> > >
> > > Sent from my iPhone
> > >
> > > > On Oct 30, 2017, at 10:24 PM, Andre <[hidden email]> wrote:
> > > >
> > > > Folks,
> > > >
> > > > I was looking at the upgrade process from 1.3.x to 1.4.0 and it seems
> > to
> > > me
> > > > we introduced a breaking change around the authorizations?
> > > >
> > > > When I look at the 1.4.0 authorizers.xml and its version 1.3.0
> there's
> > a
> > > > massive discrepancy on the XML tree and the existing 1.3.x version
> does
> > > not
> > > > seem to work out of the box on 1.4.0 ?
> > > >
> > > > Looking at the docs I couldn't find evidence of the migration being
> > fully
> > > > documented? I suspect users may be able to find their way by
> adjusting
> > > the
> > > > instructions for the 0.x upgrade, but shouldn't we have clear
> > > instructions
> > > > on the upgrade from 1.3.x to 1.4.0?
> > > >
> > > > Cheers
> > >
> >
>