CoreSessionTracking-based LoginMethod for LoginManager
Hi there Zopers, I'm currently trying to develop a LoginMethod for LoginManager which uses CoreSessionTracking to store/access credentials, rather than Basic HTTP Authorization or Basic Cookie Authorization. Here's why: - Basic HTTP auth is unacceptable because we need form-based login. - I've looked at other user folders which support cookies, and at CookieCrumbler, and at the BasicCookieLogin class bundled with LoginManager, but they all share the problem (in my mind) that they store the username/password encoded in the cookie itself, which isn't very secure - and doesn't extend well into storing other information if I wanted to. - I'd much rather use a token-based scheme where all sensitive information is stored on the server, and the cookie is just a token which can be mapped to that data. This seems to me to be what CoreSessionTracking offers. - The CST documentation mainly talk about CST as a way of tracking anonymous sessions, but I see no reason why it couldn't be used in this way too...? If we assume that the above reasoning is sound and that this is A Good Thing To Do, then I have the following problems: - I haven't written a fully-fledged disk-based product yet. I've looked at the tutorials and howtos but they're pretty basic. Helpful, but basic. I've successfully created a stripped-down do-nothing copy of the BasicCookieLogin class, but it's adding the extra (CST-related) parts that I'm having difficulty with. - If I could do it with a ZClass I reckon I could make it work, but I can't see a way to create a ZClass which LoginManager can use as a LoginMethod. There are subclasses for UserSources, but not LoginMethods. - Ideally I want it to be self-contained, so the LoginMethod instance would contain a SessionIdManager and a SessionDataManager - but I don't know how to do this properly/ morally/legally, or if it's even possible. - Another approach would be to have the LoginMethod pick up a SessionDataManager outside of it, but I'm having problems with this too... I tried hard-coding an expected ID in the LoginMethod and created a SessionDataManager with that ID in the LoginManager, but the acquisition didn't work. Maybe I'm missing something simple? Basically I have too many gaps in my knowledge to pull this together properly on my own, so it's time to ask for help. I'll be happy to expand on any of the above if necessary... I've sure learnt a lot about LoginManager and CST over the last few days, but I don't quite the skills to suit action to intent... :-( I'm assuming that this would be useful to other people if I could get it to fly? If that's the case, I'd love to release it. Similarly, if anyone wants to see the source of what I've tried so far, let me know. Other than that, all input appreciated. Thanks in advance, Andy -- Andy Gimblett - Programmer - Frontier Internet Services Limited Tel: 029 20 820 044 Fax: 029 20 820 035 http://www.frontier.net.uk/ Statements made are at all times subject to Frontier's Terms and Conditions of Business, which are available upon request.
Could you guys please take me off the Zope mailing list. thanks --Mate' -----Original Message----- From: zope-admin@zope.org [mailto:zope-admin@zope.org]On Behalf Of Andy Gimblett Sent: Wednesday, August 15, 2001 8:26 AM To: 'zope@zope.org' Subject: [Zope] CoreSessionTracking-based LoginMethod for LoginManager Hi there Zopers, I'm currently trying to develop a LoginMethod for LoginManager which uses CoreSessionTracking to store/access credentials, rather than Basic HTTP Authorization or Basic Cookie Authorization. Here's why: - Basic HTTP auth is unacceptable because we need form-based login. - I've looked at other user folders which support cookies, and at CookieCrumbler, and at the BasicCookieLogin class bundled with LoginManager, but they all share the problem (in my mind) that they store the username/password encoded in the cookie itself, which isn't very secure - and doesn't extend well into storing other information if I wanted to. - I'd much rather use a token-based scheme where all sensitive information is stored on the server, and the cookie is just a token which can be mapped to that data. This seems to me to be what CoreSessionTracking offers. - The CST documentation mainly talk about CST as a way of tracking anonymous sessions, but I see no reason why it couldn't be used in this way too...? If we assume that the above reasoning is sound and that this is A Good Thing To Do, then I have the following problems: - I haven't written a fully-fledged disk-based product yet. I've looked at the tutorials and howtos but they're pretty basic. Helpful, but basic. I've successfully created a stripped-down do-nothing copy of the BasicCookieLogin class, but it's adding the extra (CST-related) parts that I'm having difficulty with. - If I could do it with a ZClass I reckon I could make it work, but I can't see a way to create a ZClass which LoginManager can use as a LoginMethod. There are subclasses for UserSources, but not LoginMethods. - Ideally I want it to be self-contained, so the LoginMethod instance would contain a SessionIdManager and a SessionDataManager - but I don't know how to do this properly/ morally/legally, or if it's even possible. - Another approach would be to have the LoginMethod pick up a SessionDataManager outside of it, but I'm having problems with this too... I tried hard-coding an expected ID in the LoginMethod and created a SessionDataManager with that ID in the LoginManager, but the acquisition didn't work. Maybe I'm missing something simple? Basically I have too many gaps in my knowledge to pull this together properly on my own, so it's time to ask for help. I'll be happy to expand on any of the above if necessary... I've sure learnt a lot about LoginManager and CST over the last few days, but I don't quite the skills to suit action to intent... :-( I'm assuming that this would be useful to other people if I could get it to fly? If that's the case, I'd love to release it. Similarly, if anyone wants to see the source of what I've tried so far, let me know. Other than that, all input appreciated. Thanks in advance, Andy -- Andy Gimblett - Programmer - Frontier Internet Services Limited Tel: 029 20 820 044 Fax: 029 20 820 035 http://www.frontier.net.uk/ Statements made are at all times subject to Frontier's Terms and Conditions of Business, which are available upon request. _______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
On Wed, 15 Aug 2001, Andy Gimblett wrote:
I'm assuming that this would be useful to other people if I could get it to fly? If that's the case, I'd love to release it.
Sure. Release early, release often! Oleg. ---- Oleg Broytmann http://www.zope.org/Members/phd/ phd@phd.pp.ru Programmers don't die, they just GOSUB without RETURN.
Andy Gimblett wrote:
Hi there Zopers,
Hi!
I'm currently trying to develop a LoginMethod for LoginManager which uses CoreSessionTracking to store/access credentials, rather than Basic HTTP Authorization or Basic Cookie Authorization. Here's why:
- Basic HTTP auth is unacceptable because we need form-based login.
- I've looked at other user folders which support cookies, and at CookieCrumbler, and at the BasicCookieLogin class bundled with LoginManager, but they all share the problem (in my mind) that they store the username/password encoded in the cookie itself, which isn't very secure - and doesn't extend well into storing other information if I wanted to.
- I'd much rather use a token-based scheme where all sensitive information is stored on the server, and the cookie is just a token which can be mapped to that data. This seems to me to be what CoreSessionTracking offers.
Yes..
- The CST documentation mainly talk about CST as a way of tracking anonymous sessions, but I see no reason why it couldn't be used in this way too...?
Well... one reason is that there is no failsafe access control on session data objects (the token key is the only thing required to grab hold of a session data object and all of its contents via DTML). As a result, the data that is stored in a session data object would itself need to be encrypted in some way for it to be "secured". Encrypting it assumes some sort of shared key, so you're back to the original problem with a layer of indirection. :-( Safe authentication is a hard problem. The sessioning machinery might help in some way, but it's not an answer in and of itself. -- Chris McDonough Zope Corporation http://www.zope.org http://www.zope.com """ Killing hundreds of birds with thousands of stones """
participants (4)
-
Andy Gimblett -
Chris McDonough -
Mate' Sztipanovits -
Oleg Broytmann