I will get this eventually. In the meantime, I really do appreciate the help.

OK, so I have an articles.cfc. One of its job is to serve up an article (recordset) when requested.

Each article may or may not be available to the public and may have some sort of access requirement.

I see two ways of doing this:

Strategy 1:

Tell articles.cfc what article is being requested and who is requesting it. In response, articles.cfc will check what permissions are needed to view the article and ask Security.cfc if the requesting user has the correct permissions to view the article. It will then return a recordset with either the article or some stuff that says (basically). "Sorry, you don't have the rights.".

This means that articles.cfc has to talk to Security.cfc (either calling it through Application scope or instantiating it anew) and is less independent and therefore less modular.

Strategy 2:

Tell articles.cfc what article is being requested and the permissions of the person (or server) that is requesting it. In response, articles.cfc just has to check if those permissions are appropriate for the given article and then return the article or a "no can do" message.

This means that articles.cfc is more independent and more modular, but that I have to store permissions information in my Session scope and that I would have to store it in Application-scope session tracking for web services as well.

I would think that would mean that a web service couldn't call this method directly because a web service couldn't pass permissions into the method (or else the calling server could just send any permissions that it wanted to).


It seems to me that strategy 1 is better, but this seems to be "coupling" and therefore wrong. What am I missing? A strategy 3 perhaps?


Thanks and sorry for the barrage of questions to the list. =)

Steve

----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email
to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' in the message of the email.


CFCDev is run by CFCZone (www.cfczone.org) and supported
by Mindtool, Corporation (www.mindtool.com).

An archive of the CFCDev list is available at www.mail-archive.com/[EMAIL PROTECTED]

Reply via email to