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 <ptupit...@apache.org> 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 > <arzamas...@mail.ru.invalid> 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
