Hello! Please avoid targeting feature tickets on 2.8.1 by default.
As far as my understanding goes, plan for 2.8.1 is to be a bugfix release with specific changes cherry picked, so new features are unlikely to be included, and should be negotiated with person responsible for this release before being included in scope. Regards, -- Ilya Kasnacheev вт, 10 мар. 2020 г. в 12:00, Denis Garus <garus....@gmail.com>: > Hi guys! > I created the iep ticket [1] and started work. > > 1. https://issues.apache.org/jira/browse/IGNITE-12759 > > чт, 5 мар. 2020 г. в 12:00, Denis Garus <garus....@gmail.com>: > > > Hi, guys! > > > > > > I've prepared the IEP-41: Security Context of a thin client on remote > > nodes [1]; take a look, please. > > > > If there aren't any questions, I could create an issue and start work. > > > > > > Ivan, could you be an IEP sponsor? > > > > > > Thx! > > > > > > > > 1. > > > https://cwiki.apache.org/confluence/display/IGNITE/IEP-41%3A+Security+Context+of+a+thin+client+on+remote+nodes > > > > > > ср, 26 февр. 2020 г. в 12:42, Mikhail Petrov <pmgheap....@gmail.com>: > > > >> Hi, Alexei. > >> > >> The ticket [1] describes the general problem for all thin client > >> authorizations. Its particular case is described in the mentioned in [1] > >> ticket [2] on the example of a JDBC client with the reproducer > attached. > >> > >> [1] https://issues.apache.org/jira/browse/IGNITE-12589 > >> [2] https://issues.apache.org/jira/browse/IGNITE-12579 > >> > >> On 26.02.2020 11:47, Alexei Scherbakov wrote: > >> > Denis Garus, > >> > > >> > It is forbidden to remove any public IGNITE attribute without proper > >> > deprecation steps. > >> > > >> > I have read the thread and still do not clearly see the problem. The > >> subject id > >> > is not required to be a node id. > >> > > >> > The referenced in the thread ticket [1] do not provide any > reproducers. > >> > > >> > Can you properly demonstrate a broken scenario ? > >> > > >> > [1] https://issues.apache.org/jira/browse/IGNITE-12589 > >> > > >> > пт, 21 февр. 2020 г. в 13:35, Andrey Kuznetsov <stku...@gmail.com>: > >> > > >> >> Hi, guys! > >> >> > >> >> The change suggested by Denis looks robust to me: it covers security > >> >> subject handling by all kinds of clients/nodes at once. As for > >> >> ATTR_SECURITY_SUBJECT_V2 attribute, it is really better to move it to > >> >> plugin implementations to support backward compatibility with peer > >> nodes of > >> >> older versions. Obviously, cluster with security disabled will not > >> suffer > >> >> from attribute removal. Ignite core should know nothing about the > >> specific > >> >> way of security context propagation. > >> >> > >> >> Denis, could you please create Jira issue for your change? > >> >> > >> >> чт, 20 февр. 2020 г. в 17:01, Denis Garus <garus....@gmail.com>: > >> >> > >> >>>> I just transmitted security subjects for rest requests. > >> >>> SecurityContext has an unlimited size so we can get significant > >> overhead. > >> >>> And we do not solve problems with other thin clients. > >> >>> > >> >>>> If you remove ATTR_SECURITY_SUBJECT_V2, it breaks compatibility > >> between > >> >>> old > >> >>> versions and new. > >> >>> > >> >>> I suggest removing ATTR_SECURITY_SUBJECT_V2 from Ignite's codebase, > >> but > >> >> for > >> >>> compatibility, it can be used by a security plugin like in PoC. > >> >>> > >> >>> чт, 20 февр. 2020 г. в 16:47, Maksim Stepachev < > >> >> maksim.stepac...@gmail.com > >> >>>> : > >> >>>> Yes, I said about it at 07.19. > >> >>>> > >> >>>> > >> >> > >> > http://apache-ignite-developers.2346864.n4.nabble.com/Improvements-for-new-security-approach-td42698.html#a42708 > >> >>>> And in my solution, I just transmitted security subjects for rest > >> >>> requests. > >> >>>> If you remove ATTR_SECURITY_SUBJECT_V2, it breaks compatibility > >> between > >> >>> old > >> >>>> versions and new. > >> >>>> > >> >>>> чт, 20 февр. 2020 г. в 15:56, Denis Garus <garus....@gmail.com>: > >> >>>> > >> >>>>> Hi, Igniters! > >> >>>>> > >> >>>>> > >> >>>>> At present, a security subject id is assumed to be node id. > >> >>>>> > >> >>>>> But when we are dealing with thin client, JDBC or REST subject id > is > >> >>>> random > >> >>>>> UUID. In this case, we cannot get the subject information on a > >> remote > >> >>>> node, > >> >>>>> and we get problems like these [1], [2]. > >> >>>>> > >> >>>>> To fix the problem, we should spread the client session to the > whole > >> >>>>> cluster. > >> >>>>> > >> >>>>> > >> >>>>> I want to suggest a solution to the problem. > >> >>>>> > >> >>>>> > >> >>>>> First, we should get subject information using > >> GridSecurityProcessor. > >> >>>>> > >> >>>>> How GridSecurityProcessor will retrieve a subject data, it is up > to > >> >>>> plugin > >> >>>>> developers. > >> >>>>> > >> >>>>> > >> >>>>> Second, we should get rid of the assumption that a subject id is a > >> >> node > >> >>>> id > >> >>>>> and remove the ATTR_SECURITY_SUBJECT_V2 attribute. > >> >>>>> > >> >>>>> > >> >>>>> I have prepared PoC PR [3] that: > >> >>>>> > >> >>>>> - places the existing logic of spreading security context to > >> >>>>> GridSecurityProcessor; > >> >>>>> > >> >>>>> - uses GridSecurityProcessor to get SecurityContext. > >> >>>>> > >> >>>>> > >> >>>>> > >> >>>>> 1. > >> >>>>> > >> >>>>> > >> >> > >> > http://apache-ignite-developers.2346864.n4.nabble.com/JDBC-thin-client-incorrect-security-context-td45929.html > >> >>>>> 2. https://issues.apache.org/jira/browse/IGNITE-12589 > >> >>>>> 3. https://github.com/apache/ignite/pull/7375 > >> >>>>> > >> >> > >> >> -- > >> >> Best regards, > >> >> Andrey Kuznetsov. > >> >> > >> > > >> > > >
