Re: security question - custom plugin

Hi, 1) You need to add jetbrains annotation in compile-time [1]. 2) Imports depend on what are you using :) It's hard to say if your imports enough. Add ignite-core to your plugin dependencies. I don't think that there are other examples besides that blog post. [1]

security question - custom plugin

I am looking at the http://smartkey.co.uk/development/securing-an-apache-ignite-cluster/ example but it doesn't dive into details and when trying to build one myself i am unsure of the following 1) what imports are needed for the annotations is it org.jetbrains.annotations? 2) i have the

Re: POC with DataStreamer (Kafka or Ignite - security question)

Built-in encryption facilities are being discussed on the dev list. Check it up: http://apache-ignite-developers.2346864.n4.nabble.com/IEP-18-Transparent-Data-Encryption-td29001.html As for now, use operating system level encryption mechanics for your files. -- Denis -- Denis On Fri, Apr 6,

Re: POC with DataStreamer (Kafka or Ignite - security question)

Also I don't think ignite provides any kind encryption for these db files. Best Regards, Gaurav On 06-Apr-2018 8:23 PM, "David Harvey" wrote: > Assuming Ignite Persistence, you can create a cache in a specific Data > Regions, but I'm unclear whether this properties can be

Re: POC with DataStreamer (Kafka or Ignite - security question)

Assuming Ignite Persistence, you can create a cache in a specific Data Regions, but I'm unclear whether this properties can be set per region. We are setting them in org.apache.ignite.configuration.DataStorageConfiguration. What you seem to be asking for is to set these per Data Region.

Re: Security question

Thanks Dmitry, that makes sense, we will make sure that client-side code is trusted. Franck -- Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Re: Security question

Franck, You're definitely right, but this is more like client roles than regular security. On "they have a number of connected clients with actual applications" I meant that user's application is connected to the grid via clients with their local permissions. But end user cannot access the grid

Re: Security question

Wow. That means any client who can get past node authentication on join can do anything they like on all caches, including all admin commands. The node validation logic won't help at all - the join request may claim that a given security processor is used, but subsequent requests can perfectly be

Re: Security question

Hi Franck, Yes, here is used client-side security, looks like it was made to allow connect of different clients with different permissions. But it depends on GridSecurityProcessor. For example, it may have a node validation logic that will not accept nodes with unapproved security processor. In

Security question

Hi all, Stepping through the code during a cache.get() request from a client node to a server node, I don't see that GridSecurityProcessor.authorize will ever be called on the server node? Authorize is called on the client node, but on the server node the code goes straight to