Re: ListenSMTP processor

[Simon Elliston Ball]

Fantastic idea!

Would SplitEmail not make sense to divide by the mime boundary? If you add 
fragment indices in the way other Split processors do, it would be easy to 
recombine an email after processing splits. To be honest, I'm not sure what the 
use case for doing so would be, but it feels consistent with the Split, 
Process, Merge pattern you see elsewhere in NiFi.

Simon 

> On 19 May 2016, at 03:11, Joe Witt  wrote:
> 
> Andre
> 
> I like the idea.  I'd suggest having 'ListenSMTP' go ahead and create
> a good set of FlowFile attributes for things like
> to/from/cc/subject/number of attachments/time/etc... that make sense
> for a given e-mail.  The body of the flowfile would be the entire
> message which i believe would include the attachments themselves which
> is fair game.  If you did need/want to split out the attachments in
> your flow then I'd say the 'ParseEmail' idea is good but perhaps call
> it 'SplitEmail' or 'ExtractEmailAttachment' or something like that.
> 
> Thanks
> Joe
> 
>> On Wed, May 18, 2016 at 7:43 PM, Andre F de Miranda  wrote:
>> All,
>> 
>> I have been considering writing a "ListenSMTP" processor and was wondering
>> *what is the best way of dealing with multiple attachments*.
>> 
>> Looking in here
>> https://mail-archives.apache.org/mod_mbox/nifi-users/201602.mbox/%3ccaljk9a5ulcitnfo0dlsvd5d-jkcsqm+rqjxuruzwgrdbqad...@mail.gmail.com%3E
>> 
>> 
>> I can read Joe suggesting not using attributes to store large volumes of
>> data, so far so good, however, as far as I understand a flowfile can only
>> contain one "content".
>> 
>> Currently the way I envision this would be modular that taps into the
>> pattern set by ListenSyslog / ParseSyslog:
>> 
>> ListenSMTP - A processor that only provides an SMTP interface
>> 
>> ParseEmail - A processor that reads the flowfile holding the email body and
>> split it into 1 or more flowfiles containing the attached mime objects.
>> 
>> The advantage here is that people can use FetchFile or to create a GetIMAP
>> processor to parse messages.
>> 
>> Would anyone have a different view on how to achieve this?
>> 
>> I thank you in advance

[GitHub] nifi pull request: NIFI-1884 Defining API for Users, Groups, and P...

[alopresto]

Github user alopresto commented on the pull request:

https://github.com/apache/nifi/pull/452#issuecomment-220227038
  
@bbende thanks for the explanation. I suppose I am more familiar with, and 
conditioned to assume, the models used in many database-backed frameworks where 
the user and group models are canonical -- while there may be many `User` 
objects instantiated that describe "Andy LoPresto", they all refer to the same 
record in persistent storage, and modifying one (and saving it) updates the 
record that all point to. In addition, it would not be necessary to clone a 
retrieved record in order to modify it. 

Example (using Rails/Grails-esque syntax, but easily replaceable with 
`authorizer.getUser(id)`): 
```
User andy = User.getByUsername("alopresto")
logger.info(andy.getFirstName()) // "Andrew"
andy.setFirstName("Andy")
andy.update()
```

In addition, while updating the relationship can be done from either end 
(i.e. adding a user to _n_ groups is easier by modifying the one user instead 
of retrieving and modifying _n_ groups, while removing all users from a 
specific group would use the opposite operation), it seems like the model 
proposed above duplicates a lot of data during each operation. Is there a 
reason for this? It seems likely there is a tradeoff I am missing. 

I also have questions about resolving uniqueness constraints, ID 
mutability, locks, merge conflicts, etc. on updates, but it seems that these 
details are delegated to the `authorizer` implementation?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: ListenSMTP processor

[Joe Witt]

Andre

I like the idea.  I'd suggest having 'ListenSMTP' go ahead and create
a good set of FlowFile attributes for things like
to/from/cc/subject/number of attachments/time/etc... that make sense
for a given e-mail.  The body of the flowfile would be the entire
message which i believe would include the attachments themselves which
is fair game.  If you did need/want to split out the attachments in
your flow then I'd say the 'ParseEmail' idea is good but perhaps call
it 'SplitEmail' or 'ExtractEmailAttachment' or something like that.

Thanks
Joe

On Wed, May 18, 2016 at 7:43 PM, Andre F de Miranda  wrote:
> All,
>
> I have been considering writing a "ListenSMTP" processor and was wondering
> *what is the best way of dealing with multiple attachments*.
>
> Looking in here
> https://mail-archives.apache.org/mod_mbox/nifi-users/201602.mbox/%3ccaljk9a5ulcitnfo0dlsvd5d-jkcsqm+rqjxuruzwgrdbqad...@mail.gmail.com%3E
>
>
> I can read Joe suggesting not using attributes to store large volumes of
> data, so far so good, however, as far as I understand a flowfile can only
> contain one "content".
>
> Currently the way I envision this would be modular that taps into the
> pattern set by ListenSyslog / ParseSyslog:
>
> ListenSMTP - A processor that only provides an SMTP interface
>
> ParseEmail - A processor that reads the flowfile holding the email body and
> split it into 1 or more flowfiles containing the attached mime objects.
>
> The advantage here is that people can use FetchFile or to create a GetIMAP
> processor to parse messages.
>
> Would anyone have a different view on how to achieve this?
>
> I thank you in advance

