[jira] [Created] (NIFI-6097) Upgrade jackson-databind direct dependencies
Nathan Gough created NIFI-6097: -- Summary: Upgrade jackson-databind direct dependencies Key: NIFI-6097 URL: https://issues.apache.org/jira/browse/NIFI-6097 Project: Apache NiFi Issue Type: Improvement Components: Security Reporter: Nathan Gough Assignee: Nathan Gough Upgrade the direct usages of com.fasterxml.jackson.core:jackson-databind in NiFi's maven poms to version 2.9.8. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (NIFI-6096) ValidateRecord does not handle nested Map type correctly
Joseph Percivall created NIFI-6096: -- Summary: ValidateRecord does not handle nested Map type correctly Key: NIFI-6096 URL: https://issues.apache.org/jira/browse/NIFI-6096 Project: Apache NiFi Issue Type: Bug Affects Versions: 1.9.0 Reporter: Joseph Percivall Attachments: Nested_map_record_failing_validation.xml When attempting to validate a map that was nested as such top-level record -> array of records -> value in record is a map, I hit the following error: "Value is of type org.apache.nifi.serialization.record.MapRecord but was expected to be of type MAP" This is the same error in NIFI-5678. Attached is a template to reproduce the error. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (NIFI-5678) ValidateRecord does not handle Map type correctly
[
https://issues.apache.org/jira/browse/NIFI-5678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16782454#comment-16782454
]
Joseph Percivall commented on NIFI-5678:
[~joewitt] yeah I debated about creating a new one but figured it may be that
the issue wasn't fixed and may need to be reopened. I'll go ahead and create a
new one.
> ValidateRecord does not handle Map type correctly
> -
>
> Key: NIFI-5678
> URL: https://issues.apache.org/jira/browse/NIFI-5678
> Project: Apache NiFi
> Issue Type: Bug
> Components: Extensions
>Reporter: Matt Burgess
>Assignee: Matt Burgess
>Priority: Major
> Fix For: 1.8.0
>
> Attachments: Nested_map_record_failing_validation.xml
>
>
> Consider the following Avro Schema:
> {code}
> {
> "name" : "test",
> "type" : "record",
> "fields" : [ {
> "name" : "field1",
> "type" : {
> "type" : "map",
> "values" : "string"
> }
> } ]
> }
> {code}
> and corresponding JSON data adhering to the schema:
> {code}
> [{
> "field1": {
> "toto" : "v1",
> "titi" : "v2"
> }
> }]
> {code}
> ValidateRecord marks the record as invalid though it should be valid. The
> message in the provenance event is "Record #1 is invalid due to:
> MapRecord[{toto=v1, titi=v2}] is not a valid value for /field1: Value is of
> type org.apache.nifi.serialization.record.MapRecord but was expected to be of
> type MAP[STRING]".
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] JPercivall commented on issue #2861: NIFI-5248 Added new Elasticsearch json and record processors.
JPercivall commented on issue #2861: NIFI-5248 Added new Elasticsearch json and record processors. URL: https://github.com/apache/nifi/pull/2861#issuecomment-468940192 Not 100% sure I understand the choices. Could you restate the options? Ultimately my preference would be for the version of ES able to communicate with not being based on how the instance was built and instead just be able to choose the version by a processor property passed to designate the ES version but, that may be a misunderstanding of the options. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (NIFI-6020) Cannot list users or policies when an access policy contains a group that is deleted
[
https://issues.apache.org/jira/browse/NIFI-6020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16782350#comment-16782350
]
Jens M Kofoed commented on NIFI-6020:
-
[~mcgilman]: User page are now working i 1.9.0, but there are still problems
showing policies if a ldap group has been deleted.
The policy is still working but the policy page says: No policy for the
specified resource. Create a new policy.
> Cannot list users or policies when an access policy contains a group that is
> deleted
>
>
> Key: NIFI-6020
> URL: https://issues.apache.org/jira/browse/NIFI-6020
> Project: Apache NiFi
> Issue Type: Bug
> Components: Core UI
>Affects Versions: 1.5.0, 1.6.0, 1.7.0, 1.8.0, 1.7.1
>Reporter: Kevin Doran
>Assignee: Kevin Doran
>Priority: Major
> Fix For: 1.9.0
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Originally reported on the Apache NiFi Slack.
> when groups are removed in ldap, it impacts access policies that had the
> group id.
> [https://apachenifi.slack.com/archives/C0L9UPWJZ/p1549493200163800]
> This relates to NIFI-5948.
> Steps to reproduce:
> # Configure NiFi to use the LDAP UserGroupProvider.
> # Then in Nifi, using the UI, create some access policies that contain the
> LDAP groups.
> # Delete groups from LDAP or change the NiFi LdapUserGroupProvider to use a
> different group search base/filter such that a subset of groups are returned,
> and at least one group that belongs to an access policy is no longer synced
> from ldap.
> # Go to buger menu -> users as observe an NPE. stack trace below
> The only way to fix this problem is to delete the association of the access
> policy -> group in the file: authorizations.xml.
> +*Stack trace:*+
>
> {noformat}
> 2019-02-06 22:42:46,373 ERROR [NiFi Web Server-41682]
> o.a.nifi.web.api.config.ThrowableMapper An unexpected error has occurred:
> java.lang.NullPointerException. Returning Internal Server Error response.
> java.lang.NullPointerException: null
> at
> org.apache.nifi.web.dao.impl.StandardPolicyBasedAuthorizerDAO.lambda$null$2(StandardPolicyBasedAuthorizerDAO.java:285)
> at java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:174)
> at java.util.HashMap$KeySpliterator.forEachRemaining(HashMap.java:1553)
> at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
> at
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
> at java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708)
> at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:499)
> at
> org.apache.nifi.web.dao.impl.StandardPolicyBasedAuthorizerDAO.lambda$getAccessPoliciesForUser$3(StandardPolicyBasedAuthorizerDAO.java:285)
> at java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:174)
> at java.util.HashMap$KeySpliterator.forEachRemaining(HashMap.java:1553)
> at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
> at
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
> at java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708)
> at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:499)
> at
> org.apache.nifi.web.dao.impl.StandardPolicyBasedAuthorizerDAO.getAccessPoliciesForUser(StandardPolicyBasedAuthorizerDAO.java:287)
> at
> org.apache.nifi.web.dao.impl.StandardPolicyBasedAuthorizerDAO$$FastClassBySpringCGLIB$$ea190383.invoke()
> at org.springframework.cglib.proxy.MethodProxy.invoke(MethodProxy.java:204)
> at
> org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.invokeJoinpoint(CglibAopProxy.java:738)
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:157)
> at
> org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:92)
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)
> at
> org.springframework.aop.framework.CglibAopProxy$DynamicAdvisedInterceptor.intercept(CglibAopProxy.java:673)
> at
> org.apache.nifi.web.dao.impl.StandardPolicyBasedAuthorizerDAO$$EnhancerBySpringCGLIB$$9bc4b502.getAccessPoliciesForUser()
> at
> org.apache.nifi.web.StandardNiFiServiceFacade.createUserEntity(StandardNiFiServiceFacade.java:3285)
> at
> org.apache.nifi.web.StandardNiFiServiceFacade.lambda$getUsers$163(StandardNiFiServiceFacade.java:3276)
> at java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
> at
[jira] [Commented] (NIFI-6027) Cannot list policies when a user/group has been removed
[ https://issues.apache.org/jira/browse/NIFI-6027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16782348#comment-16782348 ] Jens M Kofoed commented on NIFI-6027: - [~mcgilman] I just upgraded to 1.9.0. In my case I don't get the 404. The policy page just show up blank saying: No policy for the specified resource. Create a new policy. But the policy behind is still working. If I add the deleted group the policy will be back > Cannot list policies when a user/group has been removed > --- > > Key: NIFI-6027 > URL: https://issues.apache.org/jira/browse/NIFI-6027 > Project: Apache NiFi > Issue Type: Bug > Components: Core Framework >Reporter: Matt Gilman >Priority: Major > > When attempting to view policy where a user or group has been removed outside > of NiFi (like when NiFi is syncing to an LDAP instance) the endpoint > incorrectly returns 404. This 404 is happening because it's unable to find > the user or group even though the policy does exist. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (NIFI-6095) LDAP background sync thread dies
[ https://issues.apache.org/jira/browse/NIFI-6095?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens M Kofoed resolved NIFI-6095. - Resolution: Resolved Fix Version/s: 1.9.0 Has been fixed > LDAP background sync thread dies > > > Key: NIFI-6095 > URL: https://issues.apache.org/jira/browse/NIFI-6095 > Project: Apache NiFi > Issue Type: Bug >Affects Versions: 1.8.0 > Environment: 3 nodes in a secure cluster on CentOS 7 connecting to a > MS AD via ldap configuration >Reporter: Jens M Kofoed >Priority: Major > Fix For: 1.9.0 > > > If connection to the ldap is lost the ldap-user-group-provider - background > sync thread dies. And NIFI stops syncing and gets update from ldap. > The nodes are configured for ldap and import all users and groups based on > filter and base search. Users and groups are joined according to > configuration. If users are added/removed from groups, the sync process > updates NIFI until the sync process dies because of network timeout. > Debugging: adding the "org.apache.nifi.ldap" to the logback.xml does not help > much. The only information's is warnings if a group has a member and the > users is not imported. > WARN [ (ldap-user-group-provider) - background sync thread] > org.apache.nifi.ldap.tenants.LdapUserGroupProvider > cn=superusers,ou=nifi01,ou=NiFiClusters,dc=example,dc=net contains member > uid=user01,ou=people,dc=example,dc=net but that user was not found while > searching users. Ignoring group membership. > Adding "org.springframework.ldap" to the logback.xml file gives some > information every time there is a background sync. > In my configuration I set the Sync Interval to 1 mins (authorizers.xml). > Verifying the debug logs for background sync and after some times I removed > the connection to the ldap. From now on I can't find any debug information > about the ldap sync. Even if I reestablish the connection there will be no > more debug information and no ldap sync. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (NIFI-6095) LDAP background sync thread dies
[ https://issues.apache.org/jira/browse/NIFI-6095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16782317#comment-16782317 ] Jens M Kofoed commented on NIFI-6095: - [~mcgilman], Thanks it is. I have now tested the new 1.9.0 version and now I also got the debug information about which user and groups are imported > LDAP background sync thread dies > > > Key: NIFI-6095 > URL: https://issues.apache.org/jira/browse/NIFI-6095 > Project: Apache NiFi > Issue Type: Bug >Affects Versions: 1.8.0 > Environment: 3 nodes in a secure cluster on CentOS 7 connecting to a > MS AD via ldap configuration >Reporter: Jens M Kofoed >Priority: Major > > If connection to the ldap is lost the ldap-user-group-provider - background > sync thread dies. And NIFI stops syncing and gets update from ldap. > The nodes are configured for ldap and import all users and groups based on > filter and base search. Users and groups are joined according to > configuration. If users are added/removed from groups, the sync process > updates NIFI until the sync process dies because of network timeout. > Debugging: adding the "org.apache.nifi.ldap" to the logback.xml does not help > much. The only information's is warnings if a group has a member and the > users is not imported. > WARN [ (ldap-user-group-provider) - background sync thread] > org.apache.nifi.ldap.tenants.LdapUserGroupProvider > cn=superusers,ou=nifi01,ou=NiFiClusters,dc=example,dc=net contains member > uid=user01,ou=people,dc=example,dc=net but that user was not found while > searching users. Ignoring group membership. > Adding "org.springframework.ldap" to the logback.xml file gives some > information every time there is a background sync. > In my configuration I set the Sync Interval to 1 mins (authorizers.xml). > Verifying the debug logs for background sync and after some times I removed > the connection to the ldap. From now on I can't find any debug information > about the ldap sync. Even if I reestablish the connection there will be no > more debug information and no ldap sync. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
