> First off, never hard code any variable values inside my applications
> anymore. This, for me is a security issue. If someone, somehow manages
to
> hack into your system, and gets a hold of your files, bye bye database.
All
> my environment variables get pulled from a database now, and populate the
> variables they need to. I am now more utilizing the APPLICATION scope
with
> my apps, but not calling them directly. I duplicatte them into the
request
> scope and access them that way.
You have me confused as to how firstly, your application can talk to the
overall database and secondly how it logs into the database? At some point
you have to hardcode some logic / queries into your application (whether it
be by application or request scope)
If someone where to penatrate your applications directory, losing your
database would be the least of your worries, i'd be more concerned with
loosing the entire server aswell as the database.
> The way I see it, if your going to start to have your CFCs being accessed
as
> web services, then you are going to have to do either 1 of 2 things.
> 1) Hard code any reference to datasources, username and passwords into
your
> CFCs
> 2) Only have CFCs that to not require the accessing of external variables.
Not really, i'll explain below.
>
> The reason I say that is this. I personally do see the security logic in
> having your CFCs off your site root (ie site/components), so you would
have
> to store them somewhere else, somewhere that is outside the application
its
> self. Becasue of this, when you call the CFC as a web service, there is
no
> way that the CFC knows where to get the variables it needs, unless it
> inherits or calls another CFC to somehow gather the variables it needs to
> run. Also using XML files to store the security information it needs and
> loading it into the CFC I don't particuarly like. Not for the fact that
> your loading an XML packet, more that you are storing that information in
a
> plain text format.
In my view, the storage of CFC should not be stored within your applications
structure where possible, the reason for this is that you remove the
capabilities of a blackbox environment, where say you have a
shoppingcart.cfc that can be totally independent of all applications. In
storing this component within your applications directory, basicallly paints
you into the corner of having all other applications that leverage this
component point to that specific area instead of a neutral zone. That or
your constantly making clones of the component?
You stated earlier that you store your environment variables inside a
database, to which like the XML packet, becomes free text. In storing
configuration files, you could store them anywhere you like and even have
the ability to encode the data within the packet structure, so that the
business logic on initialization decodes this data and returns the necessary
variable values to continue onwards.
In reading the XML packet you assume i'm reading it like myXML.xml file,
which would return all the information within the packet, but what if you
put a .cfm extension on the xml packet and make the root nodes <cfsilent>
then if someone where to access that file directly through the web browser,
all they would see is an error "The XML page cannot be displayed"
So how do you read the XML file then? Using CFFILE, you simply read the file
like this:
<cffile action="read" file="appConfig.cfm" variable="myXML">
<cfscript>
XMLFeed = XMLParse(myXML);
</cfscript>
<cfdump var="#XMLFeed#">
Which will return the structure of the appropriate XML feed, to which can
only be accessed via CFM server!
You stated earlier that if someone where to access your CFM server could
have access to environment variables (which i agree), to which I also reply
again that if someone where to access your server, a simpe cfdecrypt will
provide you with a wealth of information, so much so that they wouldn't even
have to bother reading your XML packet as they would simply use it against
you anyway.. in that say they replace the index.cfm with their own and by
reading your source code they find out all the tables within your database
via your DB queries and simply initiate a DROPALL on such tables.
Point is, don't delude yourselves into thinking just because you encode the
cfm files means they are out of harms way? you have to treat your source
code as just that, open source and ready for an attack should someone
penatrate your servers security layer.
RE: Using Database as your variable mapping engine, Not only do you limit
your applications scaleability by relying on your database layer as your
primary footing for the applications abilities to perform its tasks, but you
also open your application to more problems especially if you have a large
volume site. If you store this information within the request scope, it
basically has to go and grab that information, store it in the request
scope, provide it back to the user and then destroy it on completion.
If you used the application variables properly, this information is then
stored in the applications timeoutspan once, so that if 100 people hit your
site at once, the information is initialized once per 100, vs's. 100 times
per 100 visits. Performance wise, its a bit of a big ask.
> What I would be more likely to do would be this.
>
> First off you have an application config CFC in each of your application.
> Then where you keep all your CFC files, you have a CFC with initializes
your
> applications. So you would have something like
> <cfscript>
> intApplication = CreateObject("Component","appPath.intApplication");
> </cfscript>
> Then from here you can do lots of thing. Let look at 2 functions. inApp
> and returnApp.
>
> If you were calling it from within your application, you would call the
> intApp function which would set up the application for your application
> under a web app environment.
> <cfscript>
> intApplication.inApp();
> </cfscript>
> Now, if I had a web service, I would call the same CFC, but call the
> returnApp function. This function would gather the application variables,
> and return that structure to your CFC, and away you go. You then have
> access to everything your web application would, including DSNs,
usernames,
> passwords and anything else you set.
> <cfscript>
> returnStruct = intApplication.returnApp();
> </cfscript>
> This way, you still have a central location to control and maintain your
> environment, yet you are able to call it from anywhere.
>
> You may think that your still relying on your presentation layer for this,
> but your not. This CFC can be anywhere you like really, and can pass what
> ever arguments you need to get the application set up.
>
> This also means you can have a many to many relationship with that CFC,
> rather than a many to one relationship as your method will.
>
> What do you think?
This is the same concept as what i proposed only instead of hardcoding that
information into the actual cfc, you could store it in a central depositry
for not only the CFC's to leverage but other "entities" that may wish to use
such configuration. In saying this you can not only store you DB DSN
variables, but file mappings to various areas of your server to which both
CFC's and Presentation Layer utilise. Furthermore, depending on your
environment you can open up the ability to pass a varibale into such an
initApplication() to tell the application to load a specific configuration
file per app (ie if you have a CMS system and you want InstanceA of your app
to point to DBA, and InstanceB to point to DBB and so on.
This then allows your application to be portable and installation to be a
simple process of one file manipulation rather then mutliple files.
In a nutshell, using the XML method of storage vs hardcoing/database lookup
allows for future proofing aswell, especially if down the road CFMX has the
ability to compile / encrypt the source code into binary or have obsfucate
capabilities. So instead of opening the code, changing values, and then
recompiling/encrypting/obsfucating it again and again, you can simply feed
off the power of XML..
Scott Barnes
Snr Developer
eCommerce Department
Tourism Queensland / Sunlover Holidays
[EMAIL PROTECTED]
ph: (07) 3535 5066
---
You are currently subscribed to cfaussie as: [EMAIL PROTECTED]
To unsubscribe send a blank email to [EMAIL PROTECTED]
MX Downunder AsiaPac DevCon - http://mxdu.com/
