чт, 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
