• Please use real names.

    Greetings to all who have registered to OPF and those guests taking a look around. Please use real names. Registrations with fictitious names will not be processed. REAL NAMES ONLY will be processed

    Firstname Lastname

    Register

    We are a courteous and supportive community. No need to hide behind an alia. If you have a genuine need for privacy/secrecy then let me know!
  • Warning: and are NSFW. Threads may start of as text only but then pictures could be added as part of a discussion or to make some point. This is not for family viewing without a parent's consent and supervision. If you are under age 18, please do not use this section
  • Welcome to the new site. Here's a thread about the update where you can post your feedback, ask questions or spot those nasty bugs!

The future of PHP based websites

John_Nevill

New member
I haven't been around for a couple of weeks and thought I'd share the predicament that I found myself in, which ultimately raises the question on the future of shared host PHP based websites for image/forum use.

Upon returning from my holiday I was met with ~100 emails from members of my amateur photography website saying that it had stopped working, no one could post images, nor post on the forums.

To my dismay the host service provider had decided (in its infinite wisdom and without notice) to switch off a suite of PHP functionality, the very code the site depended upon

This left my website of 2 years in the making crippled. The excuse given was, "PHP has significant security vunerabilities and we reserve the right.....". Well you get the drift!

I decided to pick myself up, dust off the negatives (no pun intended) and rebuild the thing from scratch with a new host. My only real concern is is that it could happen again. It seems as though shared hosting contracts aren't worth the paper they're written on and PHP is getting a bad name.

Hence, more and more shared host providers are limiting the use of PHP. This surely does raise the issue of whether its a viable and sustainable code base for the development of images / CMS / Blog websites.

Anyhow, apologies for the off topic, but I thought it worthwhile sharing in a cautionary sense.
 

Asher Kelman

OPF Owner/Editor-in-Chief
John,

I love learning something new. Your comments intrigue me. Explain a little more of the role of PHP on various hosting services. How does it work?

Asher
 

Don Lashier

New member
PHP has had more than its share of security issues. I did a quick "google poll" and found the following:
"cert php vulnerability" = 1,410,000
"cert asp vulnerability" = 547,000
"cert coldfusion vulnerability" = 28,600

Although I've never had a problem here I quarantine PHP sites to a separate server and only allow experienced developers, don't allow ASP at all, and my own sites and majority of the sites we host are CF driven and use common scripting so I know it was written by a professional (me:).

IMO if you're doing your own scripting you really need to be in control of the server (ie dedicated or co-located server). Otherwise I would recommend using a higher level service, eg a content managed system, as the service provider won't pull the rug out from under himeself.

- DL
 

John_Nevill

New member
In general a shared host is a server which is split up into virtual servers. A high proportion of web developers use a virtual server for small/medium websites as it reduces operational costs.

Being a virtual environment, individuals share the operating system, databases, CPU and storage with other customers on a quota basis, hence the term shared host.

Like many other developers, I use a Linux shared host running Apache (web server) and MySQL (database). PHP is the main scripting language which binds and creates the interactive web environment which the end user sees. e.g. OPF is such an example of a PHP based web environment.

PHP is also free and operates under GPL (general public license) similary so does Apache and MySQL. This means that lots of developers use it without license overhead, unlike using microsoft products.

PHP is also very powerful, you can pretty much do anything you like with it, in a coding sense. This opens up vulnerbilities which in a shared enviroment impacts upon other customers. e.g. server down time and poor perfromance.

Yes its a sad world we live in and certain low lifes spend endless hours exploiting such vunerabilities. Dare I say its becomiing a form virtual terrorism!

So in order for host providers to reduce risk they reduce sever functionality!
 

Don Lashier

New member
John_Nevill said:
Yes its a sad world we live in and certain low lifes spend endless hours exploiting such vunerabilities. Dare I say its becomiing a form virtual terrorism!
I couldn't agree more, and the analogy to "real world" tactics is apt. And it's not all just script kiddies getting their jollies and having contests, it's also culture wars going on. Anti-MS factions launch exploits to embarrass and degrade MS (products) and myself and other hosting providers have caught MS with their pants down attacking PHP and CF sites.

