Guys, does anyone else bothers about it ?)
Ones more — i really not sure that all exceptions have been thrown from server
side have informative message visible from client side, if client would receive
full stack trace from server side it would reduce additional efforts from
cluster administrator side, in one case i agree here — this is not pretty a bit.
If no quorum would be here — ok, i fill a ticket for optionally enable such
behavior, as was discussed earlier, and leave the current one as it is.
thanks !
>Hi,
>
>I agree with Zhenya, that a stack from server side will be able to help in
>investigation of issues, but it really confused in production environment.
>I see all participants tell the same.
>
>Pavel, do you mean this behavior should be switching by configuration?
>
>On Thu, Aug 20, 2020 at 5:00 PM Pavel Tupitsyn < [email protected] > wrote:
>
>> Link to the original discussion:
>>
>>
>>
>> http://apache-ignite-developers.2346864.n4.nabble.com/Exception-handling-in-thin-client-should-we-pass-stack-traces-to-the-client-td22392.html
>>
>> On Thu, Aug 20, 2020 at 4:46 PM Zhenya Stanilovsky
>> < [email protected] > wrote:
>>
>> >
>> > I want to resurrect this discussion, i don`t understand what sensitive
>> > information you are talking about ?
>> > Can you show some examples or something else ? I never listen that thread
>> > dumps belong to sensitive info.
>> > I believe that one linear error can`t help user to recognize problem and
>> > logs from server side can be simple unreachable or logging disabled at
>> all.
>> > So i suggest to request full thread dump in case of server side error
>> > occurred.
>> >
>> > what do you think ?
>> >
>> >
>> > >Igniters,
>> > >
>> > >We had a discussion about how to propagate error information from
>> cluster
>> > >nodes to the client. My opinion is that we should pass a kind of vendor
>> > >code plus optional error message, if vendor code is not very specific.
>> > >
>> > >Alternative idea is to pass the whole stack trace as well. I agree that
>> > >this is very useful for debugging purposes, but on the other hand IMO it
>> > >imposes security risk. By sending invalid requests to the server user
>> > might
>> > >get sensitive information about server configuration, such as it's
>> > version,
>> > >version of the underlying database, frameworks etc.. This information
>> may
>> > >help attacker to apply some version-specific attacks. This is precise
>> > >reason why default error pages of web servers with stack traces are
>> always
>> > >replaces with some stubs.
>> > >
>> > >This is why I think we should not include stack traces.
>> > >
>> > >What do you think?
>> > >
>> > >Vladimir.
>> >
>> >
>> >
>> >
>>
>
>--
>Vladislav Pyatkov
>