also you flood the cookies with a bunch of obfuscated names as decoys
and when the boss walks around and sees the cookie properties screen
open, because the user is so entranced in trying to figure it out, the
boss could question that.
Wait a sec...
How many bosses even know what a browser cookie is, ;-)
Ben
On Feb 6, 2008, at 12:52 PM, Robert Shubert wrote:
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
________________________________________________________________________
TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf
