• Global community
    • Language:
      • Deutsch
      • English
      • Español
      • Français
      • Português
  • 日本語コミュニティ
    Dedicated community for Japanese speakers
  • 한국 커뮤니티
    Dedicated community for Korean speakers
Exit
0

OOP - The scale of method functionality.

Enthusiast ,
Oct 14, 2013 Oct 14, 2013

Copy link to clipboard

Copied

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?

Views

517

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Engaged ,
Oct 15, 2013 Oct 15, 2013

Copy link to clipboard

Copied

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-Decouplin...

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. 

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Enthusiast ,
Oct 15, 2013 Oct 15, 2013

Copy link to clipboard

Copied

LATEST

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.

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Resources
Documentation