crossbario / autobahn-python

WebSocket and WAMP in Python for Twisted and asyncio
https://crossbar.io/autobahn
MIT License
2.48k stars 768 forks source link

Hide unexpected exceptions #609

Open sehoffmann opened 8 years ago

sehoffmann commented 8 years ago

Currently any exception raised in e.g a endpoint will be reported back with its error message to the caller. I consider it really bad, that a caller might receives back sqlalchemy.exc.OperationalError: (_mysql_exceptions.OperationalError) (1045, "Access denied for user 'abc'@'localhost' (using password: NO)").

I propose that any exception which is not a or deriving from ApplicationError or which is not mapped to an uri, should report back something similiar like a HTTP 500 error. In particular: If we go into this branch protocol.py#L157, the error message should be replaced with something like "Internal server error".

So any exception deriving from ApplicationError or which has been registered with BaseSession.define will report back the actual error message just fine, but any unexpected exception will have it's error message hidden.

PS: A traceback should of course also not be transmitted in this case

potens1 commented 8 years ago

Hi, to participate in the discussion, I understand why you consider it bad since it can disclose security details, but, for another point of view, if you are coding microservices, it is really helpful to get almost the real exception when doing calls, so you can write code that acts differently to different exceptions. The thing is, here there is two opposite points of view, a) you silence every exceptions and return a generic error code but for those that you choose, b) you pass exceptions as-is except for those that you choose to silence (try...except: raise GenericException("Something wrong") in the calee) I'm more an adept of the second option (Explicit is better than implicit, never silence exception unless explicitly silenced). That said, maybe we could change the doc to explicitly tell about the exceptions and security implications of it.

Maybe there could also be a way to setup the router to intercept every exceptions (or based from source,destination or both) an do things with it (i.e. convert it to generic return code and/or log it) but this is changing the router to add some business logic in it.