Years ago, in the pre-net days when viruses were still spread by floppies, a friend of mine who worked for a major anti-virus sw company confided that his company actually hired programmers in eastern europe to devise and spread viruses to create demand for their product. Ethics today seem no better - do whatever you can get away with, and on the net, that's a lot.

- DL
 
Asher Kelman said:
So what's the advice for now forward? How do we limit risk?

Since the majority of PHP vulnerabilites I have noted are in bulletin boards the best advice is to keep your tools up to date.

If you are very serious, then go to https://forms.us-cert.gov/maillists/ and sign up for their mailing lists and scan them for software you use and follow their advice which typically involves patching software to the latest version.

I would be cautious of Don's google stats too. For instance, this week there are zero PHP vulnerabilties at http://www.us-cert.gov/cas/bulletins/SB06-233.html but there are huge numbers of vulnerabilites in PHP based apps. If you log 404 errors, then you can put your finger on the pulse of the latest attacks.

enjoy,

Sean
 

Don Lashier

New member
Sean DeMerchant said:
Since the majority of PHP vulnerabilites I have noted are in bulletin boards the best advice is to keep your tools up to date.
That's the best advice. And I suspect that the bulk of vulnerabilites are actually introduced at the app level rather than the tool (scripting language) level. The reason bb's show up so much is simply that most vulnerabilities have to do with script or sql injection in form posts, and of course this is the core of any bb system.

I would be cautious of Don's google stats too.
In this particular case the method proves to be flawed. The reason is that many of the security related sites use PHP for their reports, so for instance, the google search contains listings like "ME Download System inc/sett_style.php Vb8878b936c2bd8ae0cab Variable ... US-CERT Technical Cyber Security Alert - Microsoft Excel Vulnerability (TA06-167A) ..."

I will also note that most of the reported issues were with earlier versions of PHP. Looking at CERT's current activity and alerts, almost everything is Microsoft although Apple and Mozilla are there also.

I don't really think PHP is in any danger of disappearing.

- DL
 

Asher Kelman

OPF Owner/Editor-in-Chief
Don Lashier said:
That's the best advice. And I suspect that the bulk of vulnerabilites are actually introduced at the app level rather than the tool (scripting language) level. The reason bb's show up so much is simply that most vulnerabilities have to do with script or sql injection in form posts, and of course this is the core of any bb system.........................
- DL
What do you mean by "most vulnerabilities have to do with script or sql injection in form posts".

Asher
 

Don Lashier

New member
Asher Kelman said:
What do you mean by "most vulnerabilities have to do with script or sql injection in form posts".

Asher
I should first mention that probably the most common vulnerability is buffer overflow which is typical of Microsoft exploits. Evidently they don't follow even basic safe programming practices at Microsoft as these seem to turn up at the rate of about a dozen a month judging from the security fixes I receive.

But back to injection. When you click "submit" on a form you are sending information to the server that the server processes and usually stores on the server somewhere, typically in a database, so that it can subsequently serve this up as data (a web page, or part of a web page). Scripting languages, javascript in particular, have become so ubiquitous that tidbits can be inserted nearly anywhere and if not carefully screened they may be executed at unintended times and places. What with all the various encoding methods and idiosyncracies of browsers and script engines, it's not too hard to disguise these so they get past normal checks (if these checks are done at all). The classic recent example is the MySpace Cross-Site scripting worm. For the technically curious, the author gave a detailed explanation of how he did it. (someone should hire this kid!).

The classic simple-minded example is form page (login page or search page) that plugs values passed from the browser straight into an SQL query. Here's a nice detailed example along with recommended mitigations. But as the myspace example shows, it's not that easy to anticipate or deal with all the possible permutations and idiosyncracies when you're up against a clever and determined kid.

- DL
 

Asher Kelman

OPF Owner/Editor-in-Chief
Don,

What are the methods that service providers use beyond filtering for illegal tidbits? For example do they have an array of queries at intervals to test the integrity of the system and then if something is wrong revert to a state at t-x seconds earlier?

It would seem that mirroring for backup would be awful here. Rather a whole lot of interval new info stored all the time.

So what are the mechanisms used?
 

Asher Kelman

OPF Owner/Editor-in-Chief
Don,

What are the methods that service providers use beyond filtering for illegal tidbits? For example do they have an array of queries at intervals to test the integrity of the system and then if something is wrong revert to a state at t-x seconds earlier?

