Unable to get the security context
Hi, I have implemented the grid security processor and setting the securityconext holder in the authenticate function as below, public class MySecurityProcessor extends GridProcessorAdapter implements DiscoverySpiNodeAuthenticator, GridSecurityProcessor, IgnitePlugin { public SecurityContext authenticate(AuthenticationContext authenticationContext) throws IgniteCheckedException { SecuritySubject secureSecuritySubject = new SecuritySubject( authenticationContext.subjectId(), authenticationContext.subjectType(), authenticationContext.credentials().getLogin(), authenticationContext.address() ); SecurityContext securityContext = new MySecurityContext(secureSecuritySubject, accessToken); SecurityContextHolder.set(securityContext); return securityContext; } public void authorize(String name, SecurityPermission perm, SecurityContext securityCtx) throws SecurityException { System.out.println( SecurityContextHolder.get()); System.out.println( securityCtx ); //do some authorization . } public boolean isGlobalNodeAuthentication() { // TODO Auto-generated method stub return false; } .. } In plugin provider i am creating the component : GridSecurityProcessor. During Rest api call: -> when rest call is made authorise function in the security processor is getting called twice one by the GridRestProcessor and another GridCacheProcessor, is it mandatory to call that twice? When authorise function is called by the GridRestProcessor security context is available but when the GridCacheProcessor is called security context is coming as null always. Hence the security context is not available in the authorise function. So i used the SecurityContextHolder.get() to get the security context. But for some of the commands SecurityContextHolder.get() is not working like prepend and append. -> When cache create and cache destroy is made, authorise function is receiving the name as NULL. Why is it so? Because based on the name i am trying to validate wheather the user is allowed to perform this action During Sqlline access: -> authorise function receive the security context as NULL always . So used the SecurityContextHolder.get() , but still getting NULL. How do i get the context? -> While performing create table and drop table, the authorise function is receiving the name as NULL. One last question: when the security context is null(during rest call or sqlline access), can we use the local node context in the authorise function? Regards Radha
class loading, peer class loading, jars, fun times in ignite
I am fairly certain that I don't know how to use peer class loading properly. Am using Apache Ignite 2.7. If I have a node running on 192.168.1.2 with a peer class loading enabled, and I start up a second node - 192.168.1.3, client mode enabled and peer class loading enabled, then I expected the following: Running the snippet (based on https://apacheignite.readme.io/docs/getting-started#section-first-ignite-data-grid-application ) on the client (192.168.1.3): try (Ignite ignite = Ignition.start("examples/config/example-ignite.xml")) { IgniteCache cache = ignite.getOrCreateCache("myCacheName"); // Store keys in cache (values will end up on different cache nodes). for (int i = 0; i < 10; i++) cache.put(i,new MyWrapperOfString( Integer.toString(i))); for (int i = 0; i < 10; i++) System.out.println("Got [key=" + i + ", val=" + cache.get(i) + ']'); } Would cause the cache of "MyWrapperOfString" instances to be available on 192.168.1.2 and on 192.168.1.3 . Also be able to observe the cache using visor, etc However - I instead get an error that the class "MyWrapperOfString" is not available on 192.168.1.2. Now if I take the jar that the class is packed, and place it in the lib folder, all is happy. Should I have to do this? If yes - how do I update the jar if I have a cluster of nodes doing this? Do I have to shutdown the entire cluster in order to not have class loader problems? I thought the peer class loading is supposed to solve this problem. I think it would be VERY INSTRUCTIVE for the snippet that I anchored to not use a standard java library cache object, but to demonstrate the need to package value object into a jar and stuff it into the lib folder (If this is what is expected). Running lambdas that use basic java primitives is cool, but is this the normal? Switching up Is there interest in me creating class loader that would load java classes into the vm that could be incorporated into ignite? So instead of reading a jar, you load the class bytes into a cache . You want to hot load a new class? Fine ! pump into the DISTRIBUTED_CLASS_PATH_CACHE . Cheers. SCott
[jira] [Created] (IGNITE-11876) control.sh idle verify --cache-filter doesn't work without --dump option
Sergey Antonov created IGNITE-11876: --- Summary: control.sh idle verify --cache-filter doesn't work without --dump option Key: IGNITE-11876 URL: https://issues.apache.org/jira/browse/IGNITE-11876 Project: Ignite Issue Type: Bug Reporter: Sergey Antonov At this moment control.sh {{--cache idle_verify --cache-filter PERSISTENT}} doesn't work (see {{VerifyBackupPartitionsTaskV2#isCacheMatchFilter()}}). We should fix it. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11875) Thin client is unable to authenticate with long password
Igor Sapego created IGNITE-11875: Summary: Thin client is unable to authenticate with long password Key: IGNITE-11875 URL: https://issues.apache.org/jira/browse/IGNITE-11875 Project: Ignite Issue Type: Bug Components: jdbc, odbc, thin client Affects Versions: 2.7 Reporter: Igor Sapego Assignee: Igor Sapego Fix For: 2.8 Token authentication could use long usernames/passwords, that leads to "Invalid handshake message" ClientListenerNioServerBuffer: {code:java} if (cnt == msgSize) { byte[] data0 = data; reset(); return data0; } else { if (checkHandshake && cnt > 0 && (msgSize > ClientListenerNioListener.MAX_HANDSHAKE_MSG_SIZE || data[0] != ClientListenerRequest.HANDSHAKE)) throw new IgniteCheckedException("Invalid handshake message"); return null; } {code} The reproducer is attached. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: C++ thin/thick client: how do a do SQL queries on a distant server?
Hello! Thick Client needs to discover your topology and then it is able to query any data in it. I think you should ask this question on userlist@ for more low level answer. Regards, -- Ilya Kasnacheev вт, 28 мая 2019 г. в 01:06, j.da...@qwant.com : > Everything is in the title. > > I'd like to either manipulate SQL queries or serialized Object on a distant > ignite cluster, > but so far, I only found how to define endPoints on the thin client > configuration (nothing equivalent > on the thick client). > I haven't found how to do anything else than key/scalar-value using the > thin > client. > > Thx in advance > > > > -- > Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/ >