[GitHub] nifi pull request: Nifi 539c

[joewitt]

Github user joewitt commented on the pull request:

https://github.com/apache/nifi/pull/453#issuecomment-220190814
  
For what it is worth @olegz I too prefer to see folks avoid using '-1' 
because it is a bit of a blunt instrument in communities like this and there 
are good alternatives to keep the discussion going.

However, my read on this does align with @mosermw in that this does look 
like another SFTP implementation so I too feel like this needs more work if we 
want to support SCP which offers subtle differences that may be preferred in 
some cases over SFTP.  Knowing Mike I knew to take his -1 with nothing but 
noble intent and his follow-on comments support that as well.

Jsch is likely a perfectly fine library for this but as mike points out 
there are different api calls that are likely to be used for SCP.

@eorgad Would be curious to hear your thoughts on some good next steps to 
take with this.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

ListenSMTP processor

[Andre F de Miranda]

All,

I have been considering writing a "ListenSMTP" processor and was wondering
*what is the best way of dealing with multiple attachments*.

Looking in here
https://mail-archives.apache.org/mod_mbox/nifi-users/201602.mbox/%3ccaljk9a5ulcitnfo0dlsvd5d-jkcsqm+rqjxuruzwgrdbqad...@mail.gmail.com%3E


I can read Joe suggesting not using attributes to store large volumes of
data, so far so good, however, as far as I understand a flowfile can only
contain one "content".

Currently the way I envision this would be modular that taps into the
pattern set by ListenSyslog / ParseSyslog:

ListenSMTP - A processor that only provides an SMTP interface

ParseEmail - A processor that reads the flowfile holding the email body and
split it into 1 or more flowfiles containing the attached mime objects.

The advantage here is that people can use FetchFile or to create a GetIMAP
processor to parse messages.

Would anyone have a different view on how to achieve this?

I thank you in advance

[GitHub] nifi pull request: Nifi 539c

[olegz]

Github user olegz commented on the pull request:

https://github.com/apache/nifi/pull/453#issuecomment-220173989
  
@mosermw I think as a community we should stay away from jumping to quick 
conclusions without giving this PR a thorough and adequate review as we do with 
others.
SFTP and SCP are two different protocols and while they both utilize the 
same SSH encryption during file transfer, there are quite a few differences 
which I am sure you can read up on, with performance being one of them (SCP 
being faster) etc.
As for JSch as a library, it is neither SFTP nor SCP. It is simple Java 
implementation of SSH2, allowing anyone to build components that need to 
interact over SSH. So _"processors here are still using SFTP under the covers"_ 
is not really accurate? What I think is more accurate is that both processors 
utilize the same library (JSch) to accomplish the set goal.  
Now, I am not saying there are no issues with @eorgad's  code, 
configuration, documentation etc. I have not personally had a chance to look 
through it yet, and I am sure there are things that may be incorrect or things 
that could be improved. So in the spirit of community and collaboration let's 
concentrate on those. There will be plenty of time in the end to cast up/down 
votes.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: Formatting issues with Json: what is the best approach in NiFi?

[Andy LoPresto]

My idea is to run something like the following:

flowFile = session.get()
if(!flowFile) return

jsonSchema = """
{
// define your schema here
}
"""

boolean valid = true
session.read(flowFile, { inputStream ->
  jsonInput = org.apache.commons.io.IOUtils.toString(inputStream,
java.nio.charset.StandardCharsets.UTF_8)
  JSONObject rawSchema = new JSONObject(new JSONTokener(new
ByteArrayInputStream(jsonSchema.bytes)))
  Schema schema = SchemaLoader.load(rawSchema)
  try {
 schema.validate(new JSONObject(jsonInput))
   } catch(ve) {
 log.error("Doesn't adhere to schema", ve)
 // inspect the validation exception and use it to determine if you need to 
escape quotes, add empty strings for missing values, etc.
   }
 } as InputStreamCallback)

session.transfer(flowFile, REL_SUCCESS)


Another option would be to use the JsonParserLax [1] option in Groovy to read 
the incoming JSON, unmarshal it to a Groovy map, apply a series of common 
transformations (you’ll have more control using native Groovy types rather than 
manipulating a long string), and then marshal it back to well-formed JSON. This 
might be an easier method than what I originally described above.

[1] http://groovy-lang.org/json.html#_parser_variants 


Andy LoPresto
alopre...@apache.org
alopresto.apa...@gmail.com
PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69

