Are you saying you want external users to provide a uname/pword while internal calls don't need it? Just add a method for external folks. Imagine the internal method is getFoo(). Set the access to public, not remove. Add a new method, remoteGetFoo(), this method had access=remote and requires a uname/pword. Once you authenticate, you then call getFoo() and return the result. SO, remoteGetFoo() is like a proxy for getFoo(). I believe Corfield has an article that describes this (although, again I believe, they use a "facade CFC", a whole CFC, that gives remote access to an internal CFC).
Anyway, you get the idea. ======================================================================== === Raymond Camden, ColdFusion Jedi Master for Mindseye, Inc (www.mindseye.com) Member of Team Macromedia (http://www.macromedia.com/go/teammacromedia) Email : [EMAIL PROTECTED] Blog : www.camdenfamily.com/morpheus/blog Yahoo IM : morpheus "My ally is the Force, and a powerful ally it is." - Yoda > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of D. Delcomminette > Sent: Wednesday, June 04, 2003 8:36 PM > To: [EMAIL PROTECTED] > Subject: RE: [CFCDev] Web Services > > > Hi, > > Exactly what I meant, external users should provide a > username and password, but I don't like so much the idea of > hardcoding a user name and password in my internal app. > > Dominique > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Rod Buchan > Sent: 05 June, 2003 04:46 > To: [EMAIL PROTECTED] > Subject: RE: [CFCDev] Web Services > > Just wondering why you would need to know this. Isn't the > reason we use cfc's so that we can write modular code that is > independent of the calling code? > > The only way that I can think of is to pass an extra > parameter that only your internal app knows. > > EG: > > <cfargument name="internalPassword" type="string" > required="no" default=""> > > Then this will be "" for the web service calls and some other > value for internal calls (perhaps your internal app has it as > an application variable). > > This may not be the best method - there may be some "proper" method. > > > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Behalf Of D. Delcomminette > Sent: Wednesday, 4 June 2003 23:50 > To: [EMAIL PROTECTED] > Subject: RE: [CFCDev] Web Services > > > Ooooooops message mismatch ... > > Must read: > > Must be simple, but can't find the best way to know inside my > CFC if it was called "internally" by my application or > invoked as a Web Service by another application > > > Dominique > > ---------------------------------------------------------- > You are subscribed to cfcdev. To unsubscribe, send an email > to [EMAIL PROTECTED] with the word 'unsubscribe cfcdev' > in the message of the email. > > CFCDev is run by CFCZone (www.cfczone.org) and supported > by Mindtool, Corporation (www.mindtool.com). > > ---------------------------------------------------------- > You are subscribed to cfcdev. To unsubscribe, send an email > to [EMAIL PROTECTED] with the word 'unsubscribe cfcdev' > in the message of the email. > > CFCDev is run by CFCZone (www.cfczone.org) and supported > by Mindtool, Corporation (www.mindtool.com). > > ---------------------------------------------------------- > You are subscribed to cfcdev. To unsubscribe, send an email > to [EMAIL PROTECTED] with the word 'unsubscribe cfcdev' > in the message of the email. > > CFCDev is run by CFCZone (www.cfczone.org) and supported > by Mindtool, Corporation (www.mindtool.com). > ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [EMAIL PROTECTED] with the word 'unsubscribe cfcdev' in the message of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com).
