Having spent so much time and resources on Perl, I am beggining to wonder if I chose the right path in using it to develop web based solutions. I want to ask the monks in what ways can a developer combine this two technologies, so as to take advantage of the fact that a developer is familiar with both.
Thanks.
|
---|
Replies are listed 'Best First'. | |
---|---|
(Ovid - PHP danger) RE: Combining PHP and Perl
by Ovid (Cardinal) on Oct 07, 2000 at 03:43 UTC | |
The way that PHP handles file uploads makes it simple to trick PHP applications into working on arbitrary files local to the server rather than files uploaded by the user. This will generally lead to a remote attacker being able to read any file on the server that can be read by the user the web server is running as, typically 'nobody'.According to the alert, they don't know of any way to really fix this problem, short of a new version of PHP being rolled out.
Cheers, Update: First, thanks for pointing out how to protect against this vulnerability. I'm not trying to say that PHP is evil, just that there is a known issue with it (and I'm not claiming that there aren't issues with Perl). Next, I can see people voting me down for making a rude post, but why vote me down for letting people know about security issues? I would presume that people would prefer to know about these things. If there is a fix, people won't bother to apply it if they don't know what about the original vulnerability is. I will confess that I didn't follow the links, but in seeing them, I see bad security advice in one: check to verify that the file sizes are the same and reject them if they aren't. Fine, so all I need to do is keep sending files in increments of one byte until I get a hit. That's pretty simple to crack. The other one -- verifying the filename -- is obvious and I wouldn't have realized it since I don't know PHP. However, I still let my original post stand. There is a security issue and "according to the alert", the author didn't know how to fix it. I still feel it's important to raise issues like this because people should be aware of them. Join the Perlmonks Setiathome Group or just go the the link and check out our stats. | [reply] |
by arturo (Vicar) on Oct 07, 2000 at 04:05 UTC | |
Darn, I hate playing PHP apologist all the time. That securityfocus page has been up for some time, and there is an easy fix *in PHP* for it. It's called "checking the filename before you use it." Sure, it's a bit of a pain but it will have a more permanent fix soon. The PHP manual says this (now). If you follow the thread on securityfocus that Ovid posted, you can see how the PHP team responded. Back to the question at hand: PHP lacks a few features that I find handy in Perl, but of course the lack will only bother you if you use these features. I am otherwise a staunch advocate of the "use what works," so if you find that PHP works for you, use it. Just don't come cryin' here when it doesn't work for you =) But PHP is still young, so this may all change. Philosophy can be made out of anything -- or less | [reply] |
by Malach (Scribe) on Oct 16, 2000 at 01:22 UTC | |
Just a comment.... your initial posting (pre-update) started with a generally negative statement, *then* qualified that, by going into detail. "Use it at your own risk" is true of any language/system/whatever.... including php and perl, but in this instance, I think overstates the problem. | [reply] |
RE: Combining PHP and Perl
by pope (Friar) on Oct 09, 2000 at 12:55 UTC | |
Embperl is page oriented, fast (written in C/XS), and added syntatic sugars for web development convenience. HTML::Mason is written in pure perl, more site oriented, and offers many features which is hard to find on other templating systems such as dhandler, autohandler, caching, and output filtering. Assuming that these are run under mod_perl, Mason is slower than Embperl, and I think Embperl performance is comparable to php's. Raw mod_perl is faster than php. But I don't think that this speed differences is significant in most web apps. An apache + mod_perl httpd size is large, 10-20M is typical after loading some required perl modules. So you may take this into account when you want to build an apache + mod_perl + mod_php + mod_? php is appropriate for most web tasks, but if you want some esoteric functionality, or you want to get the best performance, you'd better use mod_perl. | [reply] |
RE: Combining PHP and Perl
by Anonymous Monk on Oct 08, 2000 at 13:59 UTC | |
| [reply] |
by Anonymous Monk on Oct 08, 2000 at 16:47 UTC | |
Live Processor = Ahh...Relief! | [reply] |
RE: Combining PHP and Perl
by pandr (Acolyte) on Oct 15, 2000 at 12:44 UTC | |
"It's all well and good to place a GUI wrapper around an existing tool, but to design a new application with only a GUI interface in mind is to forever limit that tool's flexibility." Because web programming is similar to gui programming you have the very same pitfalls. Consider a portal like site where users are allowed to create accounts. You may start by implementing this in pure PHP (the create_account.phtml page) and this typically involves DB access, password checking and what not. As your site grows you want to be able to administrate it in a more effecient manner, so you write a command line tool (in Perl) to allow quick (i.e. scriptable) handling of the accounts. This is were the pain begins. Now you have identical logic (SQL-statements, password checks, etc.) implemented in PHP and in Perl. Of course you know that is bad, but if you have thousands of lines of PHP code you are trapped! I am not saying PHP is bad. I use it myself from time to time. But I have seen people get burnt by the above scenario. (Yes, I know PHP can be used to create command line scripts, but that is definitely NOT where its strenghts are, IMO) | [reply] |
by footpad (Abbot) on Oct 15, 2000 at 22:23 UTC | |
I have noticed this myself, even in the admittedly simple uses I've put these two. One my sites is based around templates originally generated by PHP3. Given PHP's security problem with multi-part forms, I decided to implement an upload process using perl. In doing so, I found that I had to re-design my template process to make them easier to share between PHP and perl. While a reasonably trivial task, it did take some time that I could have used for other portions of the project. The lesson, then, is to take some extra time during your design phase to make sure that your implementation can suport multiple tools and processes. | [reply] |
RE: Combining PHP and Perl
by AgentM (Curate) on Oct 07, 2000 at 05:38 UTC | |
AgentM Systems or Nasca Enterprises is not responsible for the comments made by AgentM- anywhere. | [reply] |
by Anonymous Monk on Oct 08, 2000 at 00:09 UTC | |
I was trying to type in "http://www.phpmonks.org" and accidentally typed in "http://www.phpbuilder.com", but that didn't work. Trying again, I typed in "http://www.zend.com". Stupid PHP, you can't even spell the name of its support websites right. | [reply] |
by Ignorance (Monk) on Oct 10, 2000 at 07:04 UTC | |
but you might try php.net...;) | [reply] |
by mischief (Hermit) on Oct 08, 2000 at 21:12 UTC | |
I think that PHP has it's uses and can be used in conjunction with Perl to get stuff done. They both have their advantages and disadvantages, but you can only really make up your own mind on the matter by trying them out. Try doing the same task in PHP and then try again in Perl - sometimes PHP will be best for the job and sometimes Perl will. | [reply] |
RE: Combining PHP and Perl
by footpad (Abbot) on Oct 13, 2000 at 00:09 UTC | |
rodry, In my opinion, having skills in both can only be a good thing. Each was designed for different purposes; each can solve some of the same problems. However, the more tools you have in your kit, the more likely you'll be able to choose the correct one for the specific problems you encounter. Besides, it can only make you more marketable in the long run. -- f | [reply] |
RE: Combining PHP and Perl
by swiftone (Curate) on Oct 13, 2000 at 00:24 UTC | |
I've recently been learning mod_perl, and working at moving my mindset over to it. It's not difficult, so much as a drastic mental switch. I've always avoided PHP, ASP, Coldfusion, Embperl, and other solutions of those types. I recently discovered Text::Template, and I love it. What's the difference? Dependence on the webserver. With CGI Perl and Text::Template, I have command line scripts that are optimized to work with HTML browsers, but that function and are accessable without them. When you convert to mod_perl, your documents cease to be apps, and the webserver stops being a document server, and instead becomes (in the words of merlyn), a programmable app. Since I tend to prefer to keep things low level and accessable (ASCII forever!), this is a bit of a drastic switch. So when looking at PHP and Perl, think about how you want to view your documents. | [reply] |
by princepawn (Parson) on Oct 13, 2000 at 16:56 UTC | |
With CGI Perl and Text::Template, I have command line scripts that are optimized to work with HTML browsers, but that function and are accessable without them. Can you provide us with some samples of documents you have that work (seamlessly?) for both web service and command-line use? On this topic, Tom Christiansen floated a paper across Usenet awhile back that you should try to get if possible, named "GUIs Considered Harmful". In it, he states that an application should be useable from programs, the command line and the GUI. | [reply] |
by swiftone (Curate) on Oct 13, 2000 at 17:58 UTC | |
I never claimed seamlessly :) What I meant was that any CGI script using CGI.pm should be able to be run from the commandline. For large sites, I currently use Text::Template to import/interpret templates (much like HTML::Template, etc), but I write the resulting HTML to flat files that the webserver serves. (even mod_perl has problems hitting the speed of flat HTML). With flat files holding content, I can manipulate the pages with scripts and other *nix tools such as grep, ispell, etc. Of course, this prevents me from having truly user-specific dynamic pages, so I write any of those with CGI perl scripts. When those scripts become large portions of the site, mod_perl is clearly a better solution. But it's a different mindset. Tom Christiansen floated a paper across Usenet awhile back that you should try to get if possible, named "GUIs Considered Harmful". I'll look for it, thanks | [reply] |
compiling apache with mod_perl (DSO) and php4
by meonkeys (Chaplain) on Nov 04, 2000 at 02:48 UTC | |
If you are crazy and DO decide to compile Apache with php4 (with mysql support) and mod_perl (as a DSO), make damn sure you use your own mysql library and header files. If you installed mysql from binary or source rpms, the required files are in /usr/include/mysql and /usr/lib/mysql, so you tell php:
and it's able to find everything it needs. If you use the mysql headers/libs included with the php source, you may witness unexplainable segfaults when trying to use modperl DBI connects to a mysql server. Here's my build script in case you're interested...
| [reply] [d/l] [select] |