> On May 18, 2016, at 1:44 PM, idioma  wrote:
> 
> Andy,
> thank you so much for this, it sounds like a very interesting idea. To
> clarify, are you suggesting to modify the existing Json validator so that it
> can read the invalid Json? Will I then be able to pass it successfully to
> EvaluateJsonPath? Have I understood it correctly?
> 
> Thank you,
> 
> I.
> 
> 
> 
> --
> View this message in context: 
> http://apache-nifi-developer-list.39713.n7.nabble.com/Formatting-issues-with-Json-what-is-the-best-approach-in-NiFi-tp10412p10505.html
> Sent from the Apache NiFi Developer List mailing list archive at Nabble.com.



signature.asc
Description: Message signed with OpenPGP using GPGMail

[GitHub] nifi pull request: NIFI-1578: Create PutSlack processor

[rstjohn]

Github user rstjohn commented on the pull request:

https://github.com/apache/nifi/pull/256#issuecomment-220169135
  
Our use case would benefit from having all of the attachment fields
available.  The implementation I had in mind was to use dynamic
properties.  Each dynamic property would represent an item in the the
attachments array.  Each dynamic property would support expression language
and would fail gracefully if it is not a properly formed json string.  I
can live with the webhook as a sensitive field, but I personally think it
is overkill.  Anyone can look in the Dev tools to see the url and if you
are trying to protect someone from themselves, that it a lost cause.

Richard St. John, Ph.D.
On May 18, 2016 2:04 PM, "adamonduty"  wrote:

> @rstjohn  I agree with @alopresto
>  - the webhook is sensitive. Especially
> because the links and content posted on slack are generally internal to
> teams and trusted, inadvertently exposing a webhook URL could leave teams
> open to phishing attacks. And possession of a webhook URL allows one to
> post to *any* public channel or direct message any user.
>
> You have a great point about the validator - it should validate *after*
> the expression language has been applied to allow for use cases like you
> describe. I'm a bit on the fence on assuming a name without a # is a
> channel name though.
>
> We could also expose the attachments section. Did you envision a property
> where you could supply a json array as described in Slack's documentation
> ? Or did you have another
> approach in mind?
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly or view it on GitHub
> 
>



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: Formatting issues with Json: what is the best approach in NiFi?

[idioma]

Andy,
thank you so much for this, it sounds like a very interesting idea. To
clarify, are you suggesting to modify the existing Json validator so that it
can read the invalid Json? Will I then be able to pass it successfully to
EvaluateJsonPath? Have I understood it correctly? 

Thank you,

I.



--
View this message in context: 
http://apache-nifi-developer-list.39713.n7.nabble.com/Formatting-issues-with-Json-what-is-the-best-approach-in-NiFi-tp10412p10505.html
Sent from the Apache NiFi Developer List mailing list archive at Nabble.com.

[GitHub] nifi pull request: Nifi 539c

[mosermw]

Github user mosermw commented on the pull request:

https://github.com/apache/nifi/pull/453#issuecomment-220166172
  
If SCPTransfer.java continues to use Jsch then I was expecting an 
implementation similar to Jsch example code for scp.
http://www.jcraft.com/jsch/examples/ScpTo.java.html
http://www.jcraft.com/jsch/examples/ScpFrom.java.html


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] nifi pull request: NIFI-1578: Create PutSlack processor

[alopresto]

Github user alopresto commented on the pull request:

https://github.com/apache/nifi/pull/256#issuecomment-220160457
  
@Edgardo, yes, NiFi provides access control and checks authentication and 
authorization (if configured) before allowing a user or entity to access the 
processor properties. However, as @adamonduty points out, when a template is 
exported, any properties that are not marked as sensitive as exported as 
plaintext values. If someone were to share this template, the webhook URL would 
be included. Consider the URL similar to a shared password for room access. 
It's something that should be protected from unnecessary access within NiFi, as 
well as from accidental data leakage via template export. 


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] nifi pull request: Nifi 539c

[mosermw]

Github user mosermw commented on the pull request:

https://github.com/apache/nifi/pull/453#issuecomment-220146745
  
It looks like GetSCP, PutSCP and SCPTransfer are just copies of the SFTP 
equivalent, with some cosmetic changes.  They don't actually use scp.  So I'm 
wondering where the added value is?  We already have SFTP processors.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] nifi pull request: Nifi 539c

[eorgad]

Github user eorgad commented on the pull request:

https://github.com/apache/nifi/pull/453#issuecomment-220145092
  
Yes they are using jcraft.jsch under the cover - what did you have in mind?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] nifi pull request: Nifi 539c

[mosermw]

Github user mosermw commented on the pull request:

https://github.com/apache/nifi/pull/453#issuecomment-220137783
  
Maybe I'm missing something, but it seems that the GetSCP and PutSCP 
processors here are still using SFTP under the covers.  If this is the case, 
then -1.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] nifi pull request: NIFI-1884 Defining API for Users, Groups, and P...

[bbende]

Github user bbende commented on a diff in the pull request:

https://github.com/apache/nifi/pull/452#discussion_r63760082
  
