Note: This guide describes Kentico CMS version 7. Unfortunately, we cannot support this guide from version 8 forward. Go to latest documentation

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

When designing error messages, you should always consider the level of information revealed to the user. If you reveal too much information, the user may be overwhelmed and confused. Moreover, malicious users may exploit this information to gain detailed understanding of the system.

On the other hand, if you do not provide enough information for the user to understand the problem, seeing such error messages may be very frustrating for the user.

Information you should include in the error messages:

  • What is the problem (generic description)
  • What can the user do to fix the problem (suggestions)
  • What can the user do to prevent this problem in the future

Information you should NOT include in the error messages:

  • Stack trace
  • Debug information

 

Handled and unhandled error messages

Be careful about creating error messages for handled errors. Having different error pages for handled and unhandled exceptions can be a great security risk.

You should always have only one message type for both of these cases.

 

 

API example

The following example logs an event in the event log.

private bool LogEvent()
{
     // Logs an information type event
     EventLogProvider.LogEvent(EventLogProvider.EVENT_TYPE_INFORMATION, "API Example", "APIEXAMPLE", eventDescription: "My new logged event.");
     return true;
}

 

 

why?

API example

(Kentico event log)

 

Nedavat informace detailni na vystup pro uzivatele

--------------------------------------------------

- Neprozrazovat utocnikovi zbytecne informace (stacktrace), vzdycky mu ukazat akorat generickou chybu

- web.config nastaveni na custom error pages, nezobrazovat debug, trace na produkci nebo remote userum -> odkaz na jinou kapitolu v security guide

- logovani veci do event logu (muzes vzit example z code examples) misto zobrazovani na miste, kde se chyba stala

- pozor na zobrazovani ruznych chybovych hlasek - vzdycky zobrazovat jednu generickou, stava se, ze web ukaze nejakou hezkou chybovou hlasku v pripade osetrenych chyb a v pripade neosetrenych zobrazi uplne neco jineho, to je spatne, chybova stranka musi byt pouze jedna

 

- time based chyby - jde o to, ze pokud se objevi chyba nejaka, tak muze byt zpracovani stranky casove podstatne jine nez kdyz to probehne normalnim procesovanim. Obcas podle toho utocnici odhaduji, jestli jejich vstup zpusobil nejaky problem a nebo ne. Ale to uz je spis pro lidi s vetsi paranojou :)

 

 

 

 

  • No labels