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/ >
