The wonders of the daily digest means that I get to quote more than one message at a time... ;-) Mike Orr <[EMAIL PROTECTED]> wrote: > >You don't have to create a session. You just ask for it, and it creates and >maintains itself. There's a small example of using and setting session >variables in Introduction to Webware >http://webware.sourceforge.net/Papers/IntroToWebware.html >Scroll down to "The session object". Thanks for the reference! It's rather like the Java API in nature, then, at least in this area. >Advantages: > easy to use, calling mechanism consistent with form fields. Indeed. >Disadvantages (missing features): > automatic session recovery after expire (currently it presents an >error page and then starts without a session; I'd propose starting a new >session without an error message), Yes, as was noted later, this can be fixed. > operation without cookies (hooks are provided, but it's "do it >yourself"), > automatic switching between cookie and cookieless operation Actually, thinking about it, I would almost expect it to be hook-in functionality. Whilst there probably do exist ways of suggesting (or "renaming") the URL that a client has just accessed, overriding the URL supplied by the client whilst not redirecting the client, it has never been desirable functionality on my part. >> Part of the reason I ask such questions is that in the XMLForms package, the >> framework attempts to push all active data in an application back to the >> client, and this would naturally include any session identifier. > >How can the session identifier be stored on the server? The only >implementations are either in a cookie, a hidden form field, or a GET >variable. I should have been clearer here. Obviously the client needs to present a session identifier to the server on each request in order to tell the application who they are and which data belongs to them. My point was that, whilst some/many/most frameworks "persist" the bulk of the data on the server, XMLForms even sends data not being manipulated by the current screen/form to the client. Such data is transparently stashed in the form being manipulated by the client at the point of time in question. (This is a fairly old trick, but one which I thought frameworks should deal with on behalf of applications.) With the above approach, there isn't necessarily any need for a session identifier in the guise of Webware's sessions because the state in the client's interactions is held in the exchanges between client and server. However, at some point, one might want to authenticate a user in order to store data on the server, perform some transactions on the user's behalf, and so on. At this point, one requires a session identifier which indicates or confirms the user's identity, as opposed to one which merely indicates that one user is different from another. Moreover, depending on the "security implementation" used, such an identifier would need to be moderately secure, such that someone couldn't use another's identifier to gain access to their resources. It seems that this is not just a case of using a well-known user identifier as a session key, at least not on its own. But one wouldn't necessarily want to keep sending a password to authenticate a user upon every interaction with the server, unless basic authentication were supported over SSL. Certainly, sending a password as a GET parameter lends itself to the advanced "looking over the shoulder" trick. ;-) What I'm suggesting is that something could generate a session key of some kind (perhaps a random/pseudo-random number) which can be used in conjunction with user identifiers in order to authenticate people. I wonder whether the UserKit could manage this kind of thing - provide moderately "unspoofable" session support - or would much of this be managed by an application? Or am I rambling too much? ;-) >> I see one advantage of this system being the avoidance of any need to store >> session information on the server, and to be obliged to implement session >> timeouts - I hate visiting Web sites where my session expires after five >> minutes just because I had to respond to an e-mail. > >You don't even want to store the session variables on the server? Then >you don't have a session, or at least not as it's normally defined. >You'd either have to store everything in cookies, which means shutting out >those who browse without cookies, or you'd have to carry the variables >across every page as form fields or GET parameters, which is ugly to >implement (and in the case of GET fields, is ugly to the user and prone to >the user erasing part of the URL, or to bookmarking the page with "session" >variables included). Part of the challenge with XMLForms is to maintain state information in the forms themselves, even with multiple screen transactions. The biggest danger is probably providing links on pages which don't contain session information, however. >Anyway, my previous suggestion was (quoting): > >** Automatically switch the session ID between cookie and GET >whenever cookies are turned on or off. [I think this can be done by >overriding Session.SessionEncode(self, url) to return the URL unchanged >if the cookie '__SID__' is present, then calling the method for all URLs.] Wasn't there an issue with Webware only reading GET or POST parameters, but not both, at some point in the past? Wasn't this fixed? If not, wouldn't this cause problems? [...] >I have an existing site I'd like to port to Webware someday, but it would >definitely need these features. Indeed. Mike Orr <[EMAIL PROTECTED]> then wrote: > >On Thu, Jun 21, 2001 at 02:51:19PM -0000, [EMAIL PROTECTED] wrote: >> I see one advantage of this system being the avoidance of any need to store >> session information on the server, and to be obliged to implement session >> timeouts - I hate visiting Web sites where my session expires after five >> minutes just because I had to respond to an e-mail. > >Then set the timeout to half an hour, three hours or ten hours. Can I control cookies sent to me in this way? I never looked at cookie management seriously in browsers, but then isn't the session "garbage collection" that one often experiences something that the application itself is imposing on the server side, and that it is most likely discarding my session's state (or data) at such frequent intervals? Regards, Paul -- Get your firstname@lastname email for FREE at http://Nameplanet.com/?su _______________________________________________ Webware-discuss mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/webware-discuss
