[Twisted-Python] Is it necessary to utilize twisted.cred in twisted web?
I have googled this topic and found and example in (A) http://www.mail-archive.com/twisted-web@twistedmatrix.com/msg01796.html well, another simpler example is (B) http://www.mail-archive.com/twisted-web@twistedmatrix.com/msg01788.html My questions are: 1. Does the approach in (A) be recommended? To generate resource dynamically seems not efficient and not necessary for simple scenario. Is there other way to bind twisted.cred and twisted.web together? (except the deprecated twisted.web.guard) 2. The approach in (B) which suggests that request.getSession() along is quite enough to implement an simple authentication feature. Here the "simple scenario" means to guard some resource with username and password. To do it: In a protected resource, just to check for a flag in the session, if failure, then redirect to login page. If succeeded, render the resource. Why shall we bother the portal, credentials, checker,.... ? Any suggestion? Thanks in advance.
Hi, I'd love to provide a 'canonical answer' to this question, but unfortunately it is something that I've been confused with in the past too. I'm hoping there is a sort of 'best practice' answer to this, and I'd additionally hope that this answer might appear in this extremely good running series on Twisted Web: http://jcalderone.livejournal.com/tag/sixty+seconds thanks, Alex On Mon, Oct 5, 2009 at 9:08 PM, biziap biziap <fetbiz@gmail.com> wrote:
I have googled this topic and found and example in (A) http://www.mail-archive.com/twisted-web@twistedmatrix.com/msg01796.html well, another simpler example is (B) http://www.mail-archive.com/twisted-web@twistedmatrix.com/msg01788.html
My questions are: 1. Does the approach in (A) be recommended? To generate resource dynamically seems not efficient and not necessary for simple scenario. Is there other way to bind twisted.cred and twisted.web together? (except the deprecated twisted.web.guard)
2. The approach in (B) which suggests that request.getSession() along is quite enough to implement an simple authentication feature. Here the "simple scenario" means to guard some resource with username and password. To do it: In a protected resource, just to check for a flag in the session, if failure, then redirect to login page. If succeeded, render the resource. Why shall we bother the portal, credentials, checker,.... ?
Any suggestion? Thanks in advance.
_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
-- Alex Clemesha clemesha.org
crossposted to twisted-web@twistedmatrix.com, which is probably a better venue... On Oct 6, 2009, at 12:08 AM, biziap biziap wrote:
I have googled this topic and found and example in (A) http://www.mail-archive.com/twisted-web@twistedmatrix.com/msg01796.html well, another simpler example is (B) http://www.mail-archive.com/twisted-web@twistedmatrix.com/msg01788.html
My questions are: 1. Does the approach in (A) be recommended? To generate resource dynamically seems not efficient and not necessary for simple scenario. Is there other way to bind twisted.cred and twisted.web together? (except the deprecated twisted.web.guard)
There's a few problems with this approach. The biggest is that it requires username/password data to be sent on every authenticated request. Another one is more of a design principle; that you shouldn't have account/permissions code inside resource display code. I violate this principle all the time ;-) The use of dynamic resource instantiation is a common idiom in twisted.web coding, though. it isn't inherently inefficient, as long as your resource objects are fairly sane.
2. The approach in (B) which suggests that request.getSession() along is quite enough to implement an simple authentication feature. Here the "simple scenario" means to guard some resource with username and password. To do it: In a protected resource, just to check for a flag in the session, if failure, then redirect to login page. If succeeded, render the resource. Why shall we bother the portal, credentials, checker,.... ?
true, depending on your needs, this may be all that you need. from your description, though, it sounds like you'd be doing this authentication step in every resource you want to protect, which could become tedious (aka error-prone) in a big project. twisted.cred can seem daunting when you're just trying to protect a trivial web resource or two, but for more advanced uses like more complicated authentication levels, it's worth the time to learn. also, a big part of its real value comes when you need to support a variety of protocols and/or authentication types. -phil
Dear phil
true, depending on your needs, this may be all that you need. from your description, though, it sounds like you'd be doing this authentication step in every resource you want to protect, which could become tedious (aka error-prone) in a big project.
I do have lots of resources to protect. Things I have to do is getSession() and hasattr(session,'authenticated') in very request. Just like the Django, it puts @login_required in very protected resources. Username and password were verified once.
twisted.cred can seem daunting when you're just trying to protect a trivial web resource or two, but for more advanced uses like more complicated authentication levels, it's worth the time to learn. also, a big part of its real value comes when you need to support a variety of protocols and/or authentication types.
Agree, that is the reason I am asking here. I feel unconfortable to drop the twisted.cred and adapt to getSession() only. Originally, I expect to get the avatar from request if user has been authenticated by the twisted.cred framework, for example, request.getAvatar() without any extra works to do, no need to assign the avatar to session in the login phase, just need to implement required components of twisted.cred framework. Or even simply to claim a class variable in the resource (like addSlash, isLeaf) and the twisted.cred framework handles the rest of things. If the avatar has to be stored in the session and retrieve from the session in very protected resource, then to adapt the twisted.cred framework seems to be too luxury for my project which authenticate the request with only one source of backend. Do I miss some good things that the twisted.cred brings? By the way, can some one kindly drop a conceptual design which utilize twisted.cred in a multiple protocol environment? Especially the way to retrieve the avatar back in the descending phases (protected resources). That could be very interesting. Thanks in advance.
participants (3)
-
Alex Clemesha -
biziap biziap -
Phil Christensen