Re: ssl encryption
Yes, it's possible. To achieve this, you should use asymetric encryption, and *not* store the private key in the server. Then, the question remains : how can I have the server safely decrypt on demand ?! one possible solution could be to store the private key in a remote server, dedicated to the unique task of decrypting the sensitive data. A secure tunnel could be established between the two servers, so to communicate the encrypted text, and get back the decrypted text safely. You could even add security by storing the private key in a smartcard, and having the smartcard reader connected to the server. Decryptions would have to be done within the smartcard. It's completely possible, but you almost certainly don't want such CPU-expensive operations be done within a 8-bit smartcard ! On Thu, 14 Jun 2001, Kevin Schroeder wrote: This would make an interesting discussion because I've had the same question come up in my mind. How do you encrypt things on your server without giving out the passphrase? Is it even possible to keep the key in the same location as the program using it and still maintain security? Kevin
Re: RFC: DBI::Prof
It would be nice if Tim Bunce simply added it as a parameter to DBI's existing methods. Why not ask him? Fabrice Aaron Ross wrote: On Tue, 28 Nov 2000, Stas wrote: possible SQL calls manually, so I wrote this simple profiler. Take a look and tell me if you think it worths releasing on CPAN... Definitely release it! It is a very elegant solution to a problem that I'm guessing many of us have dealt with. I've always _tried_ to write a db abstraction layer, so this kind of profiling would be easy. But I can easily think of two cases where i was trying to track down bad queries and this little trick would have saved me a lot of time. [ couldn't you have telepathically told me how to do this a year ago?? ] it would be a nice addition to the guide too. aaron - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Interfacing from Apache to Access
DBD::Proxy does work the way you describe it. I've used it with succes to address MSSQL DBs. So far, with Access I met a few difficulties with memos (Access' BLOBs), but maybe I didn't find the way to do it. Fabrice David Mitchell wrote: From: Eric Strovink [EMAIL PROTECTED] wrote: Write a simple socket interface to connect Apache Perl to your existing Windoze Perl script (which you'll hack to set up as a simple server). Invent your own protocol. Locking issues will come up, but you can manage this yourself with a little creativity. There are pretty good examples of how to do simple socket things with Perl, in the Perl books. This has already been done! See DBD::Proxy. This allows you to run a little perl Program on the machine with the Access DB which acts as a proxy DB server, then the client uses DBD::Proxy (as opposed to DBD::Oracle or whatever) to access the database. Never tried it myself, but it sounds cool! * Dave Mitchell, Operations Manager, * Fretwell-Downing Facilities Ltd, UK. [EMAIL PROTECTED] * Tel: +44 114 281 6113.The usual disclaimers * * Standards (n). Battle insignia or tribal totems
Re: Microsoft SQL 7.0 interface
You might use DBD::ODBC with DBD::Proxy as well; should be easier to setup, but probably less efficient than FreeTDS. Kee Hinckley wrote: At 5:45 PM -0500 5/26/00, Wang, Pin-Chieh wrote: Any body knows how to access Microsoft SQL/on NT from Apache on Linux ? Our data base is running on NT/SQL , but web server is running Apache/Linux DBD::Sybase and FreeTDS will work (http://www.freetds.org/). - -- Kee Hinckley - Somewhere Consulting Group - Cyberspace Architects(rm) I'm not sure which upsets me more: that people are so unwilling to accept responsibility for their own actions, or that they are so eager to regulate everyone else's. -BEGIN PGP SIGNATURE- Version: PGPfreeware 6.5.2 for non-commercial use http://www.pgp.com iQA/AwUBOTH5aiZsPfdw+r2CEQKZ/ACdHfmeg1fmSfLlj5CiapCHXWF5vy8AoP7s nVY5U4aLCjUjbnib0uNRYSJ3 =73+t -END PGP SIGNATURE-
Easy Examples to Get Started
Hi Mod_Perlers! I'm currently reading Stas's book (big thanks to all of you who contributed to this masterpiece -- it's great). But you never get tired of Good Things, and I was wondering if some very easy and commented mod_perl scripts were available, as a way to get started faster and better. Fabrice -- "Tout penseur avare de ses pensees est un penseur de Radin." -- Pierre Dac
Re: Commercial app demo
There's another way. We can't build pre-compiled modules easily, but even when you code in C or Java, desassemblers can extract some source from the binaries you deliver. As far as perl scripts are concerned, a workaround consists in trivially removing all comments and \n from the source, which makes it as hard to understand as raw C desassembled code. Chip Turner wrote: Matt Sergeant [EMAIL PROTECTED] writes: Has anyone delivered a commericial mod_perl application before? If so, how do you handle demo versions, preferably with expiration dates? One thought is to simply xor encrypt some of the modules when the user downloads it, mail him a key, and use the Filter module to decrypt at runtime using his key (retrieved from STDIN at server startup time). (cut) The problem is that no matter how you encrypt the system, it has to know how to decrypt itself. That is, if you xor, or even used DES or IDEA or whatnot, the key (password, etc) has to be included with the modules, and therefore a suitably sophisticated programmer could extract the key, decrypt your code, and have his way with your source. It can be very frustrating to not be able to compile perl :( Even without the key, they could use some kind of B::Deparse trick to get just about all of the code anyway. It's a problem we've run up against where I work. We've considered a number of possibilities, but none are perfect. Unfortunately all you can hope for is to make it very, very hard for them to modify; with enough resources, a sufficiently sophisticated attacker could change your code and make it non-trial without a huge amount of labor. Chip -- Chip Turner [EMAIL PROTECTED] Programmer, ZFx, Inc. www.zfx.com PGP key available at wwwkeys.us.pgp.net
Re: www.modperl.com
Come on, folks! www.modperl.com is a nice open source initiative. There's no specific rule about what should and what should not be put in a open source web site. We'll enjoy modperl.com just as we already enjoy perl.apache.org ! "Paul J. Lucas" wrote: On Sun, 30 Jan 2000, Gunther Birznieks wrote: Another question is why www.modperl.com at all? Why not store the material as part of the main mod_perl site? Or off of the apache site? I guess I am just not sure why the site which seems to be centered around the book is its own site anyway? Despite the fact that it's an amazing book, I have to agree with his comments. IMHO, www.modperl.com, if it exists, should be about the module (and not the book) just like www.modssl.org is about the module. The book info should either be a sub-page under www.modperl.com or under the apache site (or even perhaps www.book.modperl.com). - Paul P.S.: Ralf Engelschall designs nice web pages, IMHO; perhaps you can get him to help you with www.modperl.com.
Re: [JOB] ground-floor opportunity with ownership stake
Methinks certain `job' offers should be filtered... Having several mod_perl engineers work for free for five months, most businesses should be quite prosperous, indeed ;-) Not my business anyway. David Harris wrote: We have an outstanding ground-floor opportunity for the right person. Must have strong technical skills in mod_perl application development and some or all of the following: database development, c language, linux/unix system administration. Must also have the desire and ability to invest substantial "sweat equity" in exchange for a good ownership stake in a fast-growing web-hosting business. If you are the right person, you will become a partner in our business, and will end up owning a share which, according to our projections, will be worth $1.5 million within three years. The price of this ownership stake is working full time without pay for the first five months. You need to be prepared to make that investment. After the first five months a competitive compensation package will kick in. Technical skills we are seeking are: - mod_perl development - database development - c language patching of open source programs - in depth troubleshooting of complicated systems - linux/unix system administration - good grasp on unix fundamentals - good grasp on unix security precautions Responsibilities would include: - continuing mod_perl development on web control panel - helping create accounting database and integrating it into existing instant account setup system - administration of existing servers - limited, simple end user customer support If you wish to explore this opportunity in confidence, contact David Harris at [EMAIL PROTECTED] - David Harris Principal Engineer, DRH Internet Services -- "Quand on n'a besoin que de peu de chose, un rien suffit, et quand un rien suffit on n'a pas besoin de grand-chose." -- Pierre Dac
Re: Another IE5 complaint
Most of my users are .fr people. My logs show more than 70% of them as IE users. MS is clearly in the process of enjoying one more monopolistic situation. People just don't download Netscape. What's more surprising is the enormous proportion of IE5 users over IEx users. Seems to me that if we let them do every damn thing crosses their dumb minds, we are in for long-time troubles ;( Fabrice Scemama Eric Cholet wrote: Am I the only battling service vendor who actually feels good when somebody bookmarks my website ? I can absorb the overhead of accesses to a favorites icon. This may be a security hazard for the client, but I detect a holier-than-thou attitude here against M$. Will somebody tell me why this M$ initiative is bad, other than for pre-determined prejudices ? Maybe we're getting tired of MS initiatives, such as the very rude offline site grabbing IE5 does, the crude implementation of this favicon thing, the fact that IE5 replaces error messages with its own if they aren't at least 512 bytes or something, er, the list probably goes on a bit. Sure we can deal with all that, but at our cost and sweet time. Rgds Rod Butcher -- Eric
