Hi Roland, > this is lower level than I can comprehend. Memory spaces and all.
Generally speaking, all Witango variables (with the exception of Cookie Scope Variables) live as bits of data at a particular address in your Server's RAM memory. > If someone comes in and joins a session, I want to bounce him out. > Maybe not kill the session, because it might belong to a real person. > By checking my local session cookie, I can tell if the person > logged on > properly or just came running into a page or function without passing > 'go'. > > If I see someone hasn't logged on, I can trap him into a > logon sequence > easily, BUT, he's still joined the session he barged in on. I can't > push him out of it. Maybe the Variables are within reach - but you can still write code to prevent them doing anything with them. Technically speaking, no User becomes part of a session (and its collection of Variables), but are "granted" access to read or change the Variables. This is true for valid and non-valid Users. The rules surrounding access and assignment of Variables, such as who and under what circumstances exactly, is how "Scoping" came to being. "IF" you have trapped that they shouldn't have access, then push them to a different part of your code (or another page) that does not do anything with User Scope variables. > If I can't push the interloper out of a session, > then I want to kill the whole session. This is your best strategy. Better to error on the side of caution. I also do this under unusual circumstances. > When the subject matter is > money, identity, or personal information, privacy & security are > paramount. I'm just trying to eliminate open doors. > > (I'd think this would be of general concern - how to bullet > proof your > sessions) The "web" will never be 100% secure. But in my opinion, eliminating the use of <@USERREFERENCEARGUMENT> is the right step in the right direction. Especially now, with the changes made to Witango 062 about UserReference precedence - the use of <@USERREFERENCEARGUMENT> should be your "second" choice for managing User security. As an exercise for your client, go and checkout what their on-line banking service is using for managing "secure" logon sessions (aside from SSL), I bet you'll find session-cookies (or one of it's other names) as a requirement. Hope this helps. Good luck..... ________________________________________________________________________ TO UNSUBSCRIBE: Go to http://www.witango.com/maillist.taf
