[Twisted-Python] Re: [Twisted-commits] InMemoryUsernamePasswordDatabaseDontUse didn't raise the error properly when the password was wrong
On Sun, 28 Sep 2003 17:44:47 -0600 teratorn CVS <teratorn@wolfwood.twistedmatrix.com> wrote:
- return failure.Failure(error.UnauthorizedLogin()) + raise error.UnauthorizedLogin()
Uh. Why does one work and not the other? That looks like a bug in Deferred to me. Aren't returned Failures supposed to be the same as raised exceptions in callbacks? -- Itamar Shtull-Trauring http://itamarst.org/ Available for Python & Twisted consulting
Itamar Shtull-Trauring wrote:
On Sun, 28 Sep 2003 17:44:47 -0600 teratorn CVS <teratorn@wolfwood.twistedmatrix.com> wrote:
- return failure.Failure(error.UnauthorizedLogin()) + raise error.UnauthorizedLogin()
Uh. Why does one work and not the other? That looks like a bug in Deferred to me. Aren't returned Failures supposed to be the same as raised exceptions in callbacks?
Considering that the two are equivalent, the former style is preferred in situations like this, since it does not create Python traceback info (which is _noticeably_ slower than not doing it).
On Sun, Sep 28, 2003 at 08:04:45PM -0400, Glyph Lefkowitz wrote:
Itamar Shtull-Trauring wrote:
On Sun, 28 Sep 2003 17:44:47 -0600 teratorn CVS <teratorn@wolfwood.twistedmatrix.com> wrote:
- return failure.Failure(error.UnauthorizedLogin()) + raise error.UnauthorizedLogin()
Uh. Why does one work and not the other? That looks like a bug in Deferred to me. Aren't returned Failures supposed to be the same as raised exceptions in callbacks?
Considering that the two are equivalent, the former style is preferred in situations like this, since it does not create Python traceback info (which is _noticeably_ slower than not doing it).
... and then gets send to the PB client, producing a full traceback on the client side, instead of just a one-line exception string. In this case, that means the client is able to discern between invalid usernames and invalid passwords, which would be a serious problem, if we were talking about anything other than InMemoryUsernamePassword- DatabaseDontUse. As it is, I think InMemoryUsernamePasswordDatabaseDontUse should intentionally reveal even more information about why the login failed (making it more useful for debugging and less useful for production), and the difference between returning a Failure constructed from an exception and raising an exception in a callback be spelled out explicitly somewhere. Who knows when the difference will be forgotten and something unintentionally revealed, as it was in InMemoryUsernamePasswordDatabaseDontUse? Jp -- #!/bin/bash ( LIST=(~/.sigs/*.sig) cat ${LIST[$(($RANDOM % ${#LIST[*]}))]} echo -- $'\n' `uptime | sed -e 's/.*m//'` ) > ~/.signature
On Sun, 28 Sep 2003 20:31:16 -0400 Jp Calderone <exarkun@intarweb.us> wrote:
In this case, that means the client is able to discern between invalid usernames and invalid passwords, which would be a serious problem, if we were talking about anything other than InMemoryUsernamePassword- DatabaseDontUse. As it is, I think InMemoryUsernamePasswordDatabaseDontUse should intentionally reveal even more information about why the login failed(making it more useful for debugging and less useful for production), and the difference between returning a Failure constructed from an exception and raising an exception in a callback be spelled out explicitly somewhere. Who knows when the difference will be forgotten and something unintentionally revealed, as it was in InMemoryUsernamePasswordDatabaseDontUse?
I don't think PB failures should sent *ANY* traceback info. In fact, I can't figure out how to prevent that from happening even on a case by case basis. -- Itamar Shtull-Trauring http://itamarst.org/ Available for Python & Twisted consulting
participants (3)
-
Glyph Lefkowitz -
Itamar Shtull-Trauring -
Jp Calderone