> 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. 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. But we can say users to declare their classes in META-INF/classnames.properties and current binary marshaller will works good. чт, 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 > > >> > > > > > >
