No, do it on the actual template that is processing the code.  Because like you said, what if someone knows the URL to the page?  Then must protect the code on that page as well.  THat way if anyone accesses that page directly, but doesnt have the right credentials, they will not be allowed to do anything
  ----- Original Message -----
  From: Marco Antonio C. Santos
  To: CF-Talk
  Sent: Wednesday, July 07, 2004 3:49 PM
  Subject: Re: Restricting Access

  Inside SQL clauses? Or maybe using cfinclude files.... for example...

  <CFIF Session.UsersRole IS 'DELETE'>
  <cfinclude template="delusers.cfm">
  <CFELSE>
  Sorry.... Monkey user.... you don't have permission to enter....
  </CFIF>

  Right? More suggestions?

  On Wed, 7 Jul 2004 15:35:49 -0500, brobborb <[EMAIL PROTECTED]> wrote:
  > You must protect that code at the root level, so in users.cfm, only allow the delete if the user role is DELETE
  >  ----- Original Message -----
  >  From: Marco Antonio C. Santos
  >  To: CF-Talk
  >  Sent: Wednesday, July 07, 2004 3:36 PM
  >  Subject: Re: Restricting Access
  >
  >  Thank you Matt. I'll be visiting your web site and getting MongerLite.
  >  but.... say...
  >
  >  - CEO haves the God rights role(insert, change, delete, view, all)
  >  - Monkey haves only view users option.
  >
  >  users.cfm menu page:
  >
  >  <CFIF Session.UsersRole IS 'DELETE'>
  >  Congratulations.... CEO... you can now del all users...
  >  <a href="" Gate$</a>
  >  </CFIF>
  >
  >  Hmmmm.... good code yeahhh...
  >
  >  If Monkey Smart user knows that URL and then write in URL bar...
  >
  >  what's happened??? How to protect our application from this "smart" users?
  >
  >  Thanx
  >
  >  On Wed, 7 Jul 2004 12:48:55 -0700, Matt Robertson
  >  <[EMAIL PROTECTED]> wrote:
  >  > Dave,
  >  >
  >  > Yes you are exactly right.  I snipped this out of something else and
  >  > fiddled with it.  It was originally looking for a "no"
  >  >
  >  > Marco,
  >  >
  >  > You can look at cf_AccessMonger Lite, free and linked at my site.  Its
  >  > got a live example of page protection and individual code block
  >  > protection in its index.cfm, I think.  The code is different and
  >  > simpler in that kind of old tag, but the principles are identical.
  >  >
  >  > I just began work, finally, on AMPro which I think I first announced
  >  > like a year ago.  Will use hint/answer auth, have groups and roles
  >  > which you can bundle into customizable default profiles, and keep the
  >  > same look/feel that AMLite has but with css and not FONT tags...
  >  > blech) etc. etc.  I basically have to pull the security system out of
  >  > my cms and make it standalone.  Lots of surgery.
  >  >
  >  > Cheers,
  >  >
  >  > --
  >  > --Matt Robertson--
  >  > MSB Designs, Inc.
  >  > mysecretbase.com
  >  >
  >  >
  >
  >
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings] [Donations and Support]

Reply via email to