It would seem that mirroring for backup would be awful here. Rather a whole lot of interval new info stored all the time.

So what are the mechanisms used?

Asher
 

Don Lashier

New member
Asher Kelman said:
So what are the mechanisms used?
Asher,

From what I've seen the methods are rather haphazard. Filtering for bad stuff doesn't work very well as illustrated by the myspace exploit - it's just too hard to know all the permutations, or some parts may not be constructed, and thus recognizable, til later and then it's too late.

A better practice is to only allow good stuff and discard everything else. Another good practice is to make sure that any embedded scripts aren't executable later when they're processed to create a page on the server. You not only have to worry about javascript but about the native script the page generator is using - eg PHP or Coldfusion. It really helps to centralize your form processing as this means that you can have common logic that applies systemwide.

When it comes to a Content Management System (CMS) like mine, a certain amount of trust has to enter the picture as in generally you want to allow users to embed javascript, or sometimes even PHP or CF, in their web pages, so then it becomes a TOS issue. But for publicly submitted stuff like events, any javascript entered will simply display as source, as does html when entered on most bulletin boards, avoiding the sanitization issue. The real key is the old KISS. The power and flexibility of javascript and DHTML entice too many people (programmers) to get cute, opening up all sorts of security holes in the process.

AFA recovery measures, I believe fairly normal practice is to backup the database daily but beyond that I'm not sure what sorts of general measures you could take. In any case, the loss is often loss of information (logins etc) and not damage to the DB per se.

ps: interesting article on the implications of the samy is my hero worm:
http://technology.guardian.co.uk/weekly/story/0,,1726234,00.html
(from list of news stories on Samy's own page)

btw, although in no way do I condone such exploits, I've got to admit that I'm tickled when a (presumably pimply) teenager snookers high paid programmers of a $600M site who smugly thought they had their security bases covered.

- DL
 
Last edited:

Cem_Usakligil

Well-known member
Hi All,

Thanks a lot for the interesting and valuable information provided, especially Don :).

My pragmatist's take on this (not being a real expert or anything on this topic matter) is that you can only be safe (and even then not entirely) if you run your own server (not a virtual/shared one) or if you hire a dedicated server somewhere else. The latter is quite expensive for an hobbyist like I, so I chose for the home server solution thanks to a stable and fast ADSL connection. The upload speed of 1Mbs is not much, but the traffic for my server is also quite low, so I don't care. I still keep my mail on a shared hosting server (one which is reliable in my experience) and use my home server as a fall-back just in case. I am aware that this does not answer your question in case you have high traffic volumes; dedicated hosting or co-located hosting are then the possibilities.

Once the server location has been decided upon, then there still is the question of which development platform to deploy: PHP, CF, ASP, Ruby (on Rails), AJAX, etc (this was the original topic starting question anyway). I am not sure whether we can provide a conclusive answer to this here. My guess is that all those platforms will be around for quite some time to come. In case you manage your own servers, you may decide to stick to the "proven" technology as long as you want. Whichever the platform is used, the security issue is best dealt with an approach as described by Don and Sean above:
- distrust anything, allow pre-cooked scripts very selectively
- create (if you can) your own scripts paying special attention to security issues
- keep software updated all the time
- use open source software which does not have any hidden backdoors somewhere
- use the tools you are most knowledgeable/comfortable with, do not switch too often since mistakes are more easily made at the beginning of the learning curve

Having written all this, pay special attention the risk analysis aspect. How valuable is your web site to you? What would happen if it was to be hacked by someone? Don has already provided some very good pointers in that direction. The answer will also dictate whether a self managed server is worth the hassle or not.

Cheers,

Cem

PS: edited due to a couple of typos
 

Dierk Haasis

pro member
Cem Usakligil said:
My pragmatical take on this (not being a real expert or anything on this topic matter) is that you can only be safe [...]

... when disconnecting yourself from the Net - in any conceivable way.
 

Cem_Usakligil

Well-known member
Dierk,

[..]disconnecting yourself from the Net[..]
I agree fully :).

BTW, I corrected my first sentence to read "pragmatist's" from the original "pragmatical" since the latter sounded too much like "Duglish" (Dutch-English) to me. You see, I am not a native speaker of either so I sometimes start doubting myself (LOL).

Cheers,

Cem
 
