Project

General

Profile

Bug #14013

DatabaseUtil silently accepts the lack of password file

Added by Gianluca Petrillo about 4 years ago. Updated about 4 years ago.

Status:
Closed
Priority:
Normal
Category:
Other
Target version:
-
Start date:
10/03/2016
Due date:
% Done:

100%

Estimated time:
Spent time:
Occurs In:
Experiment:
-
Co-Assignees:
Duration:

Description

The service DatabaseUtil is supposed to open a database connection using a password provided in a text file, whose name is determined by the service configuration.
The service then looks for that file in the FW_SEARCH_PATH directories.

If the file is not found, though, no special action is taken, but an empty password is used.

Reported by Tingjun Yang.

Associated revisions

Revision b23247c6 (diff)
Added by Gianluca Petrillo about 4 years ago

DatabaseUtil now loudly reacts to the absence of password file.

An exception is thrown, unless the password file name is empty.
This addresses issue #14013.

History

#1 Updated by Gianluca Petrillo about 4 years ago

  • Status changed from New to Assigned
  • Assignee set to Gianluca Petrillo
  • % Done changed from 0 to 80

A proposed solution is offered in branch feature/gp_Issue14013 of lardata.

In there, if the password file is not found, an exception is thrown.
The only way to specify to go without password is to specify an empty file name for the password file itself in the configuration of the service.
The password file name is still mandatory, whether valid or empty.

#2 Updated by Gianluca Petrillo about 4 years ago

  • Status changed from Assigned to Feedback

The suggested change is breaking in that jobs that could survive because either

  1. they actually did not use the database at all, or
  2. the database they accessed had no password

will now fail with that exception. The solution in these cases is respectively:

  1. specify not to try to connect to the database
  2. specify the name of an existing password file, which will be empty

If this behaviour is not acceptable, an alternative is to demote the exception into a warning, although this type of situations is generally considered a fatal error.

#3 Updated by Tingjun Yang about 4 years ago

  • Status changed from Feedback to Closed
  • % Done changed from 80 to 100

I made a few modifications and merged the feature branch into develop.



Also available in: Atom PDF