EeeeeEeEeEe, that sounds like a big security hole to me, Nat... I'd say this
much: If I was going to expose db conns to the client, I'd be sure that the
username/pw involved were ones that on the server end only had Select
permissions in the db, and had views in place to severly restrict what they
had access to.
Which brings up a point I'll toss out here for y'all who might not realize
it: You don't have to have only one ODBC connection for a given database.
Now, most folks get a db conn going in CFAS with a SQL login account, and
call it a day. They use the same ODBC connection for doing generic queries,
and big time "DELETE * from Users" type of queries.
I'd suggest creating separate ODBC connections, with separate SQL
login/password accounts. Grant only the specific permissions needed to the
accounts. And, on the SQL server end, use views to choke access down to only
the necessary stuff. This way, if some sneaky person manages to obtain a
valid login/password to get an ODBC conn going, hopefully its a benign one
that only has SELECT permissions in the db, and only exposes non-sensitive
data.
> -----Original Message-----
> From: Nat Papovich [SMTP:[EMAIL PROTECTED]]
> Sent: Friday, May 25, 2001 10:09 AM
> To: Fusebox
> Subject: RE: Javascript Client Variables
>
> Kevin -
>
> Hitting a database through JavaScript is, in fact *entirely* possible,
> thanks to Windows Script Host. Check out www.microsoft.com/scripting for
> more details.
>
> Basically, you use javascript or VBScript to make a call to the windows
> script host resident on most windows clients (NT4 and win2k for sure, I
> think also 98 and ME or more). The client machine, running your web page,
> uses the browser to connect to the script host on your machine
> (wscript.exe
> and/or cscript.exe in your win32\system dir) which can run perl scripts,
> vb
> scripts, etc, etc.
>
> Now you just have to find some knowledge to write a script that connects
> to
> a webpage somewhere (which shouldn't be too hard). Then your web page can
> do
> whatever processing it needs to do, including hitting a client DB. Check
> out
> adminscripts.net for examples and free downloads of pre-made scripts.
>
> Alternatively, you can use a hidden frame to hit a web page that does
> client
> db manipulation. A button click or something on your main page can submit
> a
> form on your hidden frame that posts to the web page. Definitely less
> cool,
> but easier.
>
> What's the specifics of the problem you're trying to solve such that you
> need JS to talk to the client db?
>
> NAT
>
> > -----Original Message-----
> > From: Kevin Bridges [mailto:[EMAIL PROTECTED]]
> > Sent: Friday, May 25, 2001 7:21 AM
> > To: Fusebox
> > Subject: RE: Javascript Client Variables
> >
> >
> > Yeah ... I would love to get the variables into the db though. What
> about
> > some type of server side javascript? Is that something that is
> Netscapes
> > Enterprise Server specific or does something similar work on
> > apache or IIS?
> >
> > -----Original Message-----
> > From: David Huyck [mailto:[EMAIL PROTECTED]]
> > Sent: Friday, May 25, 2001 8:26 AM
> > To: Fusebox
> > Subject: Re: Javascript Client Variables
> >
> >
> > You can write the client vars to JavaScript pretty easily using WDDX, I
> > think... But JavaScript does not inherently have access to
> > anything on the
> > server; you have to write it to the client first.
> >
> > David Huyck
> > [EMAIL PROTECTED]
> >
> > | Does anyone know if it is possible to get javascript to
> > read/write to the
> > | client variable database? Is this something that is even possible?
> > |
> > | Thanks,
> > |
> > | Kevin Bridges
> >
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Structure your ColdFusion code with Fusebox. Get the official book at
http://www.fusionauthority.com/bkinfo.cfm
Archives: http://www.mail-archive.com/[email protected]/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
