Member since
04-15-2021
30
Posts
1
Kudos Received
0
Solutions
08-19-2021
01:41 PM
@midee Have you resolved your issue? If so, please mark the appropriate reply as the solution, as it will make it easier for others to find the answer in the future.
... View more
08-19-2021
03:06 AM
@midee, were you able to implement the suggestions? Has the reply helped resolve your issue? If so, can you please mark the appropriate reply as the solution, as it will make it easier for others to find the answer in the future?
... View more
07-28-2021
10:53 AM
1 Kudo
@midee @janis-ax is correct that this is not possible. "ONLY" sensitive attributes can be encrypted/masked. Only component properties coded to as a sensitive property field would be able to decrypt an encrypted/masked value. If setting policies to block specific users from being able to view the data on these components, you may want to look at other options for performing these endpoint authentication/authorization actions. For example, with the NiFi endpoints you could use mutual TLS via certificates instead of token based authentication for accessing the endpoints. This does not mean you need to stop using or un-configure the token based authentication methods for access to your secured NiFi. If the endpoint you are trying to reach is not NiFi, you may want to see what other options it may offer for authentication that are not token based. Hope this helped, Matt
... View more
07-28-2021
10:40 AM
@midee You are using an InvokeHTTP processor to hit the rest-api endpoint of some authentication service to obtain a JWT Token, correct? The invokeHTTP processor gives you only two options for handling the response from the endpoint. Placed it in the content of the FlowFile or in to an attribute of the FlowFile. This means that any user who has been granted authorization to view the data of any component that this FlowFile will traverse can see the attributes and content of this FlowFile. There is no capability for the invokeHTTP to encrypt/mask the endpoint response in either options. Even if there was, this now masked/encrypted data would no longer be usable by downstream components. I suspect your plan is to then use this token to make additional requests to other endpoints later in your flow? Also keep in mind that a token generally has a limited lifespan. You should also have the ability to invalidate the token via another endpoint when you are done with it. So your options here are: 1. Limit user's access so they can not view the data in the dataflows that utilize this token so that they can't see the token in the content or attributes. If you are building the flow, then you know how to get the token so does not matter that you can see the token via the attributes or content. 2. Invalidate the token once done with it. Token can't be used anymore even if a user gained access to it later via looking at the content or attributes of a FlowFile. So you may consider building yoru flow to get a token --> use that token for other actions --> invalidate token (Using NiFi login authentication as a JWT token example, you hit the logout endpoint to invalidate the token on the server side. This means the client token will no longer work even if you have it still). Of course this means you flow needs to obtain a new token every time it runs. Issue here is if your flow utilizes same token for multiple FlowFiles. First FlowFile that hist logout will invalidate token other FlowFiles may try to still use. Note that the default life of a token issued by NiFi is 12 hours. After that the client token can't be used anymore and a new token would need to be obtained anyway (of course this age can be adjusted via the NiFi login provider configuration) If you found this answered your query, please take a moment to login and click "Accept" on the solutions that assisted you. Thank you, Matt
... View more
07-23-2021
12:38 AM
1 Kudo
@DennisJaheruddi , Thanks for your reply. I a able to resolve this issue with your suggestion. Thanks!
... View more
07-14-2021
11:22 PM
@MattWho Thanks for your reply and let me know about the correct flow.
... View more
06-24-2021
05:34 AM
@midee I just ran the test myself with your sample as a one line formatted json and it still worked. {"expand": "renderedFields,names,schema,operations,editmeta,changelog,versionedRepresentations","id": "1155391","key": "DPGAUT-2","fields": {"customfield_10001": null,"customfield_10002": null,"customfield_10003": null,"customfield_10004": null,"customfield_10005": null,"customfield_10006": null,"resolution": null,"customfield_10101": "","customfield_10007": null,"customfield_10008": null,"customfield_10009": "This is required value","customfield_10010": null,"customfield_10011": null,"customfield_10012": null,"customfield_10013": null,}} Make sure your RouteOnContent processor dynamic property value does not have a line return in it. You'll notice it only shows "1" line above. If you see a "2" line then you have a line return in your Value field which would cause the issue you are seeing. Hope this helped, Matt
... View more
06-02-2021
07:52 AM
@midee I am not clearly following your use case. FlowFiles consist of two parts, FlowFile attributes/metadata and FlowFile content. You give example with "customefields_12345" and "customefields_12346". Does this mean one FlowFile may have multiple "customefields_<some string>" attributes assigned to it? How do you want to route FlowFiles where only some of those customfield attributes are null while others are not? There are multiple ways to handle this using NiFi Expression Language (NEL) [1] and the routeOnAttribute [2] processor. ${anyMatchingAttribute("customfield.*"):isEmpty()} Above would return "true" if ANY of the NiFi FlowFile attributes starting with "customefield" is empty. note: The isEmpty function returns true if the Subject is null, does not contain any characters or contains only white-space (new line, carriage return, space, tab), false otherwise. There is another NEL subjectless function that would return "true" only if ALL FlowFileAttributes matching the Java regular expression were empty: ${allMatchingAttributes("customfield.*"):isEmpty()} With the RouteOnAttribute processor you create/add dynamic properties and each of those becomes a new routable relationship on the processor. if the NEL statement configured for that dynamic property returns true that FlowFile routes to that relationship. Any FlowFile that does not return true for dynamic properties will get routed to the pre-existing relationship named "unmatched". [1] https://nifi.apache.org/docs/nifi-docs/html/expression-language-guide.html [2] https://nifi.apache.org/docs/nifi-docs/components/org.apache.nifi/nifi-standard-nar/1.13.2/org.apache.nifi.processors.standard.RouteOnAttribute/index.html If you found this addressed your query, please take a moment to login and click "Accept" on this solution. Thank you, Matt
... View more