--- Diff: 
nifi-api/src/main/java/org/apache/nifi/authorization/AccessPolicy.java ---
@@ -0,0 +1,125 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.nifi.authorization;
+
+import java.util.Collections;
+import java.util.Objects;
+import java.util.Set;
+
+/**
+ * Defines a policy for a set of entities to perform a set of actions on a 
given resource.
+ */
+public class AccessPolicy {
+
+private final String identifier;
+
+private final Resource resource;
+
+private final Set entities;
+
+private final Set actions;
+
+/**
+ * Constructs a new policy with the given resource, entities, and 
actions.
+ *
+ * @param identifier the identifier of the policy
+ * @param resource the resource for the policy
+ * @param entities the entity ids for the policy (i.e. user or group 
ids)
+ * @param actions the actions for the policy
+ */
+public AccessPolicy(final String identifier, final Resource resource, 
final Set entities, final Set actions) {
+if (identifier == null || identifier.trim().isEmpty()) {
+throw new IllegalArgumentException("Identifier can not be null 
or empty");
+}
+
+if (resource == null) {
+throw new IllegalArgumentException("Resource can not be null");
+}
+
+if (entities == null || entities.isEmpty()) {
+throw new IllegalArgumentException("Entities can not be null 
or empty");
+}
+
+if (actions == null || actions.isEmpty()) {
+throw new IllegalArgumentException("Actions can not be null or 
empty");
+}
+
+this.identifier = identifier;
+this.resource = resource;
+this.entities = Collections.unmodifiableSet(entities);
+this.actions = Collections.unmodifiableSet(actions);
+}
+
+/**
+ * @return the identifier for this policy
+ */
+public String getIdentifier() {
+return identifier;
+}
+
+/**
+ * @return the resource for this policy
+ */
+public Resource getResource() {
+return resource;
+}
+
+/**
+ * @return the set of entity ids for this policy
+ */
+public Set getEntities() {
+return entities;
+}
+
+/**
+ * @return the set of actions for this policy
+ */
+public Set getActions() {
+return actions;
+}
+
+@Override
+public boolean equals(Object obj) {
+if (obj == null) {
+return false;
+}
+if (getClass() != obj.getClass()) {
+return false;
+}
+
+final AccessPolicy other = (AccessPolicy) obj;
+
+return this.identifier.equals(other.getIdentifier())
+&& 
this.resource.getIdentifier().equals(other.getResource().getIdentifier())
+&& this.entities.equals(other.entities)
+&& this.actions.equals(other.actions);
+}
+
+@Override
+public int hashCode() {
+int hash = 7;
+hash = 53 * hash + Objects.hash(this.identifier, this.resource, 
this.entities, this.actions);
--- End diff --

Good call, will update all the hashCode implementations


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] nifi pull request: NIFI-1578: Create PutSlack processor

[adamonduty]

Github user adamonduty commented on the pull request:

https://github.com/apache/nifi/pull/256#issuecomment-220126202
  
Edgardo, I was more concerned about template export. If one wants to share 
how something is done in NiFi with others via a template, many users would be 
surprised (or angry) if their webhook URL was exported. It isn't meant to be 
shared outside of a slack team, but there is a lot of potential for that to 
inadvertently occur if we don't mark it as sensitive.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] nifi pull request: NIFI-1884 Defining API for Users, Groups, and P...

[bbende]

Github user bbende commented on a diff in the pull request:

https://github.com/apache/nifi/pull/452#discussion_r63759950
  
--- Diff: 
nifi-api/src/main/java/org/apache/nifi/authorization/AccessPolicy.java ---
@@ -0,0 +1,125 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.nifi.authorization;
+
+import java.util.Collections;
+import java.util.Objects;
+import java.util.Set;
+
+/**
+ * Defines a policy for a set of entities to perform a set of actions on a 
given resource.
+ */
+public class AccessPolicy {
+
+private final String identifier;
+
+private final Resource resource;
+
+private final Set entities;
+
+private final Set actions;
+
+/**
+ * Constructs a new policy with the given resource, entities, and 
actions.
+ *
+ * @param identifier the identifier of the policy
+ * @param resource the resource for the policy
+ * @param entities the entity ids for the policy (i.e. user or group 
ids)
+ * @param actions the actions for the policy
+ */
+public AccessPolicy(final String identifier, final Resource resource, 
final Set entities, final Set actions) {
+if (identifier == null || identifier.trim().isEmpty()) {
+throw new IllegalArgumentException("Identifier can not be null 
or empty");
+}
+
+if (resource == null) {
+throw new IllegalArgumentException("Resource can not be null");
+}
+
+if (entities == null || entities.isEmpty()) {
+throw new IllegalArgumentException("Entities can not be null 
or empty");
+}
+
+if (actions == null || actions.isEmpty()) {
+throw new IllegalArgumentException("Actions can not be null or 
empty");
+}
+
+this.identifier = identifier;
+this.resource = resource;
+this.entities = Collections.unmodifiableSet(entities);
+this.actions = Collections.unmodifiableSet(actions);
+}
+
+/**
+ * @return the identifier for this policy
+ */
+public String getIdentifier() {
+return identifier;
+}
+
+/**
+ * @return the resource for this policy
+ */
+public Resource getResource() {
+return resource;
+}
+
+/**
+ * @return the set of entity ids for this policy
+ */
+public Set getEntities() {
+return entities;
--- End diff --

Good call, I prefer documenting in the javadoc


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: [GitHub] nifi pull request: NIFI-1578: Create PutSlack processor

[Edgardo Vega]

Isn't the concern about the webhook url handled by the fact there is nifi
security. If you don't trust people with the url you most certainly don't
trust them with access to the nifi canvas. Considering in Slack anyone on
the team can see the webhook url I think that the webhook is NOT sensitive.

On Wed, May 18, 2016 at 2:04 PM, adamonduty  wrote:

> Github user adamonduty commented on the pull request:
>
> https://github.com/apache/nifi/pull/256#issuecomment-220109946
>
> @rstjohn I agree with @alopresto - the webhook is sensitive.
> Especially because the links and content posted on slack are generally
> internal to teams and trusted, inadvertently exposing a webhook URL could
> leave teams open to phishing attacks. And possession of a webhook URL
> allows one to post to *any* public channel or direct message any user.
>
> You have a great point about the validator - it should validate
> *after* the expression language has been applied to allow for use cases
> like you describe. I'm a bit on the fence on assuming a name without a `#`
> is a channel name though.
>
> We could also expose the `attachments` section. Did you envision a
> property where you could supply a json array as described in https://api.slack.com/docs/attachments";>Slack's documentation? Or did
> you have another approach in mind?
>
>
> ---
> If your project is set up for it, you can reply to this email and have your
> reply appear on GitHub as well. If your project does not have this feature
> enabled and wishes so, or if the feature is enabled but not working, please
> contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
> with INFRA.
> ---
>



-- 
Cheers,

Edgardo

[GitHub] nifi pull request: NIFI-1884 Defining API for Users, Groups, and P...

[bbende]

Github user bbende commented on a diff in the pull request:

https://github.com/apache/nifi/pull/452#discussion_r63760205
  
--- Diff: nifi-api/src/main/java/org/apache/nifi/authorization/Group.java 
---
@@ -0,0 +1,115 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.nifi.authorization;
+
+import java.util.Collections;
+import java.util.HashSet;
+import java.util.Objects;
+import java.util.Set;
+
+/**
+ * A group that users can belong to.
+ */
+public class Group {
+
+private final String identifier;
+
+private final String name;
+
+private final Set users;
+
+/**
+ * Constructs a new group with the given identifier and name.
+ *
+ * @param identifier a unique identifier for the group
+ * @param name the name of the group
+ */
+public Group(final String identifier, final String name) {
+this(identifier, name, null);
+}
+
+/**
+ * Constructs a new group with the given identifier, name, and users.
+ *
+ * @param identifier a unique identifier for the group
+ * @param name the name of the group
+ * @param users the list of user identifiers that belong to this group
+ */
+public Group(final String identifier, final String name, final 
Set users) {
+if (identifier == null || identifier.trim().isEmpty()) {
+throw new IllegalArgumentException("Identifier can not be null 
or empty");
+}
+
+if (name == null || name.trim().isEmpty()) {
+throw new IllegalArgumentException("Name can not be null or 
empty");
+}
+
+this.identifier = identifier;
+this.name = name;
+this.users = (users == null ? Collections.unmodifiableSet(new 
HashSet<>()) : Collections.unmodifiableSet(users));
+}
+
+/**
+ * @return the identifier of the group
+ */
+public String getIdentifier() {
+return identifier;
+}
+
+/**
+ * @return the name of the group
+ */
+public String getName() {
+return name;
+}
+
+/**
+ * @return the list of user identifiers that belong to this group
+ */
+public Set getUsers() {
+return users;
+}
+
+@Override
+public boolean equals(Object obj) {
+if (obj == null) {
+return false;
+}
+if (getClass() != obj.getClass()) {
+return false;
+}
+
+final Group other = (Group) obj;
+if (!Objects.equals(this.identifier, other.identifier)) {
--- End diff --

Good call, will do that and will verify other equals methods are consistent 
if necessary


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] nifi pull request: NIFI-1884 Defining API for Users, Groups, and P...

[bbende]

Github user bbende commented on the pull request:

https://github.com/apache/nifi/pull/452#issuecomment-220121052
  
@alopresto The intent was for the relationship to be bi-directional, 
meaning you could add a user to a group by adding/updating a User with a new 
group id in the set of groups, or by adding/updating a Group with a new user id 
in the set of users.

The overall idea was to retrieve an object, make a copy of it with the 
desired changes, and then call update. So for the example scenarios...

- You could do this two different ways, but one would be to create a new 
Group instance with name "Admins" and no users and call addGroup(), then create 
a new User instance with name "Bryan Bende" and a set of group ids containing 
the id of the "Admins" group and call addUser()

-  Same as above to create the group and user and place the user in the 
group... then you would retrieve the User instance for "Andrew LoPresto", make 
a copy of that User instance with the name set to "Andy LoPrestro" and call 
updateUser(...)

- Same as scenario 1 to create the group and users and place the users in 
the group, although to add both users to the group in one action you could 
retrieve the Group, make a copy of the Group and add both user ids to the set 
of users, and call updateGroup(). Removing "Bryan Bende" from "Admins" could be 
done by copying the Group without "Bryan Bende"s id in the set of users and 
calling updateGroup, or by copying the User for "Bryan Bende" without the id of 
the "Admin" group in the set of groups and calling updateUser().

After thinking about all of these, it seems like it would nice to have 
builders that made it convenient for updating a User or Group... So something 
like...

```
User user = authorizer.getUser(id);
User updatedUser = new User.UserBuilder().fromUser(user).name("New 
Name").build();
authorizer.updateUser(updatedUser);
```
Also easily removing entries, so something like this for removing a user 
from a group:

```
User user = authorizer.getUser(id);
User updatedUser = new 
User.UserBuilder().fromUser(user).removeGroup(groupId).build();
authorizer.updateUser(updatedUser);
```
Thoughts?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] nifi pull request: NIFI-1578: Create PutSlack processor

[adamonduty]

Github user adamonduty commented on the pull request:

https://github.com/apache/nifi/pull/256#issuecomment-220109946
  
@rstjohn I agree with @alopresto - the webhook is sensitive. Especially 
because the links and content posted on slack are generally internal to teams 
and trusted, inadvertently exposing a webhook URL could leave teams open to 
phishing attacks. And possession of a webhook URL allows one to post to *any* 
public channel or direct message any user.

You have a great point about the validator - it should validate *after* the 
expression language has been applied to allow for use cases like you describe. 
I'm a bit on the fence on assuming a name without a `#` is a channel name 
though. 

We could also expose the `attachments` section. Did you envision a property 
where you could supply a json array as described in https://api.slack.com/docs/attachments";>Slack's documentation? Or did 
you have another approach in mind?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] nifi pull request: NIFI-1884 Defining API for Users, Groups, and P...

[alopresto]

Github user alopresto commented on the pull request:

https://github.com/apache/nifi/pull/452#issuecomment-220108280
  
I'm not sure I understand the relationship between `User` and `Group` -- 
which class owns the relationship, and is it bidirectional? What would be the 
steps for the following tasks:

- Create a group "Admins", create a user "Bryan Bende", add "Bryan Bende" 
to "Admins"
- Create a group "Admins", create a user "Andrew LoPresto", add "Andrew 
LoPresto" to "Admins", change name of "Andrew LoPresto" to "Andy LoPresto" 
- Create a group "Admins", create a user "Bryan Bende", create a user "Andy 
LoPresto", add "Bryan Bende" to "Admins", add "Andy LoPresto" to "Admins", 
remove user "Bryan Bende" from "Admins"

It seems as if the `User` and `Group` objects both have references to each 
other, but they are String identifiers, and the `Set`s are immutable. 


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] nifi pull request: Eorgad patch nifi 539

[eorgad]

Github user eorgad commented on the pull request:

https://github.com/apache/nifi/pull/416#issuecomment-220098715
  
Due to my own difficulty with Branching ended up re creating a branch and 
all the steps - now in Pull request: Nifi 539c , # 453, so closing this one. 


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] nifi pull request: Eorgad patch nifi 539

[eorgad]

Github user eorgad closed the pull request at:

https://github.com/apache/nifi/pull/416


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] nifi pull request: NIFI-1884 Defining API for Users, Groups, and P...

[jtstorck]

Github user jtstorck commented on a diff in the pull request:

https://github.com/apache/nifi/pull/452#discussion_r63745403
  
--- Diff: nifi-api/src/main/java/org/apache/nifi/authorization/Group.java 
---
@@ -0,0 +1,115 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.nifi.authorization;
+
+import java.util.Collections;
+import java.util.HashSet;
+import java.util.Objects;
+import java.util.Set;
+
+/**
+ * A group that users can belong to.
+ */
+public class Group {
+
+private final String identifier;
+
+private final String name;
+
+private final Set users;
+
+/**
+ * Constructs a new group with the given identifier and name.
+ *
+ * @param identifier a unique identifier for the group
+ * @param name the name of the group
+ */
+public Group(final String identifier, final String name) {
+this(identifier, name, null);
+}
+
+/**
+ * Constructs a new group with the given identifier, name, and users.
+ *
+ * @param identifier a unique identifier for the group
+ * @param name the name of the group
+ * @param users the list of user identifiers that belong to this group
+ */
+public Group(final String identifier, final String name, final 
Set users) {
+if (identifier == null || identifier.trim().isEmpty()) {
+throw new IllegalArgumentException("Identifier can not be null 
or empty");
+}
+
+if (name == null || name.trim().isEmpty()) {
+throw new IllegalArgumentException("Name can not be null or 
empty");
+}
+
+this.identifier = identifier;
+this.name = name;
+this.users = (users == null ? Collections.unmodifiableSet(new 
HashSet<>()) : Collections.unmodifiableSet(users));
+}
+
+/**
+ * @return the identifier of the group
+ */
+public String getIdentifier() {
+return identifier;
+}
+
+/**
+ * @return the name of the group
+ */
+public String getName() {
+return name;
+}
+
+/**
+ * @return the list of user identifiers that belong to this group
+ */
+public Set getUsers() {
+return users;
+}
+
+@Override
+public boolean equals(Object obj) {
+if (obj == null) {
+return false;
+}
+if (getClass() != obj.getClass()) {
+return false;
+}
+
+final Group other = (Group) obj;
+if (!Objects.equals(this.identifier, other.identifier)) {
--- End diff --

Can you just return the result of `Objects.equals(this.identifier, 
other.identifier)` here?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] nifi pull request: NIFI-1745: Refactor how revisions are handled a...

[markap14]

GitHub user markap14 opened a pull request:

https://github.com/apache/nifi/pull/454

NIFI-1745: Refactor how revisions are handled at NCM/Distributed to Node

This is part 2 of NIFI-1745, which provides user info to revision 
claims/locks and removes the cluster context, as it is no longer necessary

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/markap14/nifi NIFI-1745-Part2

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/nifi/pull/454.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #454


commit 55fb1dab52880cfba94ac6ebd3552b4019020b1b
Author: Mark Payne 
Date:   2016-05-17T15:51:09Z

NIFI-1745: Refactor how revisions are handled at NCM/Distributed to Node




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] nifi pull request: NIFI-1884 Defining API for Users, Groups, and P...

[jtstorck]

Github user jtstorck commented on a diff in the pull request:

https://github.com/apache/nifi/pull/452#discussion_r63744574
  
--- Diff: 
nifi-api/src/main/java/org/apache/nifi/authorization/AccessPolicy.java ---
@@ -0,0 +1,125 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.nifi.authorization;
+
+import java.util.Collections;
+import java.util.Objects;
+import java.util.Set;
+
+/**
+ * Defines a policy for a set of entities to perform a set of actions on a 
given resource.
+ */
+public class AccessPolicy {
+
+private final String identifier;
+
+private final Resource resource;
+
+private final Set entities;
+
+private final Set actions;
+
+/**
+ * Constructs a new policy with the given resource, entities, and 
actions.
+ *
+ * @param identifier the identifier of the policy
+ * @param resource the resource for the policy
+ * @param entities the entity ids for the policy (i.e. user or group 
ids)
+ * @param actions the actions for the policy
+ */
+public AccessPolicy(final String identifier, final Resource resource, 
final Set entities, final Set actions) {
+if (identifier == null || identifier.trim().isEmpty()) {
+throw new IllegalArgumentException("Identifier can not be null 
or empty");
+}
+
+if (resource == null) {
+throw new IllegalArgumentException("Resource can not be null");
+}
+
+if (entities == null || entities.isEmpty()) {
+throw new IllegalArgumentException("Entities can not be null 
or empty");
+}
+
+if (actions == null || actions.isEmpty()) {
+throw new IllegalArgumentException("Actions can not be null or 
empty");
+}
+
+this.identifier = identifier;
+this.resource = resource;
+this.entities = Collections.unmodifiableSet(entities);
+this.actions = Collections.unmodifiableSet(actions);
+}
+
+/**
+ * @return the identifier for this policy
+ */
+public String getIdentifier() {
+return identifier;
+}
+
+/**
+ * @return the resource for this policy
+ */
+public Resource getResource() {
+return resource;
+}
+
+/**
+ * @return the set of entity ids for this policy
+ */
+public Set getEntities() {
+return entities;
+}
+
+/**
+ * @return the set of actions for this policy
+ */
+public Set getActions() {
+return actions;
+}
+
+@Override
+public boolean equals(Object obj) {
+if (obj == null) {
+return false;
+}
+if (getClass() != obj.getClass()) {
+return false;
+}
+
+final AccessPolicy other = (AccessPolicy) obj;
+
+return this.identifier.equals(other.getIdentifier())
+&& 
this.resource.getIdentifier().equals(other.getResource().getIdentifier())
+&& this.entities.equals(other.entities)
+&& this.actions.equals(other.actions);
+}
+
+@Override
+public int hashCode() {
+int hash = 7;
+hash = 53 * hash + Objects.hash(this.identifier, this.resource, 
this.entities, this.actions);
--- End diff --

When using Objects.hash(), you should be able to just return the invocation 
of that with the class members you want included in the hash:
`return Objects.hash(this.identifier, this.resource, this.entities, 
this.actions);`


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.or

[GitHub] nifi pull request: NIFI-1884 Defining API for Users, Groups, and P...

[jtstorck]

Github user jtstorck commented on a diff in the pull request:

https://github.com/apache/nifi/pull/452#discussion_r63743405
  
--- Diff: 
nifi-api/src/main/java/org/apache/nifi/authorization/AccessPolicy.java ---
@@ -0,0 +1,125 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.nifi.authorization;
+
+import java.util.Collections;
+import java.util.Objects;
+import java.util.Set;
+
+/**
+ * Defines a policy for a set of entities to perform a set of actions on a 
given resource.
+ */
+public class AccessPolicy {
+
+private final String identifier;
+
+private final Resource resource;
+
+private final Set entities;
+
+private final Set actions;
+
+/**
+ * Constructs a new policy with the given resource, entities, and 
actions.
+ *
+ * @param identifier the identifier of the policy
+ * @param resource the resource for the policy
+ * @param entities the entity ids for the policy (i.e. user or group 
ids)
+ * @param actions the actions for the policy
+ */
+public AccessPolicy(final String identifier, final Resource resource, 
final Set entities, final Set actions) {
+if (identifier == null || identifier.trim().isEmpty()) {
+throw new IllegalArgumentException("Identifier can not be null 
or empty");
+}
+
+if (resource == null) {
+throw new IllegalArgumentException("Resource can not be null");
+}
+
+if (entities == null || entities.isEmpty()) {
+throw new IllegalArgumentException("Entities can not be null 
or empty");
+}
+
+if (actions == null || actions.isEmpty()) {
+throw new IllegalArgumentException("Actions can not be null or 
empty");
+}
+
+this.identifier = identifier;
+this.resource = resource;
+this.entities = Collections.unmodifiableSet(entities);
+this.actions = Collections.unmodifiableSet(actions);
+}
+
+/**
+ * @return the identifier for this policy
+ */
+public String getIdentifier() {
+return identifier;
+}
+
+/**
+ * @return the resource for this policy
+ */
+public Resource getResource() {
+return resource;
+}
+
+/**
+ * @return the set of entity ids for this policy
+ */
+public Set getEntities() {
+return entities;
--- End diff --

For getters that return entities/request actions, since the underlying set 
is unmodifiable, should we mention that in the javadoc?  Another alternative 
would be to return a defensive copy of the internal set.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] nifi pull request: NIFI-1578: Create PutSlack processor

[alopresto]

Github user alopresto commented on the pull request:

https://github.com/apache/nifi/pull/256#issuecomment-220092091
  
Hi,

While I understand making `webhook` a sensitive value means it does not 
"accompany" the template, it really is a sensitive value. Anyone with that URL 
can post indiscriminately to the Slack channel it references. This is another 
good example of where the upcoming [Variable 
Registry](https://cwiki.apache.org/confluence/display/NIFI/Variable+Registry) 
should be a helpful feature. 


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] nifi pull request: Nifi 539c

[eorgad]

GitHub user eorgad opened a pull request:

https://github.com/apache/nifi/pull/453

Nifi 539c

Commit review notes on GetSCP , PutSCP and SCPTransfer

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/eorgad/nifi nifi-539c

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/nifi/pull/453.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #453


commit 15b0321d3c4a69e778e4eebedc2dd1343ade8dd4
Author: eorgad 
Date:   2016-05-18T16:26:40Z

Merge remote-tracking branch 'apache/master' into nifi-539c

commit e85ab80d50d9ce67905ea78e6386323cd42096e4
Author: eorgad 
Date:   2016-05-18T16:29:26Z

GetSCP and PutSCP

Commit review notes on GetSCP , PutSCP and SCPTransfer




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: StoreInKiteDataset cant validate URI

[pradeepbill]

Thanks Ricky for the response, I can confirm there are no whitespace/special
characters issues  , but here is what happened, it was working before a
linux security/other patch updates that happened over the weekend.And after
the update this piece is complaining about the URI, not sure if they are all
linked, but no errors of any kind in the logs.Please advice.

Thanks
Pradeep



--
View this message in context: 
http://apache-nifi-developer-list.39713.n7.nabble.com/StoreInKiteDataset-cant-validate-URI-tp10409p10483.html
Sent from the Apache NiFi Developer List mailing list archive at Nabble.com.

[GitHub] nifi pull request: NIFI-1884 Defining API for Users, Groups, and P...

[mcgilman]

Github user mcgilman commented on the pull request:

https://github.com/apache/nifi/pull/452#issuecomment-220025580
  
+1 LGTM


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] nifi pull request: NIFI-1884 Defining API for Users, Groups, and P...

[mcgilman]

Github user mcgilman commented on the pull request:

https://github.com/apache/nifi/pull/452#issuecomment-220023481
  
Reviewing...


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] nifi pull request: NIFI-1578: Create PutSlack processor

[rstjohn]

Github user rstjohn commented on the pull request:

https://github.com/apache/nifi/pull/256#issuecomment-220020450
  
We are heavy users of Slack and find this processor very useful.  
Below are a few changes that we would like to see:
* Do not make WebHook a sensitive value.  It makes it hard to use in 
templates
* Update the channel validation to work better with expression language.  
Currently, the field must start with a # or @.  However, our expression 
language variable is responsible to setting the destination.  It could be 
either an @ or a #.  We don't know until runtime.  You could default prepend a 
# unless the expression language evaluation starts with @.
* Allow dynamic properties to populate the "attachments" json field from 
the Slack API.  This allows greater customization of the posted message. 


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---