"Jeff Johnson" <jeff@...> wrote:
> I'm porting a site from Cold Fusion to Webware. One thing CF does that I
> like is that when you define a datasource in the CF Admin page, it stores
> the username and password so it never has to appear in your pages. In order
> to interact with the database, the login must have some pretty powerful
> priviledges that I wouldn't want in plain text files. Is there any way to
> hide the username and password for a datasource?
I don't know of any way to avoid putting the username/password in a
plain text file somewhere. I always put the database-connection
settings in a seperate file and import it (helps when moving from the
testing to production db, etc). You can give this file particularly
strict permissions.
Really, if a Python program is going to login to a database it needs
to have the same information a person needs to login to the database
-- i.e., plaintext login information. You can obscure it some but you
can't really hide it. I assume this is what CF does -- maybe it
encrypts the information again, but that's just obscuring it too since
the key to decrypt the information has to sit somewhere in plaintext.
In Unix I suppose the solution would be to make the script suid to
some privileged user who could access the login information. I'm not
sure how I'd do that in Webware, though -- I guess you could make the
AppServer suid to a somewhat privileged user, and just make sure that
user has the necessary permissions but nothing else (i.e., one step
above nobody). I'm even less sure how you'd do that on Windows.
> Another feature of CF that I've never had to use but it might be nice is the
> ability to encrypt entire pages so the server can decrypt and serve them but
> the source isn't easy to copy.
Well, there's no real limit on what you can do, though the key
security still remains an issue. I've made Python wrappers for GPG,
and they work well enough. There might be modules for encryption in
Python -- I haven't really looked.
You could make a servlet that decrypted the contents of a file, and a
factory that associated this servlet with certain extensions. That's
if you wanted to encrypt content. If you want to encrypt code, you'll
have to go through many more gyrations, decrypting then evaluating.
Considering the difficulty, it wouldn't really give you a whole lot
more security -- it's unlikely you can secure the decryption key any
better than you can secure the files. If you had people putting
GPG/PGP encoded files in a public location however, you could gain
real security. Also, if you receive the key from the user themselves
and don't store it this will give you some security.
If you can't be sure of the integrity and security of the server
itself it's all rather difficult.
--
Ian Bicking Colorstudy Web Design
ianb@... http://www.colorstudy.com
homepage: http://www.colorstudy.com/ianb
4769 N Talman Ave, Chicago, IL 60625 / (773) 275-7241
|