- 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).
Nuts - hadn't thought of that.
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. :-(
OK... So how about the LoginMethod has the key as a property, defined when it's created (heck, even chosen at random and never visible to any user). Then the raw data from the SessionDataManager is useless, 'cos only the LoginMethod knows the key, but the LoginMethod can decode it and decide if they're logged in or not - right? Or am I missing something - is this still insecure?
Safe authentication is a hard problem. The sessioning machinery might help in some way, but it's not an answer in and of itself.
*nods* - I think I'd still like to use it, because it's a nice way to organise things. Putting any meaningful data on the client side gives me heebie-jeebies. Of course, I'm assuming that CST includes checks to guard against cookie-hijacking. :-) -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.