> Even if compact footer is disabled ? Footer is checked in postWrite - much later class descriptor check.
чт, 23 янв. 2020 г., 12:23 Alexei Scherbakov <alexey.scherbak...@gmail.com>: > чт, 23 янв. 2020 г. в 12:17, Dmitrii Ryabov <somefire...@gmail.com>: > > > > The protocol must be language-agnostic. If we add some features there, > > let's make sure they are usable from anywhere. > > > > That's why I want to allow primitives only. Any language can send numbers > > and strings. > > > > In general it's possible to have cross-platform complex data structures, > for example see protobuf. > > > > > > Binary marshaller, before packing object to byte[], will try to use > > discovery processor and send message containing class descriptor. But > thin > > clients don't have discovery. Furthermore, if we write binary marshaller > > without class descriptor synchronization, we can get objects with > different > > class versions and corresponding exceptions. > > > > Even if compact footer is disabled ? > > > > > > But we can say users to declare their classes in > > META-INF/classnames.properties and current binary marshaller will works > > good. > > > > This approach doesn't looks like cross-platform. > > > > > > чт, 23 янв. 2020 г., 12:13 Alex Plehanov <plehanov.a...@gmail.com>: > > > > > Hello, > > > > > > User attributes also (besides authentication) can be used to pass some > > info > > > about an application that uses a client and then display this > information > > > in monitoring tools. Other vendors use such approach (Oracle DB, for > > > example, have DBMS_APPLICATION_INFO package, PostgreeSQL have > > > application_name connection property and application information > > available > > > later in system views). > > > > > > About allowed data types: we should definitely limit attribute types to > > > only primitive types. Thin client binary marshaller can't send > > information > > > about custom types before the handshake. > > > > > > > > > ср, 22 янв. 2020 г. в 21:39, Pavel Tupitsyn <ptupit...@apache.org>: > > > > > > > I've looked through the PR more closely, trying to understand the use > > > case, > > > > and there are some Java-specific things going on (left a comment). > > > > Please keep in mind that we have thin clients in Python, Node.js, > C++, > > > C#. > > > > The protocol must be language-agnostic. If we add some features > there, > > > > let's make sure they are usable from anywhere. > > > > > > > > On Wed, Jan 22, 2020 at 9:21 PM Pavel Tupitsyn <ptupit...@apache.org > > > > > > wrote: > > > > > > > > > The approach with UserAttributes map looks dirty to me and raises > > > > > questions: > > > > > > > > > > - Why is UserAttributes property related to authentication? > > > > > - UserAttributes name implies that users can put there anything > they > > > > want, > > > > > but what for? What are those additional use cases? > > > > > > > > > > I think we should focus on a specific problem at hand and avoid > > > > > unnecessary future-proofing. > > > > > What are current and potential future custom authenticators and > what > > > kind > > > > > of data do they need? > > > > > > > > > > On Wed, Jan 22, 2020 at 6:28 PM Nikita Amelchev < > > nsamelc...@gmail.com> > > > > > wrote: > > > > > > > > > >> I think we should add this. It will provide an extra level of > > > security. > > > > >> This approach is used in many products, for example in AWS (MFA). > > [1] > > > > >> > > > > >> [1] > > > > >> > > > > > > > > > > https://docs.aws.amazon.com/general/latest/gr/aws-sec-cred-types.html#multi-factor-authentication > > > > >> > > > > >> ср, 22 янв. 2020 г. в 18:13, Andrey Kuznetsov <stku...@gmail.com > >: > > > > >> > > > > > >> > Hi, Pavel! > > > > >> > > > > > >> > Sometimes single authentication factor is not enough. Attributes > > > > >> proposed > > > > >> > allow to add extra factors flexibly. > > > > >> > > > > > >> > ср, 22 янв. 2020 г., 17:39 Pavel Tupitsyn <ptupit...@apache.org > >: > > > > >> > > > > > >> > > Token can be sent instead of a password (like git works with > > > GitHub > > > > >> > > tokens). > > > > >> > > > > > > >> > > For now I don't see a reason to include attributes into the > > > > handshake > > > > >> > > message. > > > > >> > > > > > > >> > > On Wed, Jan 22, 2020 at 5:32 PM Ilya Kasnacheev < > > > > >> ilya.kasnach...@gmail.com > > > > >> > > > > > > > >> > > wrote: > > > > >> > > > > > > >> > > > Hello! > > > > >> > > > > > > > >> > > > One does not send security certificate as attribute. The > only > > > way > > > > to > > > > >> > > obtain > > > > >> > > > peer security certificate is to ask SSL engine to provide > it. > > > > >> > > > > > > > >> > > > Nevertheless, I can see how it can be useful with e.g. > > Kerberos, > > > > >> which is > > > > >> > > > token-based IIRC. > > > > >> > > > > > > > >> > > > Regards, > > > > >> > > > -- > > > > >> > > > Ilya Kasnacheev > > > > >> > > > > > > > >> > > > > > > > >> > > > ср, 22 янв. 2020 г. в 17:20, Dmitrii Ryabov < > > > > somefire...@gmail.com > > > > >> >: > > > > >> > > > > > > > >> > > > > This map is something like user object from > > > > `SecurityCredentials`. > > > > >> > > > > Sometimes login and password are not enough for security > > > checks. > > > > >> For > > > > >> > > > > example, we can send security certificate and validate it > > > inside > > > > >> > > > > authenticator. > > > > >> > > > > > > > > >> > > > > ср, 22 янв. 2020 г., 17:16 Igor Sapego < > isap...@apache.org > > >: > > > > >> > > > > > > > > >> > > > > > Hi Dmitrii, > > > > >> > > > > > > > > > >> > > > > > Can you please explain your use case? > > > > >> > > > > > I'm not sure I'm getting what is the motivation of this > > > > change. > > > > >> > > > > > > > > > >> > > > > > Best Regards, > > > > >> > > > > > Igor > > > > >> > > > > > > > > > >> > > > > > > > > > >> > > > > > On Wed, Jan 22, 2020 at 5:11 PM Pavel Tupitsyn < > > > > >> ptupit...@apache.org > > > > >> > > > > > > > >> > > > > > wrote: > > > > >> > > > > > > > > > >> > > > > > > Hi Dmitrii, > > > > >> > > > > > > > > > > >> > > > > > > Honestly, I could not grasp the problem, can you > explain > > > it > > > > >> in more > > > > >> > > > > > detail? > > > > >> > > > > > > What do we solve by adding a map with arbitrary stuff > to > > > the > > > > >> client > > > > >> > > > > > > protocol handshake? > > > > >> > > > > > > > > > > >> > > > > > > On Wed, Jan 22, 2020 at 5:02 PM Dmitrii Ryabov < > > > > >> > > > somefire...@gmail.com> > > > > >> > > > > > > wrote: > > > > >> > > > > > > > > > > >> > > > > > > > Hello, Igniters! > > > > >> > > > > > > > > > > > >> > > > > > > > I want to add the possibility of sending user > defined > > > > >> attributes > > > > >> > > > from > > > > >> > > > > > > thin > > > > >> > > > > > > > clients. And check them inside custom authenticator > > > during > > > > >> > > > handshake > > > > >> > > > > > [1]. > > > > >> > > > > > > > > > > > >> > > > > > > > There is an issue in hardcoded binary writer for > JDBC > > > and > > > > >> > > > > > `IgniteClient`. > > > > >> > > > > > > > This writer searches for a classes in the JDK and > > > > >> > > > > > > > META-INF/classnames.properties, and tries to sync > > > > >> notdeclared > > > > >> > > > classes > > > > >> > > > > > > with > > > > >> > > > > > > > cluster. But fails because current classloading uses > > > > >> discovery. > > > > >> > > > > > > > > > > > >> > > > > > > > I'd like to keep this writer and allow only > primitive > > > > types > > > > >> and > > > > >> > > > > > `String` > > > > >> > > > > > > > for user attributes to prevent unexpected fails. I > > think > > > > it > > > > >> is > > > > >> > > > better > > > > >> > > > > > > than > > > > >> > > > > > > > changing writer to one with heavy classloading. > > > > >> > > > > > > > > > > > >> > > > > > > > Is it ok to restrict thin attributes to primitives > and > > > > >> 'String'? > > > > >> > > > > > > > > > > > >> > > > > > > > [1] > > https://issues.apache.org/jira/browse/IGNITE-12049 > > > > >> > > > > > > > > > > > >> > > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > >> > > > > > > > >> > > > > > > >> > > > > >> > > > > >> > > > > >> -- > > > > >> Best wishes, > > > > >> Amelchev Nikita > > > > >> > > > > > > > > > > > > > > > > > -- > > Best regards, > Alexei Scherbakov >
