Mikhail, So, I suppose there should be ordering guarantees that listener is registered before first validation failure can occur. Hope GridComponent#onKernalStart is the right place. Is it enough to pass only problematic node id (or ClusterNode) with an event? Actually such event seems to fit naturally node join/left/failed events.
вт, 3 дек. 2019 г. в 10:38, Mikhail Petrov <pmgheap....@gmail.com>: > > Hi Ivan. > > No other lifecycle events are needed in my case. > > We can register a listener in the security component's > GridComponent#onKernalStart method and listen locally to every failed > joining attempt. Am I missing something? > > Regards, > Mikhail. > > On 03.12.2019 8:48, Ivan Pavlukhin wrote: > > Mikhail, > > > > Do you need some ordering guarantees among node lifecycle events and > > listener notifications. For example, I can imagine that it is good to > > notify security component about every node failed validation. How can > > we achieve it with events (I assume dynamic listener registration)? > > > > пн, 2 дек. 2019 г. в 18:09, Mikhail Petrov <pmgheap....@gmail.com>: > >> Hi, Andrey. > >> > >> It doesn't influence on authentication or authorization process. There > >> is a security requirement that demands to notify some outer security > >> subsystems in a specific way when joining node validation failed in any > >> Ignite component (e.g. GridCacheProcessor) not only in > >> IgniteSecurityProcessor. So PluginProvider#validateNewNode is not > >> acceptable for me. > >> > >> Regards, > >> Mikhail. > >> > >> On 02.12.2019 16:35, Andrey Gura wrote: > >>> Mikhail, > >>> > >>> I don't understand how node validation on join affects security. But > >>> it seems that you can use > >>> PluginProvider#validateNewNode(org.apache.ignite.cluster.ClusterNode, > >>> java.io.Serializable) method. Does it fit for your needs? > >>> > >>> On Mon, Dec 2, 2019 at 12:54 PM Mikhail Petrov <pmgheap....@gmail.com> > >>> wrote: > >>>> Hi, Ivan. > >>>> > >>>> > >>>> Unfortunately, we came to no decision yet. As I mentioned above this > >>>> event is disabled by default and no node will receive this event without > >>>> an explicit subscription. In my case, that event is assumed to be used > >>>> on node locally to share joining node info between security and > >>>> discovery components. I have no idea how to solve this problem without > >>>> publishing a new event too. But I'm concerned about the acceptance of > >>>> that solution. Maybe it can be solved some other way? I will appreciate > >>>> any suggestion or review PR [1] with event implementation. > >>>> > >>>> > >>>> [1] https://github.com/apache/ignite/pull/7057 > >>>> > >>>> > >>>> Regards, > >>>> > >>>> Mikhail. > >>>> > >>>> On 02.12.2019 10:38, Ivan Pavlukhin wrote: > >>>>> Mikhail, Andrey, > >>>>> > >>>>> Have you come to a common decision here? As for me, it sounds useful > >>>>> to expose node join failure details somehow. The thing to decide on is > >>>>> a mechanism to expose it. Unfortunately, immediately have no idea > >>>>> better than using events. > >>>>> > >>>>>> What is purpose of the special cluster wide event? Node is not joined > >>>>>> to the topology. Why topology nodes should know something about this > >>>>>> node? > >>>>> Was this question answered? I suppose that at least coordinator will > >>>>> receive the event, will not it? > >>>>> > >>>>> чт, 28 нояб. 2019 г. в 10:10, Mikhail Petrov <pmgheap....@gmail.com>: > >>>>>> Hi, Ivan. > >>>>>> > >>>>>> I'm sorry that the discussion was moved in private channel. The problem > >>>>>> I'm trying to solve is described below in the thread. The security > >>>>>> plugin in my case stores and analyzesinfo about a node that failed to > >>>>>> join. > >>>>>> > >>>>>> > >>>>>> Regards, > >>>>>> > >>>>>> Mikhail. > >>>>>> > >>>>>> > >>>>>> > >>>>>> -------- Forwarded Message -------- > >>>>>> Subject: Re: Joining node validation failure event. > >>>>>> Date: Thu, 21 Nov 2019 21:43:33 +0300 > >>>>>> From: Mikhail Petrov <pmgheap....@gmail.com> > >>>>>> To: Andrey Gura <ag...@apache.org> > >>>>>> > >>>>>> > >>>>>> > >>>>>> Hi, Andrey. > >>>>>> > >>>>>> In my task security plugin running on the coordinator must locally > >>>>>> handle the situation when some node is trying to join the topology with > >>>>>> the invalid configuration. I can't handle the response on a node that > >>>>>> failed to connect because it's untrusted. > >>>>>> > >>>>>> Actually I'm only concerned about one validation -- when all Ignite > >>>>>> components validate new node. > >>>>>> > >>>>>> In my case plugin must be able to obtain general and security subject > >>>>>> information from joining TcpDiscoveryNode attributes. But I have no > >>>>>> idea > >>>>>> how to share information between the security and discovery components > >>>>>> without recording event and listening it locally. > >>>>>> > >>>>>> This event is assumed to be disable by default and in my case used only > >>>>>> on local node so it's not look like "cluster wide event". > >>>>>> > >>>>>> Also I propose to record this event in dedicated utilityPool so it > >>>>>> can't > >>>>>> stuck discovery thread. > >>>>>> > >>>>>> I will appreciate any thoughts on this problem. > >>>>>> > >>>>>> Regards, > >>>>>> Mikhail. > >>>>>> > >>>>>> On 21.11.2019 19:40, Andrey Gura wrote: > >>>>>>> Mikhail, > >>>>>>> > >>>>>>> It is still not enough details to me. What is expected behavior if the > >>>>>>> plugin? > >>>>>>> > >>>>>>> There are a different validations during node join. Many of them > >>>>>>> placed in RingMessageWorker#processJoinRequestMessage method. If > >>>>>>> validation will fail then corresponding message will be sent to the > >>>>>>> joining node (including TcpDiscoveryAuthFailedMessage) and node will > >>>>>>> not joined to topology. > >>>>>>> > >>>>>>> What is purpose of the special cluster wide event? Node is not joined > >>>>>>> to the topology. Why topology nodes should know something about this > >>>>>>> node? > >>>>>>> > >>>>>>> On Thu, Nov 21, 2019 at 9:54 AM Mikhail Petrov <pmgheap....@gmail.com> > >>>>>>> wrote: > >>>>>>>> Hi, Andrey. > >>>>>>>> > >>>>>>>> I take part in the development of a custom security plugin for Apache > >>>>>>>> Ignite. There is an information security requirement for which node > >>>>>>>> joining failures due to invalid configuration must be handled by the > >>>>>>>> plugin. > >>>>>>>> > >>>>>>>> This is where my case comes from. Are there any objections to the > >>>>>>>> proposed approach? > >>>>>>>> > >>>>>>>> Regards, > >>>>>>>> Mikhail. > >>>>>>>> > >>>>>>>> On 20.11.2019 19:38, Andrey Gura wrote: > >>>>>>>>> Hi, Mikhail! > >>>>>>>>> > >>>>>>>>> Could you please describe the case for this new event? > >>>>>>>>> > >>>>>>>>> On Wed, Nov 20, 2019 at 12:45 PM Mikhail Petrov > >>>>>>>>> <pmgheap....@gmail.com> wrote: > >>>>>>>>>> Hello, Igniters. > >>>>>>>>>> > >>>>>>>>>> There is a case which requires to handle joining node validation > >>>>>>>>>> failure > >>>>>>>>>> in Ignite components and obtain information of the node that tried > >>>>>>>>>> to > >>>>>>>>>> join and the reason for the failure. Now, as I see, there is no > >>>>>>>>>> way to > >>>>>>>>>> do it. I propose to implement a new event -- > >>>>>>>>>> NodeValidationFailedEvent > >>>>>>>>>> -- and record it in case the validation fails. I have created > >>>>>>>>>> Tiket [1] > >>>>>>>>>> and PR [2], which shows an example of implementation. Could anyone > >>>>>>>>>> take > >>>>>>>>>> a look at it, please? > >>>>>>>>>> > >>>>>>>>>> [1] https://issues.apache.org/jira/browse/IGNITE-12380 > >>>>>>>>>> > >>>>>>>>>> [2] https://github.com/apache/ignite/pull/7057 > >>>>>>>>>> > > > > -- Best regards, Ivan Pavlukhin
