Opened 11 years ago

Closed 10 years ago

Last modified 10 years ago

#533 closed bug (fixed)

XML dump when an error occurs is too verbose

Reported by: jeanyves Owned by: fake51
Priority: critical Milestone: Rox Framework, Upgrade
Component: FrameWork Keywords: password XML security
Cc: lemon-head, steinwinde


The problem is that some password (database, and even some user one) can be displayed in it.

Since it is mainly for the user eyes this is not a big risk for the user himself, but we have had a case where such a report (by the user who copy paste the error message) finally arrive in the BV forum. This was allowing any reader of the BV Forum to read the Username and the password of the user !

This is to fix (to find a way to avoid password content display in these XML error dump)

in addition : this show that the BV Volunteer forum is something which is for volunteer and not for anonym visitors, because here can be reported various case with very sensible information.

Change History (11)

comment:1 Changed 11 years ago by lemon-head

  • Milestone changed from 0.1.5 - short - xxx to Rox Framework, Upgrade

I set the milestone to "Rox Framework, Upgrade" because the basic new framework stuff will work quite well without an improved error display. This means, a solution for this problem can be moved online any time after the basic framework stuff is on production.

In general I totally agree with the request! And even for, the XML error page is totally annoying, as it mixes with the html and makes the browser complain about invalid XML.

comment:2 Changed 11 years ago by guaka

  • Cc lemon-head steinwinde added; lemon-head steinewinde removed
  • follow_up changed from none to test
  • Summary changed from XML dump when an error occurs is to verbose to XML dump when an error occurs is too verbose

comment:3 Changed 11 years ago by midsch

What is to be tested here?

comment:4 Changed 11 years ago by jeanyves

  • follow_up changed from test to review code

I don't know how to test this.

The problem is that some error occurs with, for example database access, this can result with a dump on screen with non public data and with database password if the failure was with database connection

Before speaking about testing it, we need someone to work on it, for now I dont have a lot of idea.

  • May be no more dump except if the $_SESSIONIdMember? is within some hardcoded list or if the $_SERVERSERVERNAME? does not contain ?

@Andreas, or Felix : probably you are in the best position to propose something ?

I change the status to review code

comment:5 Changed 10 years ago by micha

  • freq_reported changed from 1 to 5

what's the status on this?

comment:6 Changed 10 years ago by jeanyves

I think it is not solved so far We havent seen it recently because parameters for database are fine and mysql is running, the to do test is to stop mysql (for example) and observe what happens

comment:7 Changed 10 years ago by fake51

  • Owner set to fake51

comment:8 Changed 10 years ago by fake51

  • follow_up changed from review code to release

Production no longer displays exception output - it displays a fail/sorry message instead.

I've tested it by throwing an exception - not sure if there's more we can do about it, short of finding pages that fail horribly by themselves.

comment:9 Changed 10 years ago by fake51

One thing to keep in mind: currently alpha will STILL spit out exception info. We should really split off the production DB into production and alpha

comment:10 Changed 10 years ago by fake51

  • Resolution set to fixed
  • Status changed from new to closed

All exceptions are now logged to ./htdocs/exception.log

comment:11 Changed 10 years ago by globetrotter_tt

  • follow_up changed from release to none
Note: See TracTickets for help on using tickets.