Cem Usakligil said:
My pragmatist's take on this (not being a real expert or anything on this topic matter) is that you can only be safe (and even then not entirely) if you run your own server (not a virtual/shared one) or if you hire a dedicated server somewhere else.
I disagree.

First, virtual dedicated servers have better protection than shared server environment as there are more levels of software to hack (security via complexity? ;) ). And with a decent company the top level OS/virtualization environment is administered by subject matter experts rather than amateurs (i.e., us).

With the shift to virtualization technologies "shared hosting" companies are starting to move to virtualized sharing of hosts. What this means is that you get a safe shared hosting professionally administered. Why I say this is the odds are (those damned statistics again ;) ) you nor I am likely to spend years studying OS level security and application level security to achieve what even a mediocre dedicated professional can achieve (note I did not say expert). Nor will have the extensive data (thousands or tens of thousands of servers) from a tool like snort to give us a serious heads up on trends. Although my 404 logs show many of them I do not have the time or interest to bother with them and instead watch for attacks on my databases solely. And truth be told I am moving to static sites precomputed on my box which is much faster than a shared host at computation and just serving files off a box with better network connectivity.

And since cheap shared hosting is about $40 US or less per year with adequate bandwidth and terrible CPU and database performance you can get a good experience from it.
Cem Usakligil said:
Once the server location has been decided upon, then there still is the question of which development platform to deploy: PHP, CF, ASP, Ruby (on Rails), AJAX, etc (this was the original topic starting question anyway).
Note that AJAX is a client side technology which can be supported by PHP, CF, ASP, Ruby, C++, ASP.net, Python, ...
- create (if you can) your own scripts paying special attention to security issues
[/quote]
Unless you know programming, using pre-cooked scripts and regularly updating them is likely to be the safest course.
Cem Usakligil said:
-use open source software which does not have any hidden backdoors somewhere
This is difficult unless you read the source. Take a look at this obfuscated perl and tell me at a glance it has no back doors. Then do this with hundreds of thousands of lines of code. Someplace, somewhere, and somehow one must trust in modern computing as there are too many layers of complexity for any single human to grasp them all. Even a simple 3 line Hello_World.c file requires the insane number of lines of code in the compiler to make it work without adding the complexity of the OS and device drivers. Do you understand how compilers truly work? I know I do not. I also know such knowledge would often hinder getting work done while worrying about irrelevant details that spending $50 more the CPU or RAM would solve. My point is that understanding exactly how a computer works is far beyond a single human. Heck, what if a backdoor involved a tiny CPU bug mixed with some assembly language optimizations in the compiler? Would you catch it? I would not even bother.

In short, there is not surety and trust must come into play at some point.

Regardless of that, caution is called for.
Cem Usakligil said:
- use the tools you are most knowledgeable/comfortable with, do not switch too often since mistakes are more easily made at the beginning of the learning curve
Sounds reasonable. But never forget tools and technologies can shift beneath your locale on the learning curve and mess you up too.
Cem Usakligil said:
Having written all this, pay special attention the risk analysis aspect. How valuable is your web site to you? What would happen if it was to be hacked by someone? Don has already provided some very good pointers in that direction. The answer will also dictate whether a self managed server is worth the hassle or not.

I would agree that risk analysis is of value. My choice is using a self managed server to generate static content. This mitigates a lot of risk as you then run the software in a trusted environment where hacking is not an issue.

my $0.02,
icon7.gif


Sean
 

Cem_Usakligil

Well-known member
Hi Sean,

1) While virtual servers are (theoretically) safer indeed, I have seen cases where a virtual server hosted by a hosting provided has gone berserk and caused severe performance problems for other virtual servers running on the same box, even crashes. I have been a victim of this and have moved hosting providers a few times before finding reliable ones who take good care of their of boxes as they should. Apart from that, I agree with your comments in that general area. Let hosting professionals do their jobs and let us do ours properly :).
2) If one uses ready made scripts, it is important to be able to see what's in it. I don't bother looking at obfuscated or large code myself, I just trust the open community on doing it on my behalf (just how stupid does this sound actually ;-)). I know that this is a weak argument, but open source is IMO better than closed source where you don't have any options to start with. Trust, in both cases, definitely comes into play.
3) Separating static (valuable) data and dynamic (less valuable) data is exactly what I had in mind when I decided to have a home server while still keeping a hosting account for other things as well. It all depends on the associated risk models and what you can afford to loose. Mind you, privacy is also an important aspect. I may have some safely backed up static data on a server which makes it affordable for me to loose it if the server ever crashes. However, I cannot afford having that data becoming public property.

Just my 2 Euro cents
img_6631_0_icon7.gif



Regards,

Cem
 

John_Nevill

New member
I do hope I didn't scaremonger with my post, but rather open people's eye's to what's happening, especially for those among us who may consider developing a personal website.

Don, looks like you have you bases covered. I couldn't agree more with your comments.

BTW, my old site was a phpBB/ nukephp/gallery hybrid and I had such tools as sentinel locking down most things. Although, as you rightly say, SQL injection is the main source of concern. So the unexpected plug pull was in effect on a out of the box solution provided bythe host provider

Ironically, I had quite a hard time trying to find a new host provider that would allow me to run the scripts which they were promoting as out of the box solutions. Furthemore most of the packaged installs which they provided (bulletins/cms/blogs) were out of date and added to the vunerability problem.

My advice is you get what you pay for, low cost hosts offer budget services, and given the option I would go dedicated rather than shared, Although in my instance, the cost differential is too great as I am reluctant to run advertising or charge people. I know, its not the best business model, but I do get something back through donations.
 
Sean DeMerchant said:
Do you understand how compilers truly work? I know I do not. I also know such knowledge would often hinder getting work done while worrying about irrelevant details that spending $50 more the CPU or RAM would solve. My point is that understanding exactly how a computer works is far beyond a single human.

My choice is using a self managed server to generate static content. This mitigates a lot of risk as you then run the software in a trusted environment where hacking is not an issue.

Understanding exactly how compilers work isn't all that difficult, relatively speaking. Neither is understanding how computers in general actually work until you get down to quantum mechanics.

For low-traffic web applications that are basically data jockeys (get data from database and show to user or get data from user, validate, and stick it in the database), you absolutely can throw hardware at the problem and not worry about it. For other types of programming, understanding how the compiler works is absolutely vital. For example, in a long-running inner loop, knowing if i++ is faster than ++i can be important.

But, (as I constantly have to remind myself when working in Perl) if you really cared about speed, you wouldn't be running an interpreted language to begin with.

Edited to add:

As someone mentioned, someone ripping out half of the capabilities of your language will break any application. If you go around randomly deleting class files, shlibs, DLLs, or whatever your language-specific equivalent is, things are going to blow up.

PHP is not going anywhere. It's free, it's got a massive install base, a huge number of applications use it, it's loosely-typed, which means it's easy for beginners (which is a double-edged sword, as a lot of open source projects end up being My First Program, and as such, are poorly written and insecure), and it's got a lot of useful stuff built into it. It's simply too useful to too many people.

To be reredundant, it's crucial to draw a distinction between insecure languages and insecure applications; it's possible to write an insecure application in any language. Some languages are invulnerable to certain types of attacks, for instance, you can't have a buffer overflow in languages like Perl and Lisp, but you can simply fail to validate your data in anything.
 

Asher Kelman

OPF Owner/Editor-in-Chief
Thanks Nicolai,

and O.T. in case his proficiency in software might fool you, he is an accomplished photographer with experience and fine work in pinhole photographic art.

We may, in fact, have a new forum on Pinhole Camera Photography. Also he is planning a resource page for us.

Thanks Nicolai for joining us and I hope everyone will get yo know you and enjoy your work!

Asher
 

Don Lashier

New member
John_Nevill said:
Don, looks like you have you bases covered. I couldn't agree more with your comments.
One should never assume that they have their bases covered - this could lead to AYBABTU :) In fact this thread prompted me to do a thorough test and I discovered that a recent change I made permits active javascript in a place where I formerly didn't permit. Fortunately this is only in a trusted environment currently, but I've got to fix this before going fully "web2" (allowing public input).

Cem Usakligil said:
I know that this is a weak argument, but open source is IMO better than closed source where you don't have any options to start with.
Open source is a two edged sword. The white hats can look at the logic and determine the holes, but it also makes it easier for the black hats to detect vulnerabilities and design exploits. Despite its dismissal, I benefit from "security by obscurity" since I write my own code, it's not widely distributed and hence presents a much smaller and less attractive target than widely deployed open source applications.
Cem Usakligil said:
I have seen cases where a virtual server hosted by a hosting provided has gone berserk and caused severe performance problems for other virtual servers running on the same box, even crashes.
It's very difficult to entirely protect one VS from another, and it's very easy to peg the CPU - I've done it several times myself accidently while developing, but fortunately I was in the next room from the server so could easily restart the service.

My own service uses not only a shared server (no VS), but a shared database which currently holds over 50,000 web page belonging to ~300 websites. This allows me to keep hosting costs very low compared to similar CMS hosting but also increases the possibility of collateral damage should a customer or the system misbehave. Fortunately in 10 years there have never been any serious issues. The only issue I've ever had was DOS attacks by Microsoft and that was easily solved by firewall rules. Microsoft clearly feels threatened by PHP and CF and stoops to their typical low-ball tactics - tg that Adobe bought CF and Adobe is too big (or too proud) to be bought by MS.

But again, most vulnerabilities arise when you permit public input - eg bulletin boards, blogs or galleries with feedback, etc., IOW web2. As long as the login is secure, simply using a CMS or page generator should not be much of an issue.

- DL
 
You're right, most vulnerabilites are from public input--but public input means any parameter passing whatsoever, not just prosaic text input. If you're passing a post ID to a blog, it's public input, and the system need not have commenting to be vulnerable.

Pegging the CPU is really easy: while(true) { pretty_much_anything(); }
 

Erik DeBill

New member
Don Lashier said:
One should never assume that they have their bases covered - this could lead to AYBABTU :) In fact this thread prompted me to do a thorough test and I discovered that a recent change I made permits active javascript in a place where I formerly didn't permit. Fortunately this is only in a trusted environment currently, but I've got to fix this before going fully "web2" (allowing public input).


Open source is a two edged sword. The white hats can look at the logic and determine the holes, but it also makes it easier for the black hats to detect vulnerabilities and design exploits. Despite its dismissal, I benefit from "security by obscurity" since I write my own code, it's not widely distributed and hence presents a much smaller and less attractive target than widely deployed open source applications.


There's actually a third layer to this. Closed source and open source solutions are both "off the shelf" solutions and hackers build libraries of exploits for them. One or the other may have fewer vulnerabilities, or a faster response time when one is reported, but both of them are great big targets.

The irony is that custom written code, while usually much more buggy and vulnerable, won't have the pre-written exploits against it. If people come after you specifically you're more likely to get burned, but if people are just looking for someone to hack they'll pass you by and go on to someone running something they already know about.

None of this has anything to do with PHP, except that there's an awful lot of standard PHP code out there written by people who either didn't think about security or didn't know what they were doing when they did. PHP itself does not encourage good programming practices (and even encourages some bad ones) so it's naturally that a lot of bad code uses it.

Likewise, MySQL is typically the first DB someone learns about. It's very simplistic and doesn't include a lot of the powerful features of other RDBMSs. Personally, I'm hesitant to hire someone if all their database experience is with MySQL. They probably haven't learned a lot of the very fundamental database best practices (MySQL used to actually preach against some of them in their documentation!)

Thus PHP + MySQL gets a bad reputation and places start forbidding people to use it. This is part of the life cycle of a programming language. Perl used to be the dominant scripting language on the web. Now it's PHP and Perl is hard to find. I'd bet that in a couple years some other language (Ruby?) will be the de facto standard.

None of this should really matter to the average photographer looking to have a web presence. Just pick some standard software that's widely used and then make sure you always stay up to date on patches. There's usually a security or announcement mailing list for any widely used piece of software. Sign up for it and read the emails. If so few people use it that there's not even an announcement list, then question whether you should use it. Check the archives of that list and make sure that there haven't been a lot of security problems in the past. When hackers first start checking something out, there will usually be a flurry of hacks over a period of 6 months or a year as they find all the bugs in a poorly written piece of software. You really don't want to start using something while that's going on.


Full disclosure: I don't like PHP as a programming language, and have avoided doing much with it.
 

Asher Kelman

OPF Owner/Editor-in-Chief
One issue of the updates is the issue of specific templates and whether or not they will migrate smoothly in a new update!

Asher
 

Don Lashier

New member
Erik DeBill said:
The irony is that custom written code, while usually much more buggy and vulnerable, won't have the pre-written exploits against it. If people come after you specifically you're more likely to get burned, but if people are just looking for someone to hack they'll pass you by and go on to someone running something they already know about.

Yes, security by obscurity - highly underrated.

Full disclosure: I don't like PHP as a programming language, and have avoided doing much with it.

I don't either, and I despite being a C programmer for decades, I don't like Java either, at least for web applications. For web applications both PHP and Java are "inside out" relative to ColdFusion. This is why Java finally evolved JSP and tag libraries - learned the lesson from CF. This is a much more intuitive, efficient (coding wise) and direct way of writing dynamic web pages. Interestingly some are suggesting that under Adobe, once dominant CF may return to dominance.

- DL
 

Erik DeBill

New member
Don Lashier said:
This is a much more intuitive, efficient (coding wise) and direct way of writing dynamic web pages. Interestingly some are suggesting that under Adobe, once dominant CF may return to dominance.

I'm not going to place any bets on a resurgence. I'm not aware of any language that's ever made a serious comeback after falling out of favor. Once you've lost it, you've lost it.

I'm sure whatever rises to dominance will use templates for web development. The only question in my mind is how much code will be embedded in them. It might have 0 code embeded (like TAL, from Python) or it might let you freely mingle code and HTML (like ASP, or HTML::Mason). My experience is that the more you embed, the harder to maintain. However, it makes it easier to dash off quick pages if the language doesn't enforce a separation. I'm betting on it letting you embed a lot of business logic.
 

Don Lashier

New member
Erik DeBill said:
I'm not aware of any language that's ever made a serious comeback after falling out of favor. Once you've lost it, you've lost it.
In terms of dominance, correct, but old languages never die - they just slowly fade. RoR is the current fad with PHP and Java fading somewhat.

I'm sure whatever rises to dominance will use templates for web development. The only question in my mind is how much code will be embedded in them. It might have 0 code embeded (like TAL, from Python) or it might let you freely mingle code and HTML (like ASP, or HTML::Mason). My experience is that the more you embed, the harder to maintain. However, it makes it easier to dash off quick pages if the language doesn't enforce a separation.
It was a noble thought to separate logic and presentation but in practice it's awkward and difficult. Every web app I've looked at freely mixes code and html, and this is where my comment about PHP being backwards comes in - as long as you're going to mix it's much more straightforward to embed the logic rather than the html - which is why I hate PHP.

I use templates, but it's just a small set of dynamic templates and the developer never has to touch them, but just specify the layout parameters in the database. This allows great flexibility - for instance, the other day one of the sites we host wanted to RSS feed their press releases so I created a new template, boom - two hours and it was done. Not only their request but now any set of the 50,000 pages from 300 sites we host can be RSS fed simply by adding an argument to the URL.

- DL
 

Erik DeBill

New member
Don Lashier said:
It was a noble thought to separate logic and presentation but in practice it's awkward and difficult. Every web app I've looked at freely mixes code and html, and this is where my comment about PHP being backwards comes in - as long as you're going to mix it's much more straightforward to embed the logic rather than the html - which is why I hate PHP.


I've actually been lucky enough to work on three different frameworks that separated logic from presentation. The current one is using Petal - no code can be embedded and all data must be passed in when the template is called. There are provisions for some very very simple control based on looping and boolean tests, but no way to actually manipulate data.

All of those frameworks have been much much easier to work on than the ones they replaced. Of course, the calling code still needs to know what data to send into a template, so there will always be coupling to some extent, but at least you can change page layout without worrying about accidentally borking your business logic.

If I can't keep the logic out altogether, I'll settle for embedding the logic in HTML. You have to watch out that people don't put huge amounts of code into the HTML, though, or it can start looking like a CGI script with here documents for occasional bits of HTML.
 

Don Lashier

New member
Erik DeBill said:
My experience is that the more you embed, the harder to maintain. However, it makes it easier to dash off quick pages if the language doesn't enforce a separation. I'm betting on it letting you embed a lot of business logic.

I'm afraid I was being a bit obtuse. I do separate business logic (which amounts to only shopping cart/checkout in my system) into separate code only modules, but I see no reason to separate presentation logic from the html. Doing this actually obsucates things imo.

- DL
 
Top