Skip to main content
A
Aegis_Kleais
Inspiring
October 14, 2013
Question

OOP - The scale of method functionality.

  • October 14, 2013
  • 1 reply
  • 649 views

Imagine I have 2 objects.  A 'user' object, responsible for handling user functionality, and a 'security' object, responsible for handling authorization and authentication.

I would like to hear pros and cons to my current belief of the following.

I have a method in the security object called 'canAccess'.  You can pass it 2 optional arguments, a userID and a pageID.  If no userID is passed, it infers the current user object's ID (which is tied to the session scope), and if no pageID is provided, it infers the current request object's page ID (which is tied to the request scope)

At first, I thought this might be a security risk, because code could pass a userID that did not belong to them, even though all this method does is determine if the user provided has Access rights to the page provided.

I've been thinking about this for quite some time, and my current belief is that this is OK as LONG as the method is not set for remote access (and it is not).  My application supports installable 'modules' which others can code, plugs into my framework, and the pages in those modules could invoke this method and pass whatever user/page ID combo they want to it, but ultimately, it's up to the responsibility of the person who has the core application/framework to approve/inspect any modules they install.

Does this sound as if I am properly assessing the scalability of my object methods?  Any concerns you can bring to light I haven't hit on?

    This topic has been closed for replies.

    1 reply

    D
    duncancumming
    Participating Frequently
    October 15, 2013

    Firstly, you say your canAccess method has 2 optional arguments for the userID and pageID.  This doesn't really make sense, those arguments should both be mandatory, as the function won't work without them, right?  I'm guessing you're doing something like:

    <cfargument name="userID" required="false" default="#session.userID#">

    <cfargument name="pageID" required="false" default="#request.pageID#">

    If so, this isn't good OOP because you want to decouple your CFC from referencing any shared scopes.  This is a good article about the basic principles involved:

    http://www.bryantwebconsulting.com/blog/index.cfm/2009/7/9/OO-Principles-Encapsulation-and-Decoupling

    Instead your code should be make those arguments required without defaults.

    Secondly, I don't see any problem with the basic idea of defaulting to the session ID or the page ID, however I'd move that logic out of your CFC (if that is how you're doing it), and into however you call that function. 

    A
    Aegis_KleaisAuthor
    Inspiring
    October 15, 2013

    Thanks Duncan!

    An interesting concept of OOP; I had never heard of decoupling, but after hearing your explanation, that makes sense.  Rather than the "benefit" of being able to optionally provide an argument, and have it default to something, it should instead, always rely on data that is passed into it.  Excellent point!

    Thanks for the article link!

    This OOP stuff is a really great methodology.

    Terms & ConditionsAccessibility statement
    Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices