Δεν το κρύβω ότι η όλη σχέση μου με το captcha είναι σχέση μίσους. Θεωρώ την όλη διαδικασία στησίματος του σε μια φόρμα, δύσκολη, δύσχρηστη και στις περισσότερες περιπτώσεις αρνητική ως προς το εικαστικό αποτέλεσμα.

Από την άλλη το θέμα των spam messages μέσω forms, παραμένει και μάλιστα εδώ και ένα σεβαστό χρονικό διάστημα έχει ήδη ξεπεράσει τον έλεγχο που προσφέρει το captcha.

Προφανώς, την ίδια σκέψη με μένα όσον αφορά τα μειονεκτήματα του captcha έχουν κι άλλοι, γι΄αυτό βλέπω σε πολλές φόρμες, ο έλεγχος να γίνεται μέσω «λογικών ερωτήσεων» που είναι σε θέση να απαντήσει ένας άνθρωπος αλλά όχι ένα bot : 2 + 2 =, snow is hot or cold ? κλπ.

Η λύση που χρησιμοποιώ, και μέχρι στιγμής δουλεύει με 100% επιτυχία εστιάζεται καθαρά σε css. Η «πατέντα» δεν είναι δική μου, διάβασα την μεθοδολογία σε κάποιο blog που δυστυχώς δεν θυμάμαι, αποφάσισα να την χρησιμοποιήσω και δεν το έχω μετανιώσει.

Λειτουργεί απλά, γρήγορα και δεν επιφέρει κανένα μειονέκτημα στο εικαστικό αποτέλεσμα της φόρμας, ούτε ενδεχομένως μπερδεύει τον χρήστη με «λογικές ερωτήσεις».

Σε μια τυπική φόρμα με τα πεδία της, προσθέτουμε ανάμεσα τους άλλο ένα πεδίο. Ας του δώσουμε το όνομα «hfield»

<input name=»hfield» type=»text» />

H εμφάνιση της φόρμας μετά την προσθήκη του πεδίου :

Στο css file που χρησιμοποιούμε προσθέτουμε το class :

.nodisplay {display:none;}

το οποίο εν συνεχεία εφαρμόζουμε στο πεδίο hfield το οποίο διαμορφώνετε ως εξής :

<input class=»nodisplay» name=»hfield» type=»text» />

με την εφαρμογή του class στο πεδίο, η εμφάνιση της φόρμας αλλάζει και το πεδίο πλέον δεν εμφανίζεται :

Ετσι επιτυγχάνουμε τα εξής απλά : ο χρήστης δεν βλέπει κάποιο πεδίο που να τον μπερδεύει, ενώ το spam bot που θα περάσει θα «δει″ το κρυμμένο πεδίο και θα προσπαθήσει να το συμπληρώσει.

Από εκεί και πέρα εύκολα μπορούμε να ελέγξουμε κατά την αποστολή της φόρμας αν το πεδίο hfield είναι κενό ή όχι. Αν είναι κενό επιτρέπουμε στην φόρμα να αποσταλεί. Αν δεν είναι, μπλοκάρουμε τον spammer. Ας πούμε, με javascript :

if (document.myform.hfield.value != «»)  {
alert («δεν επιτρέπονται spam messages»);
return false;  }

Χρησιμοποιώ την συγκεκριμένη μέθοδο παντού με απόλυτη επιτυχία μέχρι στιγμής, χωρίς να τροποποιώ την εμφάνιση, ούτε να παιδεύομαι με captcha τεχνικές αμφιβόλου αξιοπιστίας.

Επειδή με παίδεψε, και επειδή θεωρώ ότι είναι χρήσιμο για ενσωμάτωση σε CMS που παραδίδονται στον πελάτη ώστε να κάνει μόνος του τα update του web site.

Σενάριο
Θέλουμε να αποθηκεύουμε σε μια βάση δεδομένων MySQL, το όνομα αρχείου μιας φωτογραφίας που θα συνοδεύει την εκάστοτε εμφάνιση του record.

Τρόπος Επιλογής Φωτογραφίας
Έχουμε ανεβάσει τις φωτογραφίες (μέσω FTP ή μέσω ενός upload script) στο folder του server.

Με PHP εμφανίζουμε τα ονόματα των αρχείων από το συγκεκριμένο folder, και με την επιλογή κάποιου αρχείου, εμφανίζεται η φωτογραφία με χρήση javascript.

<select name=»photo» onChange=»previewPic(this)»>
<?php
if ($handle = opendir(‘photos/’)) {
while (false !== ($file = readdir($handle))) {
if ($file != «.» && $file != «..») { ?>
<option value=»<? echo $file ?>»><? echo $file ?></option>
<?
}
}
closedir($handle);
}
?>
</select>

Πριν κάνουμε αυτό έχουμε φροντίσει να περάσουμε όλες τις φωτογραφίες του folder σε ένα javascript function ώστε να γίνεται το preview.

<script language=»JavaScript»>
function previewPic(sel) {
document.previewpic.src=»photos/» + sel.options[sel.selectedIndex].value;
}
function showPic(sel) {
images = new Array();
<?php
if ($handle = opendir(‘photos/’)) {
while (false !== ($file = readdir($handle))) {
if ($file != «.» && $file != «..») { ?>
images[1] = «<? echo $file ?>»;
window.location.href = images[sel.selectedIndex+1];
<?
}
}
closedir($handle);
}
?>
}
</script>

Προσπαθούσαμε από καιρό να βρούμε μια λύση, μέσω της οποίας ο χρήστης που θα ήθελε να πειραματιστεί με το Ruby δεν θα είχε την δύσκολη αποστολή να σετάρει την εφαρμογή του μέσω SSH.

Για τους γνώστες βέβαια, η πρόσβαση SSH απαιτείται, σε εμάς όμως τουλάχιστον, όσοι επέδειξαν ενδιαφέρον για ενεργοποίηση hosting με rails support είχαν κυρίως την διάθεση να πειραματιστούν και η όποια προσπάθεια να στήσουν την εφαρμογή τους μέσω jailed SSH ήταν χρονοβόρα, κουραστική και γεμάτη ερωτήσεις εκατέρωθεν.

Ακολουθεί ένας οδηγός, πως μπορούν να στήσουν την Ruby On Rails εφαρμογή τους με Mongrel instance, καθώς και πως να την διαχειριστούν. Παραλείπω το κομμάτι της εγκατάστασης του Ruby On Rails και του Gems στον server, καθώς και την εμφάνιση των σχετικών icons στο περιβάλλον του Cpanel, καθώς είναι θέμα που προφανώς δεν απασχολεί τον τελικό χρήστη αλλά και πολύ απλή διαδικασία αν φυσικά υπάρχει το cpanel 11.

- Κάνουμε login στο Cpanel

- Πάμε στο tab «Software / Services» και κάνουμε κλικ στο icon Ruby On Rails

- Εμφανίζεται η ακόλουθη οθόνη, όπου δημιουργούμε το Ruby on Rails / Mongrel Instance. Συμπληρώνοντας την φόρμα, το cpanel δημιουργεί όλο το skeleton των αρχείων και σετάρει το Mongrel.

οι παραπάνω ρυθμίσεις εν ολίγοις σημαίνουν ότι βγάζουμε την Ruby εφαρμογή εκτός του public_html και ότι θα ενεργοποιήσουμε το Mongrel instance σε production environment.

- Kάνουμε upload την Ruby on Rails εφαρμογή μας μέσω FTP, ορίζουμε τις πληροφορίες της database και κάνουμε το migration (rake db:migrate).

- Πριν δούμε αν η εφαρμογή τρέχει σωστά, πρέπει να ενεργοποιήσουμε το Mongrel Instance και πάλι από το περιβάλλον του cpanel. Απλά στην ακόλουθη οθόνη, πατάμε το πράσινο icon (Run) και κάνουμε click στο link για να δούμε πως αποκρίνεται η εφαρμογή μας μέσω temporary url.

- Όταν έχουμε ολοκληρώσει την εφαρμογή, πρέπει να κάνουμε redirect το site στον κατάλογο rails_sites. Εύκολα και απλά κάνοντας click στο button «Create Rewrite» και πάλι από το περιβάλλον του cpanel

*** πριν ξεκινήσουμε και εφ’όσον ο hosting provider που είμαστε παρέχει την δυνατότητα σεταρίσματος της ruby εφαρμογής μέσω cpanel, θα πρέπει να ελέγξουμε αν τα modules που προαναφέρονται (mongrel, rake) είναι εγκατεστημένα και άρα μπορούμε να τα χρησιμοποιήσουμε στις ruby εφαρμογές μας.

Τρία χρόνια μετά την εμφάνιση της PHP5, καιρός ήταν.

Aπό το php.net :

[13-Jul-2007]

Today it is exactly three years ago since PHP 5 has been released. In those three years it has seen many improvements over PHP 4. PHP 5 is fast, stable & production-ready and as PHP 6 is on the way, PHP 4 will be discontinued.

The PHP development team hereby announces that support for PHP 4 will continue until the end of this year only. After 2007-12-31 there will be no more releases of PHP 4.4. We will continue to make critical security fixes available on a case-by-case basis until 2008-08-08. Please use the rest of this year to make your application suitable to run on PHP 5.

For documentation on migration for PHP 4 to PHP 5, we would like to point you to our migration guide. There is additional information available in the PHP 5.0 to PHP 5.1 and PHP 5.1 to PHP 5.2 migration guides as well.