> on 3/17/03 11:53 AM, Raymond Camden at [EMAIL PROTECTED] wrote:
> > Correct, although I normally recommend using self-posting forms. It 
> > makes updates _much_ easier.
> 
> Self posting forms, like the type that DreamweaverMX makes?

I wouldn't know - I use HomeSite+.

>  
> >> Once the user successfully logs in:
> >> Place a line of code on each page in that "protected" 
> directory that 
> >> will check for the existence of session.logged in, if not present, 
> >> redirect to the index page of the root, which has a link 
> to the login 
> >> popup.
> > 
> > Ack! No. Again, look at my code. Notice how I use cfabort. This is 
> > what you would need to do. It is MUCH better to protect all 
> files in 
> > application.cfm then add a check to each file. It is too easy to 
> > forget a file that way.
> 
> Ahh, so I'd use Application.cfm in the root to SET session 
> variables, and an application.cfm in the lower directory to 
> CHECK for and manage those session variables that are passed 
> from application.cfm from above?

Well... it depends. In general, if you want to protect a set of pages,
you would use application.cfm since it is run before any file in the
folder. So, if you wanted to see if session.name = ray before allowing
any file to run, you would do your check in application.cfm, not the sub
pages.

Does the distinction make sense? You CAN check in every file. However,
if your logic is, "Do X before any file in the folder is run", then it
is better to use Application.cfm.


> >> This being safe because, as long as no other pages in the site are 
> >> checking for the existence of "session.loggedin" they 
> should display 
> >> just fine.
> > 
> > Or just don't do that. Check for getAuthUser()
> 
> In that lower Application.cfm? The one that will manage the 
> sessions and logins for that lower, protected directory?

As soon as the <cflogin> block is run, getAuthUser will return a value
IF you are logged in of course.

> I think I'm starting to "see" it now.
>  
> >> Well, that subdirectory will be further broken down by 
> "roles" (if I 
> >> understand roles correctly) so that a user will only be able to 
> >> access subdirectories if their roles match, and if they 
> don't they'll 
> >> see an error message.
> > 
> > Ah, then I'd use an application.cfm in each subfolder. Make it 
> > cfinclude the parent application.cfm. Then do a simple, 
> > if(isUserInRole("foo")) to protect the folder.
> 
> Is this because, when a page is requested, once it FINDS an 
> application.cfm it stops ALL "looking for an 

Correct.

> application.cfm"? So you place an application.cfm in the 
> lower, individual directories and INCLUDE the Application.cfm 
> from "above"? (in the root of the "protected" directory)?
> 

Correct, becuase my 'core' Application.cfm will contain site-wide logic,
but I have a specific need for this particular subfolder. So, unlike
most Application.cfm files, you won't see a <cfapplication> tag in it.
We aren't defining a new application, just some logic to run for one
particular folder.

Hope this makes sense.

=======================================================================
Raymond Camden, ColdFusion Jedi Master for Mindseye, Inc
Member of Team Macromedia

Email    : [EMAIL PROTECTED]
Blog     : www.camdenfamily.com/morpheus/blog
Yahoo IM : morpheus

"My ally is the Force, and a powerful ally it is." - Yoda 

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4
Subscription: 
http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribe&forumid=4
FAQ: http://www.thenetprofits.co.uk/coldfusion/faq
This list and all House of Fusion resources hosted by CFHosting.com. The place for 
dependable ColdFusion Hosting.

                                Unsubscribe: 
http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
                                

Reply via email to