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 <[email protected]> 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 <[email protected]> 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 <[email protected]> > > 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 <[email protected]> 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 > > > > > >
