Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Layer reporting for postgis authentication failure #1046

Closed
tmcw opened this issue Jan 23, 2012 · 6 comments
Closed

Layer reporting for postgis authentication failure #1046

tmcw opened this issue Jan 23, 2012 · 6 comments

Comments

@tmcw
Copy link
Contributor

tmcw commented Jan 23, 2012

Certain PostGIS failures log the name of the layer and map, like tables not existing, but auth errors include no such metadata. We should add a similar level of logging against errors if possible.

@springmeyer
Copy link
Member

What did the auth errors look like for you?

@tmcw
Copy link
Contributor Author

tmcw commented Jan 24, 2012

Sorry, needed more context: this is taken from http://support.mapbox.com/discussions/general-questions/444-mapbox-throws-no-errors-but-doesnt-render-a-map

If you have an invalid database username or password in the project.mml, it doesn't show any error unless you change a style and hit "save", at which point it tells you "Error: Postgis Plugin: FATAL: password authentication failed for user "your_user"" but not which layer was at fault, or what username/password was invalid.

@artemp
Copy link
Member

artemp commented Jan 24, 2012

FATAL: password authentication failed for user "your_user"" -- this is what libpq (client library) reports.

I appended 'connection_str' in 19deb86 so you should get something like :

RuntimeError: Postgis Plugin: FATAL:  role "postgres" does not exist
 dbname=osm user=postgres password=xxx connect_timeout=4

In future, we should move fancy error message formatting out of mapnik core into client code (#1044)

@springmeyer
Copy link
Member

connection string was intentionally NOT printed there so that the password would not appear. If we print it then I think we'll need a custom "safe" version of the connection string.

@artemp
Copy link
Member

artemp commented Jan 24, 2012

Good point :)

On Jan 24, 2012 7:31 PM, "Dane Springmeyer" <
reply@reply.github.com>
wrote:

connection string was intentionally NOT printed there so that the
password would not appear. If we print it then I think we'll need a custom
"safe" version of the connection string.


Reply to this email directly or view it on GitHub:
#1046 (comment)

@springmeyer
Copy link
Member

closing, "Safe" version added in 9afaf09

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants