JOB: LAMP Artisan

Dan Egli ddavidegli at gmail.com
Mon Feb 24 02:55:38 MST 2014


On February 21, 2014, Doran L. Barton wrote:

> Uh... I'd develop using Java over PHP any day.



To each their own. Java has it's good points, but so does PHP to my point
of view.



> While it has a seemingly

> ubiquitous install base (and user base), it still has a horrible security

> record and incomprehensible language design.



I hope you don't mean that seriously. I've developed many applications
using PHP and have yet to have any of my projects exploited. The logs on
some of my test projects indicate several people trying to break in (after
I invited friends and other programmers to try and break in so I could test
the security of the code), but the only times they got in were when I
forgot to be careful and took shortcuts I shouldn't have taken in the first
place. Once I fixed those shortcuts, the attempts all failed. I'll grant
that this was with Pgsql and not MySQL, but I'm not convinced the separate
DBMS was entirely responsible (partially, sure, because people did try
things known to work through MySQL, but they failed naturally enough on
Pgsql). And please don't ask for any details of exactly what was tried or
how I got around it. It's actually been quite a few years since I did much
of any web coding and I don't recall all the details of what I did.



I'd probably do the same thing again today, frankly. If I was building a
"LAPP" project, I'd build it, but before releasing it to public consumption
I'd ask some people (maybe even plug folks) to try and break in, and to
tell me of any successes so I could plug the holes they find.



To me that just seems to be good practice for any project that is going to
face the general public. You design it. Then you try to break in. Once YOU
can't break in, then it's time to ask others. After all, they might try
something you never thought of. So once THEY try to break in, and succeed
(assuming they do) you can in turn fix those holes, and any that might have
been missed but you see them now because they are similar to something that
was tried. Once that works, then you release to the public. And of course,
during this test time, you use a test copy of the database rather than the
real database. That way, if someone who was actually trying to get in for
actual malicious usage rather than just test it for you manages to do
something, the test database is the only one compromised. And that's all
but harmless because it's easy to drop a test database and re-create it
from the "production" database.



Does anyone have a real objection to this approach? I'd be curious. It's
worked well for me in the past, but perhaps there's a better approach now?


--- Dan


On Sat, Feb 22, 2014 at 11:14 AM, Levi Pearson <levipearson at gmail.com>wrote:

> On Fri, Feb 21, 2014 at 1:20 PM, Matthew Frederico <mfrederico at gmail.com>
> wrote:
>
> > Yes - it's not a perfect programming language like node,
>
> Ack!
>
> No!
>
> Node (and javascript in general) so far from being "a perfect
> programming language" that it's not even funny.  I'd probably take
> javascript over PHP if I had to, but I actually think it's easier to
> write terrible, incomprehensible code for node.
>
> Let me explain myself, because I realize this goes against common
> wisdom and hype.
>
> PHP strongly encourages writing very linear control.  You get a fresh
> "interpreter state" at the beginning of every request, and the app
> follows a route through the code towards the final sending of a
> response. And then you're done, aside from whatever changes you made
> to the database along the way. If something goes wrong, you can dump a
> stack trace or whatever and figure out what it's doing. Sure, the
> concerns might not be cleanly separated, there might be SQL queries in
> the middle of rendering code, but although the code may be terrible it
> is at least *straighforwardly* terrible.
>
> Node, on the other hand, straight up *disallows* linear control flow
> for anything but the most straightforward request/response actions.
> Everything is callback-based, and there's a popular notion that this
> means you don't get concurrency errors. Well, that's just not true.
> You've got persistent state in your node process, and every time
> control flow passes through a callback, some other request can come
> along and change that state. Interleavings are not *arbitrary*, but
> they are still *common*.  There are some patterns and idioms that can
> restore some semblance of sanity to complex control flow, but you have
> to know about them and use them properly.  And when things go wonky,
> there's no complete stack trace to help you figure things out, just a
> fragment recording the stack frames since the latest callback.
>
> Don't get me wrong-- Node is an excellent tool in the hands of a
> competent programmer who's got a firm grasp on managing concurrency.
> But then PHP can produce excellent results in the hands of competent
> programmers as well. It's actually very fast for straighforward
> things. The question is, which one fares better in the hands of
> less-comptent programmers? I'm afraid I have to go with PHP here.
> Yeah, it's a mess, and incompetent programmers have made lots of
> messes with it, but they're straightforward kinds of messes.  The
> kinds of messes you can make with Node if you're not really good at it
> are the sort that will have you completely scrapping a project.
>
> Node is pretty fast for a system based on a dynamic language like
> Javascript.  It's not particularly faster than LuaJIT2, though, and
> Lua is a *far* better-designed language if you're intent on dynamic
> typing.  Personally, I would lean towards something like Go, D, Scala,
> OCaml, Haskell, etc. as the primary language for anything not meant to
> be a throwaway prototype, and Lua for scripting. And I certainly
> wouldn't call any of them "a perfect programming language" :)
>
>        --Levi
>
> /*
> PLUG: http://plug.org, #utah on irc.freenode.net
> Unsubscribe: http://plug.org/mailman/options/plug
> Don't fear the penguin.
> */
>


More information about the PLUG mailing list