>Thanks for the advice. For this particular application security is not
>extremely important. There is no sensitive data - the security is simply
>being used to ensure that only registered members see certain parts of the
>site. I don't think that anyone would go through the trouble of hacking
>into the site, and if they did the client wouldn't particularly care.
Well - if security is not an issue then why bother ;-)
Anyway other answers below:
Having said that, your comments raise a few more questions:
1. Where would I keep this new token so that each page would have
access to
it? Would I store it in a variable (which scope) or would I simply
make
sure that it is always passed on the URL, which would automatically
make it
available to each template?
1. URL
2. If I'm sending this token via the URL, doesn't that make it as
insecure
as CFID and CFTOKEN, couldn't it be used for hijacking as well?
Yes, but if you really want security you'd run over SSL (https) and
then it can't be hijacked...
3. My original idea was to have the user log in once, which would
mean one
db read, and then I wouldn't have to read the database anymore, as
their
login status would be in memory. It sounds like you're suggesting
storing
the login status (and auth levels) in a db, and then reading it for
each
page. Doesn't this introduce unnecessary overhead? Am I wrong to
assume
that db reads should be minimized where possible?
Depends on your setup, with one server you can store it in a memory
structure, but in a cluster you'd need to have it in a db.
4. Since sending my note I've been looking at some other code. The
main
problem I'm having is with locking. I think I've found a couple of
possible
solutions to this problem:
a. create a variable in the request scope to contain the urltoken
and then
use that in each page.
That works but you still need to write the authorisation level back
into persistent memory when you're done.
b. use a client variable instead of a session variable.
That's a db hit for each variable access...
As I'm still quite new to this I'm not sure which, if either,
approach would
be best. I'm sure that many web sites out there restrict access to
members.
I guess I'm just looking for some suggestions on how other people
have done
this in the past, and then I can choose the method that's most
appropriate
for this site. I thought I had a simple solution, but it doesn't
seem to be
as simple as I originally thought.
Any suggestions would be greatly appreciated.
Thanks,
Bob
-----Original Message-----
From: BOROVOY Noam [mailto:[EMAIL PROTECTED]]
Sent: Monday, September 25, 2000 11:35 AM
To: Fusebox
Subject: RE: User Authorization Levels, no Cookies and CFLOCK
Depends on your security needs, but instead of relying on CFID and
CFTOKEN
which are far from secure, upon login assign a user a unique random
token
which you'll keep in a database (or memory - application structure
for
example - if it's a single server)
On each link pass back the token on the URL and use it as a key into
the db
or structure to check:
a. user is logged in (and not timed out)
b. other info - such as authorisation level.
You can also check out this:
http://www.aebco.com/CF/CF_Security.doc
<http://www.aebco.com/CF/CF_Security.doc>
HTH,
Noam
----------
From: Bob Silverberg [SMTP:[EMAIL PROTECTED]]
Sent: Monday, 25 September 2000 16:31
To: Fusebox
Subject: User Authorization Levels, no Cookies and CFLOCK
I apologize for bringing back an old topic, but I have a
specific
question.
I've only been using CF for a few months, so the answer to
this may
be quite
simple/obvious.
I've used the attached logic in an application that only
uses
application
variables and it works perfectly. I'm now working on a new
application that
needs to keep track of a user's authorization level. I'm
doing this
by
using a session variable, session.authLevel. If that
variable
doesn't
exist, I ask the user to log in (fuseaction=showLogin), and
if they
are
successful (fuseaction=attemptLogin) I set the session
variable.
I also need to make sure that the application will work
without
cookies, so
I need to pass CFID and CFTOKEN on each URL. Currently I'm
doing
this with
session.urlToken. This means that I need to read
session.urlToken
on every
page, so I need a read-only lock for that. As mentioned
above, I
need to
set session.authLevel after the user logs in, so I need an
exclusive
lock
for that.
I tried using the logic below to wrap my cfswitch statement
in a
read-only
SESSION lock, but that prevents me from obtaining the
exclusive lock
that I
need to set session.authLevel.
So I'm just wondering what the best way to deal with this
is, other
than
placing a read-only lock in each page. I noticed a few
people
saying that
they never use session variables. How do you deal with user
authorizations
if you're not using them? Do you just use client variables
instead,
or is
there a better trick that I'm totally missing?
If anyone has any comments on how I might do the above
better
(including
managing sessions without cookies), please let me know.
Thanks,
Bob Silverberg
[EMAIL PROTECTED]
-----Original Message-----
From: BOROVOY Noam [mailto:[EMAIL PROTECTED]]
Sent: Monday, August 28, 2000 11:18 AM
To: [EMAIL PROTECTED]
Subject: RE: No more need for cflock!!
Thought we bashed this one out a while back:
The "pointers" or "references" might be stored in thread
safe memory
(like
the request scope) but the memory they point to (or
reference) is
NOT thread
safe.
Here's my current approach to tackle this problem (based on
the
accumulated
tips from the list):
In App_globals
1. set simple globals into the request scope - no locking
issues -
tiny
performance hit on setting all the values for each request
probably
equal or
less than the hit of locking.
2. set structures / arrays into the application scope -
first check
if
already defined and loaded - do a full check using IsDefined
followed by
isArray / IsStruct and a check for minimum size - just in
case there
was a
DB error on the previous load.
Then if not defined Write lock and load the data from the DB
- i.e.
define
the data element, include the needed query and fill it up.
If defined do nothing it's already there for you to use.
3. In Index.cfm wrap the whole file after the include of
app_locals
with a
read lock. (if you reference any application vars in
app_locals you
will
want to lock that as well after the include of app_globals.
The read locks will not hit performance - they will only
affect
performance
on the first hits after a reboot and once the application
variables
time out
and need to be re-loaded - which should hardly happen on a
busy
site.
So Steve - only two locks for the whole application - just
placed in
different locations ;-)
For session vars things get messier as you want to write to
them
deep down
in the application - but I found that a well designed app
can
usually avoid
the need for session variables and if really needed use
client vars
or do
the locking everywhere...
HTH,
Noam
----------
From: Fred T. Sanders [SMTP:[EMAIL PROTECTED]]
Sent: Monday, 28 August 2000 16:30
To: [EMAIL PROTECTED]
Subject: Re: No more need for cflock!!
Yes it does only set a pointer, I've tested that
before and
found it
to be
the case.
However (and I haven't tested this) the request
scope by its
very
definition
in CF
is supposed to be thread safe. Wouldn't this in
effect be
treated by
the
CFAS as read locked
pointer?
Fred
----- Original Message -----
From: "Scott Talsma" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, August 28, 2000 9:42 AM
Subject: RE: No more need for cflock!!
> I too believe that
>
> <cfset request.app = application.requestapp>
>
> only sets a pointer. My question regards when do
we need
to set
read
locks?
>
> When all application data resides in the database,
and we
establish that
> application variables will only take on these
values (and
that no
other
> application variables will exists), then doesn't
there
exist an
implicit
> guarantee that (outside of Steve's code) only
reads from
the
request
> variable (a pointer to the application variables)
will
take place?
Is
there
> any danger when two threads simultanously read
from the
same
memory
address?
>
> -----Original Message-----
> From: Cameron Childress
[mailto:[EMAIL PROTECTED]]
> Sent: Montag, 28. August 2000 15:33
> To: [EMAIL PROTECTED]
> Subject: RE: No more need for cflock!!
>
>
> Steve... We've been using this technique for some
time
now. I
see that
you
> are traveling down same path now, so here are
comments on
what
I've found
by
> doing this so far...
>
> One mistake I made early on was code similar to
this line
from
your code
> below:
>
> <cfset request.app=application.requestapp>
>
> I believe that this actually only creates a
pointer to
your
application
> struct, so when you call something in
'request.app', it's
still
technically
> accessing data in your application scope, and
could still
lead to
memory
> issues without a lock. You can solve the problem
by doing
this
instead:
>
> <cfset request.app=
Duplicate(application.requestapp)>
>
> Also, I am very concerned about the effect of this
method
on a
site which
> stores a large amount of data in the application
scope.
You're
basically
> making CF copy the entire scope on every page
call. This
could
cause
> enormous performance problems on a large, heavy
traffic
site with
alot of
> data kept in memory.
>
> I've done some rudimentary load testing with this
technique, and
haven't
yet
> seen a serious issue with decreased performance,
but as
I've been
adding
> more and more data into the application scope for
a
current
project I've
> become more and more worried that the same test
would
yield
different
> results a second time.
>
> I probably will hold off on the load testing for a
bit
longer till
I get
> finished stuffing everything I need to into the
application scope,
but
does
> anyone else have any comments for or against this?
>
> -Cameron
>
> --------------------
> Cameron Childress
> McRae Communications
> p. 770-460-7277 x.232
> f. 770-460-0963
>
> > -----Original Message-----
> > From: Steve Nelson [mailto:[EMAIL PROTECTED]]
> > Sent: Saturday, August 26, 2000 10:34 AM
> > To: Fusebox
> > Subject: No more need for cflock!!
> >
> >
> > I've just hit upon a technique that would mean
we only
ever need
to use
> > cflock two times in a fusebox home application.
This is
for
application
> > variables, session and server variables would
need to do
the
same too i
> > imagine (personally i never use them)
> >
> > First I want to propose a new filename,
qry_globals.cfm
the
point of the
> > file is to store application wide queries, it
would sit
in the
root
> > directory of your home application. It would
run
queries from
the
> > database upon booting up the server then store
the
variables
into
> > memory. This massively reduces stress on the
database,
generally it's
> > an excellent technique. The problem has been
with
cflock.
people
> > forget to use it and CF WILL blow up on you if
you
forget to use
> > CFLOCK. So I figured out a way to bypass all
the cflock
nonsense and
> > only require two cflocks in your entire
application,
which do
very small
> > tasks.
> >
> > Check this code out. It's wicked cool (Hal let
me know
how I
did on my
> > fusedocs, i'm just starting to get into them,
and love
'em! :)
> >
> > <cfsetting enablecfoutputonly="yes">
> > <!--- qry_globals.cfm --->
> > <!---
> > || I start by doing a check to see if the
variable
> > application.requestapp exists if this
> > || variable exists then I set
request.app=application.requestapp
and I
> > do not rerun any
> > || application wide queries. If this variable
does not
exist I
rerun
> > all the queries
> > || and set application.requestapp=request.app
> > ||
> > || Then anytime I want one of these values I
call it as:
> > request.app.queryname instead
> > || of application.queryname. By doing this I no
longer
need to
use
> > cflock in anywhere
> > || other than this file.
> >
> > || [EMAIL PROTECTED]
> >
> > ||
> > -->
> > <-- request.app - this is a copy of an
application
variable
called
> > application.requestapp
> > ++> application.requestapp - this is where all
application wide
queries
> > sit
> > +++
> > --->
> > <cfset request.maindsn="valuemusiclocal">
> > <cfapplication name="blbl"
> > applicationtimeout="#createtimespan(0,1,0,0)#">
> > <cflock name="#application.applicationname#"
timeout="60"
> > type="readonly">
> > <cfif isdefined("application.requestapp")>
> > <cfset request.app=application.requestapp>
> > <cfset runrequest="no">
> > <cfelse>
> > <cfset runrequest="yes">
> > </cfif>
> > </cflock>
> > <cfif runrequest>
> > <cfset request.app=structnew()>
> > <cfquery name="request.app.getstates"
> > datasource="#request.maindsn#">
> > select * from states
> > where active=1
> > order by state_name
> > </cfquery>
> > <cfset request.app.state_rows=structnew()>
> > <cfloop query="request.app.getstates">
> > <cfset
request.app.state_rows[state_id]=currentrow>
> > </cfloop>
> > <cflock name="#application.applicationname#"
timeout="60"
> > type="exclusive">
> > <cfset application.requestapp=request.app>
> > </cflock>
> > </cfif>
> > <cfsetting enablecfoutputonly="no">
> >
> >
> >
> >
> >
> > <!--- dsp_address.cfm --->
> > <!---
> > || I'm demonstrating the use of a request.app
variable,
note
that
> > || I do not need cflock, and I do not need to
rerun the
getstates query
> >
> > || [EMAIL PROTECTED]
> >
> > ||
> > -->
> > <--
> > ++> request.app.getstates - this is a query with
all the
states
in it
> > +++
> > --->
> > <select name="state_id">
> > <cfoutput query="request.app.getstates">
> > <option value="#state_id#">#state_name#
> > </cfoutput>
> > </select>
> >
> >
> > Now that's a beautiful thing! eh?
> >
> > Steve
> >
------------------------------------------------------------------
> > ------------
> > To Unsubscribe visit
>
http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/fusebox or
> send a message to
[EMAIL PROTECTED] with
'unsubscribe' in
> the body.
>
>
--------------------------------------------------------------------------
--
> --
> To Unsubscribe visit
>
http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/fusebox or
> send a message to
[EMAIL PROTECTED] with
'unsubscribe' in
> the body.
>
>
--------------------------------------------------------------------------
--
> --
> To Unsubscribe visit
>
http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/fusebox or
> send a message to
[EMAIL PROTECTED] with
'unsubscribe' in
> the body.
>
>
--------------------------------------------------------------------------
----
> To Unsubscribe visit
http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/fusebox or
send a message to [EMAIL PROTECTED]
with
'unsubscribe' in
the body.
>
----------------------------------------------------------------------------
--
To Unsubscribe visit
http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/fusebox or
send a message to [EMAIL PROTECTED] with
'unsubscribe' in
the body.
----------------------------------------------------------------------------
--
To Unsubscribe visit
http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/fusebox or
send a message to [EMAIL PROTECTED] with
'unsubscribe' in
the body.
----------------------------------------------------------------------------
--
To Unsubscribe visit
http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/fusebox or
send a message to [EMAIL PROTECTED] with
'unsubscribe' in
the body.
----------------------------------------------------------------------------
--
To Unsubscribe visit
http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/fusebox or
send a message to [EMAIL PROTECTED] with
'unsubscribe' in
the body.
----------------------------------------------------------------------------
--
To Unsubscribe visit
http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/fusebox or
send a message to [EMAIL PROTECTED] with 'unsubscribe' in
the body.
------------------------------------------------------------------------------
To Unsubscribe visit
http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/fusebox or send a
message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
