Mason 1.0 Released
Sowbug writes: "Perl programmers rejoice! Mason 1.0 was released today,
though prerelease versions have been in operation for years at websites like TechWeb,
Salon.com, and AvantGo.
Congratulations, Jonathan Swartz
(principal author of Mason)!" I don't know much about Mason, but it seems like another cool addition to the Cold Fusion/PHP world of embeddable code in Web pages.
Perl is the duct tape of the internet. If it was so vulnerable it wouldn't be so widely used.
Hmm ... that's a strange logic. With such logic, we can logically deduce that BIND is the parangon of computer security, that sendmail is a great piece of software, and that Paul Vixie knows how to write code.
Might be a bit too much.
--
I have been using Mason and related packages for a long time. I agree strongly with the people who say that mixing code and markup is a bad idea. I would go even further from my own experience, and say that mixing execution and display in any way is a bad idea.
On receiving a web request, the first thing to do is process the input, perform any operations, and then set up necessary information for doing a page display, using a tool such as Mason, with the least possible amount of code. My Mason pages rarely contain more than a <% $object->get('foo') %>.
In this way one has the versatility to redirect internally if an operation fails, and one doesn't have to cope with a page crashing halfway through display.
Mason is an excellent tool for controlling a structured web site. Mixing markup and code, execution and display is a separate, general topic, and should be considered apart from any specific tool.
If someone has a .WAV of this, it'd be much appreciated.
The song is called "We Do (The Stonecutter's Guild)" and it's available on the Simpsons'
CD "Songs in the Key of Springfield" (A play on the name of the X-Files CD "Songs in the Key of X").
- web sites running Perl are notoriously insecure
Are you trying to claim that it's the half of the web which isn't running on asp that is insecure- It's not because Perl is insecure, it's because Perl makes it so damn easy to just "get something working", and clueless people are writing insecure scripts all over the place.
Uh... you miss the point. You run the script (root 'sploit, not cgi) on the perl interptreter on your local machine - not the remote machine that you are trying to hack into. Which err... was my point - the hacker uses perl as a tool, perl isn't part of the problem.and if you are refering to cgi scripts that people have writen themselves - well when you write a cgi script you are writing a piece of software - and if the software that you write is insecure, then that is not a bug in perl, it's yer own damn fault.
- Especialy since there is a root exploit for every known version of perl in existance
I think it is fair to say that perl is a relatively secure & bug free piece of software.Mason looks okay but its still developing script within the HTML, when working with designers who don't know perl this becomes a problem. I've been using a mod called HTML::Template for some time now and I highly recommend it to anyone building web pages with Perl. HTML template allows a set of specialized HTML tags in that actual HTML documents that a separate script uses to insert data. It has varables and loops and if/else structures.
HTML::Template can also do caching of HTML pages when used with mod perl, plus the tags are ignored by commonly used HTML editors such as Dreamweaver. All in all I think its a much better solution.
"One World, one Web, one Program" - Microsoft promotional ad
The Anti-Blog
If you need to create files on the local filesystem (this can usually be avoided but not always), would you rather do it in a directory that is world writable (or writably by the web server process, which may as well be the same thing if you have lots of CGI/mod_perl/whatever) or would you rather have a Perl script that is setgid to some special group and only give that group write access?
This is largely a moot issue with the proliferation of scripting languages running within the web server process, although sometimes it is worth taking the hit of a fork+exec(+perl startup (ugh)) in order to restrict access to important files.
Hear hear!
"But is ASP stronger?"
"No! No. Quicker. Easier. More seductive."
--Just Another Pimp A$$ Perl Hacker
El riesgo vive siempre!
Use templates.
--
Akopia, recently acquired by RedHat, developed Interchange, which is an awesome web development platform for e-commerce websites. It's GPL. I highly recommend you check it out at: http://developer.akopia.com
Daniel
...if you don't know the secret handshake?
-----
Who controls the British crown?
Who keeps the metric system down? We do! We do!
Even the cost of a Win98 licence is more than the minimum monthly wage.
The existence of open source and free products like Mason, Zope etc will go a long way to ensure that disseminating information is not constrained by the cost of the tools.
Well done to the Mason group.
Live today. Tomorrow will cost a lot more!
No you are not following the logic at all. When someone finds a new hole in BIND it is all over the news (news sources for geeks anyway) and *everybody* knows about it. Same with sendmail. If Perl had root exploits it would get the same amount of attention. There should be links and stories all over the place about it. Now show me said proof and I'm willing to buy into it. About the only thing I can find on securiteam.org is something about Activestates Perl and a exploit having to do with Perl and IIS. Everything else looks minor and quickly patched or like using Perl to do exploits. Looks like there might be a couple of modules you would like to research also. Compare that to what a search on IIS reveals. :)
Cypherpunks: Civil Liberty Through Complex Mathematics. Those who live by the sword die by the arrow.
"You can emmbed php in html but not perl"
I would call that a strike against PHP. I thought the whole concept of clean design was to separate content and presentation. It's difficult to do that if you're constantly embedding <? some php code ?> and then the site designers want the look to include mauve tilebars or something.
Not that I don't think he was trolling, but try a google search on 'suidperl' and 'bugtraq' and you'll get a number of results describing buffer overflows.
And anyway, there's nothing wrong with blunt object references ;-)
Just don't do it. It's bad practice to use suidperl. Mason doesn't require it.
bp
Mason is pretty nice, I checked it out when it was just getting started. They've done a lot since then.
The high-level features are outlined on their site. Among them are: caching of HTML and data, use of the Perl debugger, and staging vs. production execution modes.
The CPAN repository is chock full of mind-bogglingly useful code, so it's nice to see more tools coming of age that allow you to take advantage of all of that through the Web. mod_perl is very nice, but for some tasks, it's just too cumbersome to work at that level. Mason nicely abstracts that away.
You're wrong. It's not a strike against PHP. Here's why.
All templating systems require code to be embedded in HTML. It may be as simple as "put this variable here" -- but it's still code. A robust templating system that supports dynamic page generation, personalization, and database interaction will inevitably require common programming-language constructs, such as testing, looping and branching, at the presentation level.
While it is sound practice to separate business logic from presentation logic, and presentation logic from look and feel, it is a practice that should be followed insofar as it is practical and beneficial. And no further.
It's a lot like Einstein's position on simplicity: a theory should be as simple as possible, but no simpler. Do not follow ideas over cliffs.
By providing a common language at all layers of an application, PHP allows the application designer the freedom to do the right thing, or the wrong thing. I'm fine with that. The smart designer will make a wise choice, and the dumb designer is probably using a different platform anyway.
It's not because Perl is insecure, it's because Perl makes it so damn easy to just "get something working", and clueless people are writing insecure scripts all over the place.
You could have the same problem with any technology, but not so many clueless people are cabable of writing swiss-cheese-security programs in C. Besides, by now there has been enough yammering about input validation that most of the "CGI for Dummies" books cover security a little better than they used to.
include $sig;
1;
As promising as Mason is, the maintainers have a very poor design philosophy. They consider it acceptable for the line numbers produced in error messages to *always* be incorrect! They consider it acceptable for the external and internal names of parameters to a component to use a common naming convention thus ensuring that you cannot use the %ARGS section if you want to use valid HTML parameter names that are NOT valid Perl names. The classic example: If you have an image input called foo, the browser will send parameters called foo.x and foo.y (you can't change this) containing the coordinates of where the user clicked.
Oddly enough the idea of having a generalized mapping was rejected in part because they didn't want to make Mason "HTML specific"! Instead, apparently, they want to force everyone into a lowest-common-denominator between Perl and whatever they are using Mason to interact with.
I used to think Mason was great, but this poor design philosophy forced me to abandon it in favor of tools that are designed with quality in mind.
-JF
MrJoy.com -- Because coding is FUN!
AAARGH! Another one! Another goddamn DIY html templating mechanism! Have you ever *thought* about looking on CPAN? Do you know that there are dozens of different html templating/perl embedding packages out there already?
Code reuse. It's a good idea. This means you. Do some research before you start typing.
Here's one:
www.perldoc.com - HTML::Template
Here's another:
www.perldoc.com - CGI::FastTemplate
And here's an archived thread of people who know more than we do talking about these things:
templating:html_perl_separation_&_perl_embedding
Personally, I recommend Mason. When in doubt, always go with the most powerful tool you can find: so you know the choice won't limit you later. And yes, it is possible to use Mason in an organization where the HTML people are too stupid to be let near perl: I've seen it done. You just keep the Mason calls simple, and keep the complexities out of their face.
Is this realy a good idea? Especialy since there is a root exploit for every known version of perl in existance? Perl doesnt and will never run on my machine.
Absolutely. I threw my computer away because having one just an invitation to the script-kiddies.
http://twitter.com/onion2k
His mistake (or probably troll) is in the fact that the waekness is not in perl - perl is just usefull in expoilting the weaknesses in other software.
Modsnake
allows you to embed Python Power statements directly into HTML code. Perl is quite cool too, but I don't know how good it would be for new programmers (post 1994). I think that the majority of new programmers will choose Python over Perl, but older programmers who are familiar with Perl will probably stay with Perl.I've used Perl in several of my projects, but more often than not the project consisted more of Python code. Well, a mixture between Perl, Python, Java and C isn't unusual in some large projects, but 70% of the code, you'd find, will probably be Python.
Embedding scripts in HTML can be done in a way that minimizes problems when you change appearance and empowers designers. Generally, if you create some high-level functions with easy to understand parameters, you can pass that info on to people who are doing the client side design and have them incorporate things nicely.
... starts with an x...).
As a *simple* example, suppose I've got a list of frequently changing links that I want displayed on any page in a given site (let's also say frames are out). I can throw the links in a file or in a database, and create a PHP function
showlinks();. I pass this on to the client side team, and wherever the list of links is to appear, they just include:
It's just like they got a new tag to play with (hmmm. This reminds me of something else
This can get more difficult, obviously, as things get more complex, but if you're willing to put in the work to do the proper abstraction, and you have client-side folks with a few ounces of intelligence, it seems to work pretty well in many situations.
--
Libertarianism is rich wolves and poor sheep playing gambler's ruin for dinner.
The most bugs!
;-)
--
Fuck Censorship.
News for Geeks in Austin, TX
-- Eat your greens or I'll hit you!
-- Eat your greens or I'll hit you!
Um, GE has the largest Market Cap
GM has the highest Revenues
GE has the highest profits
WalMart has the most employees
So what has microsoft got?