> His number is 9 billion, because he thinks to highly of himself :-)

Hey, I think I used to work for that guy :-P

Thanks.

Scott,









> Good point, a good level of obfuscation in the storing of the data is
> needed
> 
> 
> Ben
> 
> On Feb 6, 2008, at 12:28 PM, Scott Cadillac wrote:
> 
>> 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

Reply via email to