Aha! So _some_ cfcs can access a shared scope... ;-) I actually did shift towards the security service being session aware so long as it's knowledge of session is self contained a while back, when I started having flex front ends. But I've also allowed the controller to have limited knowledge the session and I don't think it's that bad. But it's definitely not as encapsulated as the other approach.
In terms of flex I either do what you describe, or have the remote proxy aware of session or enforce security at the application.onRequestStart phase, depending on the complexity of the app. I knew I didn't totally disagree with you... ;-) On Tue, Apr 29, 2008 at 10:48 AM, Brian Kotek <[EMAIL PROTECTED]> wrote: > See, you agree with me and don't even realize it. ;-) Your second approach > would be the one I would recommend. Yes, something, somewhere has to know > about the session scope or you can't use it. Which is why the SessionFacade > is the common way to solve the problem. You can encapsulate access to the > session scope in a single method (i.e. getCurrentUserID() would be the only > thing that knows about the session scope, and everything else calls that > method), or you can even create a whole component to encapsulate access to > the session scope if you're OK with the tradeoffs in doing so. > > Another issue the choice to enforce security at the Controller level at > all. What happens when you want to open this up to a Flex application? Or to > web service calls? Those things never even see your HTML Controller. As > things go ever more toward SOA, this kind of decision can really cause > problems later. I'd recommend enforcing such security in the Model as much > as possible, either through explicit code or via AOP. > > That said, of course if your controller has to do something like forward > the user to a login page (i.e. it is making a decision specific to the HTML > application), then by all means do so. I'd do something along the lines of: > > <cfif not securityService.isUserLoggedIn()> > <cflocation.../> > </cfif> > > Even in that case, the Controller has no idea *how* the security service > knows whether the user is logged in or not. For all it cares you're writing > it to a text file. ;-) > > > > > On Tue, Apr 29, 2008 at 1:23 PM, Jon Messer <[EMAIL PROTECTED]> > wrote: > > > I'm not sure I agree with you here Brian, I do agree that for most > > purposes persistent scopes shouldn't be accessed by objects, but I think > > session and controller are a little different. > > > > Going with the session.userId example, where would the this be set or > > accessed? > > > > It seems to me that if you are going to use the concept of session then > > either the controller can do something like > > > > if(securityService.isUserLoggedIn(session.userId) ) > > > > or else the securityService itself would have to know about > > session.userId. But either way one of these two things has to know about it > > or else you can't use session at all. > > > > I agree 100% that the shared scopes shouldn't be used as a hidden means > > to pass information to and from objects. And controllers definitely have no > > business needing a dsn, but if they did it should be passed to them on init > > not accessed through application. > > > > I'm just not sure where you see something like session.userId being > > set/used. I think of session as a form of user input cached for convienence. > > And the controller is supposed to mediate user input to/from the model. > > > > I could be persuaded I'm wrong though, if you describe how you would > > handle this situation in a better manner... > > > > > > > > On Tue, Apr 29, 2008 at 9:54 AM, Brian Kotek <[EMAIL PROTECTED]> wrote: > > > > > As the person pushing this in the CF-Talk thread, I have to disagree > > > with Dan on this one. Though I think he may be misunderstanding the > > > question. Dan, to be clear, the issue isn't whether it is OK for a > > > Controller CFC to use values *passed-in* via a method call or constructor, > > > which I agree is fine and is in fact the way it should almost always be > > > done. He's asking whether it is literally OK to directly reference > > > "application.dsn" or something from within a Controller, which I would say > > > no to. > > > > > > I don't see any reason why a Controller CFC should need to access > > > anything in the application or session scopes, or anything external to the > > > component for that matter (meaning anything not passed as arguments to the > > > method or properties of the component). > > > > > > In fact, I'd argue that in most cases, if you think you need to access > > > an application or session variable from inside a Controller, it means you > > > may want to reconsider what the Controller is doing in the first place. > > > Things like "application.dsn" or "session.userID" should probably never be > > > needed by a Controller. These things are used by the Model, and the > > > apparent > > > need for these kinds of values may indicate that your Controller is doing > > > work that should really be happening in the Model anyway. My Controllers > > > are > > > really, really dumb. All they do make requests to the Model to perform > > > processing, and render Views. > > > > > > regards, > > > > > > Brian > > > > > > > > > > > > > > > On Tue, Apr 29, 2008 at 12:03 PM, Charlie Griefer < > > > [EMAIL PROTECTED]> wrote: > > > > > > > > > > > Hey all... > > > > > > > > I've had a lingering question, and a thread over on cf-talk (about > > > > properly encapsulating CFC methods) has really got me thinking about > > > > it. > > > > > > > > Over on that thread, there's a "debate" (to use the term loosely) on > > > > accessing the application scope from within a CFC. Yes, I > > > > understand > > > > that's a "bad thing" and I understand why. But in an MVC > > > > framework... > > > > what about CFCs in your controllers? Those CFCs don't really model > > > > any particular object. They're more of a transport mechanism to > > > > facilitate communication between the model and the view. > > > > > > > > So, I get that CFCs in the model should be encapsulated. But what > > > > about CFCs in the controller? is it "acceptable" (which i realize > > > > is > > > > a subjective term) to access shared scopes like application and > > > > session from controller CFCs? > > > > > > > > -- > > > > Evelyn the dog, having undergone further modification pondered the > > > > significance of short-person behaviour in pedal depressed, > > > > pan-chromatic resonance, and other highly ambient domains. "Arf," > > > > she > > > > said. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "CFCDev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cfcdev?hl=en -~----------~----~----~----~------~----~------~--~---
