Can someone provide a real world example of what it would take to
have a race condition? And is this possible with very low traffic if
a user loads a shopping cart (for example) in two browser tabs and
somehow, by sheer act of the universe, manages to submit both in the
same millisecond?
From Adobe:
If two requests to the page that includes this code are made at the
same time, it is possible that in the time between the right-hand
side read of the session.cartTotal, and the left-hand-side write for
the second page request to execute and modify session.cartTotal. The
result is corrupt data. Developers should always ensure that they
mitigate or prevent corrupt data when writing application code. Using
the cflock tag in this case will prevent the race condition:
_____________
Derrick Peavy
Sales and Web Services
CollegeClassifieds.com
http://www.collegeclassifieds.com
A Service of Universal Advertising, inc.
___________________________________
On May 10, 2007, at 3:00 PM, Douglas Knudsen wrote:
On 5/10/07, Dusty Hale <[EMAIL PROTECTED]> wrote:
I was always under the impression that it was better to use client
variable with the storage mechanism set to a database server with
the thought being too much overhead session variables due to having
to <clock> the session variables.
RAM access has to be faster than a trip to DB land I'd think. In
the past maybe, but unless you are expecting a race condition, no
need to lock them anymore.
Dean the 3X3 approach seems good. I'm a little confused how to
check on "the object" level but I think I understand were to go on
the "user" and "requested action". Thanks for your thoughts.
From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] On Behalf Of Dean
H. Saxe
Sent: Wednesday, May 09, 2007 5:07 PM
To: discussion@acfug.org
Subject: Re: [ACFUG Discuss] preferred method for coding logins
Whoa, I could talk for days on this alone.
A few thoughts:
Authentication must take place on the server. All authorization
information must also remain on the server, therefore it is always
held in the SESSION scope. While I have immense respect for Hal, I
find that method to be a PITA. Besides, it only addresses
authorization to a specific function and not data. For good, strong
authorization you must check 3 things, 3 times (3X3):
Check:
The User
The object
The requested action
The user should have permission to take the action upon the object.
You do this in three places:
1) Before allowing the user to see the option to perform <action>
on <object> in the UI
2) When the user requests to perform <action> (e.g. view) the
object (e.g. view acctID 1000)
3) When the user attempts to modify the object (e.g. delete acctID
1000).
So, you have 2 levels of AuthZ: The first is large grained, does
the user have permission to a URL or a set of functionality. This
prevents privilege escalation vertically, e.g. a user becomes an
admin. The second is fine grained, does the user have permission to
a specific piece of information. This prevents horizontal privilege
escalation, e.g. can user Dean see user Dusty's personal data. This
is where most developers screw up and forget to check for permissions.
AuthZ systems are easy to implement... incorrectly. Make sure yours
is designed well up front to prevent problems down the road. And
make sure it is USED in the code each and every time permission to
perform some action on some object is requested.
FWIW, this is an authorization (authZ) issue and not one specific
to authentication (authN). If you want thoughts on authN, just ask.
-dhs
Dean H. Saxe, CISSP, CEH
[EMAIL PROTECTED]
"If liberty means anything at all, it means the right to tell
people what they do not want to hear."
-- George Orwell, 1945
On May 9, 2007, at 5:00 PM, Dusty Hale wrote:
As a part of the app I'm working on I have to code a permission
based login system. I've written a lot of this kind of code in the
past to pull from but I thought it would be interesting to ask if
anyone has thought on current preferred ways to code logins.
My thoughts are:
What is the current preferred method of holding login information
(variable scopes)? Client, Session, or Cookie scope.?
In the past I've always used numeric values to assign specific
permissions and the BitAnd() function to determine if a user has
access to a specific permission. This was an approach that I
learned from Hal Helms years ago. I wonder if there are newer more
preferred ways of coding logins before I dive into this one or if
I should stick to what I already know. I welcome any thoughts or
opinions on the subject.
Dusty
-------------------------------------------------------------
To unsubscribe from this list, manage your profile @
http://www.acfug.org?fa=login.edituserform
For more info, see http://www.acfug.org/mailinglists
Archive @ http://www.mail-archive.com/discussion%40acfug.org/
List hosted by FusionLink
-------------------------------------------------------------
-------------------------------------------------------------
To unsubscribe from this list, manage your profile @
http://www.acfug.org?fa=login.edituserform
For more info, see http://www.acfug.org/mailinglists
Archive @ http://www.mail-archive.com/discussion%40acfug.org/
List hosted by FusionLink
-------------------------------------------------------------
--
Douglas Knudsen
http://www.cubicleman.com
this is my signature, like it?
-------------------------------------------------------------
To unsubscribe from this list, manage your profile @
http://www.acfug.org?fa=login.edituserform
For more info, see http://www.acfug.org/mailinglists
Archive @ http://www.mail-archive.com/discussion%40acfug.org/
List hosted by FusionLink
-------------------------------------------------------------
