But really cookies are the most convenient way to go from a Witango page to a HTML page and back to a Witango page and maintain the session. Heck the USR is going to do that automatically as long as the domain hasn't changed and/or the scope hasn't timed out. You can also use cookies to step between programming languages.
And don't leave out that the value of a cookie can be easily encrypted with tripledes or blowfish so storing and retrieve a relatively sensitive piece of data can still be done safely. Combine that with a method of timing them out along with the user's session and it should be pretty secure. Just thinking out-loud a little. Robert -----Original Message----- From: Scott Cadillac [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 06, 2008 3:29 PM To: [email protected] Subject: Re: Witango-Talk: Passing login to JavaScript Hi Ben, > I agree with Robert here, this is what cookies where designed for True, to a point. Keep in mind cookies where introduced before server-side user/session scope variables where commonly available for web apps. Once user/session scope variables did come along they became the preferred alternative for some very good reasons. Namely security of sensitive information like a user's ID. If the user's ID is available as a cookie (or a URL argument for that matter), and not verified upon posting to a database for example, the user has an opportunity to hijack somebody else's identity. This could potentially permit a malicious user to bypass authentication limits on what they are allowed and not allowed to do, e.g., change or delete records. Chaos could ensue. An ambiguous session identifier, that only exists for a unique browser instance, is more protection than exposing something sensitive like a real database identifier. Especially given the tools users have at their disposal these days with Firefox extensions and the like that allow anybody to alter their cookie values prior to posting. If a company has say 20 employees, and you know your ID is say 14, how long will it take to guess your boss' ID? Then again, if you're just using that information for something innocent like displaying alternative menus then you're probably fine. But still, it's something to be mindful of. Scott, > > Ben > > On Feb 6, 2008, at 7:06 AM, Robert Shubert wrote: > >> A cookie might work. >> >> From: Dan Stein [mailto:[EMAIL PROTECTED] >> Sent: Wednesday, February 06, 2008 9:58 AM >> To: [email protected] >> Subject: Witango-Talk: Passing login to JavaScript >> >> I have a site where 90% of the pages can be served with just plain >> HTML or HTML and some XML and JavaScript. >> >> We use a Filemaker database for the members info and that is how >> they log in. >> >> If they are logged in we show them a different menu because they get >> different information. >> >> I prefer not to keep loading and caching pages with The witango >> server that only need this small bit of information which we could >> easily make the users email address and ID number. >> >> Is there a way to store this information using JS or some other >> technique after having witango log them in. >> >> So somehow I want to pass the user scope variables from witango and >> have them available. >> >> Dan >> -- >> Dan Stein >> FileMaker 7 Certified Developer >> Digital Software Solutions >> 799 Evergreen Circle >> Telford PA 18969 >> Land: 215-799-0192 >> Cell: 610-256-2843 >> Fax 215-799-0192 ( Call 1st) >> FMP, WiTango, EDI,SQL 2000, MySQL, CWP >> [EMAIL PROTECTED] >> www.dss-db.com >> >> "I destroy my enemies when I make them my friends." >> >> Abraham Lincoln >> >> ________________________________________________________________________ >> TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf >> ________________________________________________________________________ >> TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf > > > ________________________________________________________________________ > TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf ________________________________________________________________________ TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf ________________________________________________________________________ TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf
