Search options (Page 7 of 8)

Unfortunately, this particular example probably won't increase safety much - lots of harvesters probably already decode %xx to chars before scanning for email addresses ... it's the simplest and most widely used hack, and it's only a few lines of code to decode all chars, before scanning the source for email addresses ... you must assume they're pretty dumb? I expect they'll put in at least a TINY bit more effort than that

For added safety, you have to make the source unreadable, which means you have to format the data, in the source, as something that can't be read directly out of the HTML source - what I did, for example, is a very simple solution, but will require the script to be parsed and executed ... probably the safest would be a technique similar to yours, but with some sort of added twist, for example XOR'ing all the values, or just adding one or subtracting two from each value - already then, the script would have to be parsed and executed to decode the result.

Mod posted!

I don't see how it could be confusing? The search feature as such won't change from the users point of view, at all - it'll simply function better, probably a lot more like the user would expect.

And there's no need to change any tables or alter the behavior of the code at all, the only change will be a couple of calls to the stemmer here and there.

I'll post a mod.

I'd say about 90% of them are. But it's probably not a big deal as you're using Hotmail, I hear it has really good spam filtering

So you're still considering it, but nothing can affect your decision - yeah, that makes sense

well, we've been using the JavaScript cloak on this site for nearly three years now, and I have received very little spam on my email address which is shown there; sometimes maybe 1-2 mails per week or so, which is very good by today's standard, and I'm pretty sure these came from other sites where my email address might have been displayed. We do not use any kind of spam filtering on our server. I get as many virus mails as the next guy of course, but this will happen regardless, as anyone with your email address in their address book who gets hit by a virus, will start distributing your email address to other hosts and infect those etc., but that's another discussion really.

you and I are smart enough to know that this is the only way to be truly safe, but most people are not - so the question is, do we care about those less fortunate people, or is "their own damn fault"? I am passionately against spam, and anything I can do to screw things up for the spammers, I am happy to do

easy to find, but certainly not easy to run - I doubt if any of them will really make their own JavaScript parser just to get those few extra email addresses ... there are MASSES of completely unprotected pages from which they can rip billions of email addresses daily; a few hundred or even a few thousand email addresses won't make any difference to these people.

even if they did care enough to do it, I doubt they'd be able to do it in the first place - a JavaScript parser is not simple ... bear in mind, in order to get the email address, you have to not just parse, but actually execute the JavaScript, and if they did that, they'd also be running tons of other scripts; and there would be loads of other stuff they'd have to take into account then, like stopping popups, emulating the browser object and the entire DOM to keep scripted menus and effects from breaking the execution, etc.

still true, but still not an excuse to sit back and not do anything about the problem - quite the contrary ... and if the only other option is to not allow people to show their email addresses at all, then I'd rather take the second-best option and at least leave them with a choice.

Chacmool,

You've saved me loads of time by writing this converter, thank you very much!

Here's my contribution ...

The converter was only doing a half-perfect job of converting the message contents in posts - you seem to have overlooked the fact that carriage return and linefeed in MiniBB posts don't mean anything? In PunBB they do - thus, you must first discard any carriage returns and linefeeds before you convert <br> to linefeed, otherwise you get excess whitespace in some messages. The font color tag was not handled. After converting everything possible, I would strip and wipe any excess HTML at the end - this should maybe be optional, for those who allowed HTML in their posts when they were running MiniBB. And finally, for those using "hack_smilies.php" with MiniBB (I was), I made a little conversion function, which will detect smilie images and translate them back to ordinary smilies for PunBB to display.

Here's the modified "functions.php":

<?
    function generatedtime($start, $finish){
        list( $start1, $start2 ) = explode( ' ', $start );
        list( $finish1, $finish2 ) = explode( ' ', $finish );
        return sprintf( "%.2f", ($finish1 + $finish2) - ($start1 + $start2) );
    } // end function generatedtime

    function html_stuff($message){
        $pattern = array(
            '/>/i',
            '/</i',
            '/&/i',
            '/"/i',
            '/'/i'
        );

        $replace = array(
            '>',
            '<',
            '&',
            '"',
            "'"
        );
        
        return addslashes(preg_replace($pattern, $replace, $message));
    }

    function convert_smilies($message) {
        $smilie_path = '/img/emos/'; // images in this folder will be converted to smilies - this path must including trailing and leading slashes, and may be partial (e.g. you can specify simply "/images/smilies/" instead of "http://www.mysite.com/myforum/images/smilies/")
        
        // map of which GIFs to convert to what smilies:
        $smilie_map = array(
            'grin.gif'     =>  ":)",
            'sad.gif'      =>  ":(",
            'shock.gif'    =>  ":o",
            'lol.gif'      =>  ":D",
            'wink.gif'     =>  ";)",
            'tongue.gif'   =>  ":p",
            'biglol.gif'   =>  ":biglol:",
            'confused.gif' =>  ":confused:",
            'grin.gif'     =>  ":grin:",
            'mad.gif'      =>  ":mad:",
            'sad.gif'      =>  ":sad:",
            'wink.gif'     =>  ":wink:",
            'sad.gif'      =>  ":cry:",
            'lol.gif'      =>  ":lol:",
            'cool.gif'     =>  ":cool:",
            'hihi.gif'     =>  ":hihi:",
            'biglol.gif'   =>  ":rofl:",
            'tongue.gif'   =>  ":tongue:",
            'shame.gif'    =>  ":shame:",
            'shock.gif'    =>  ":eek:",
            'rolleyes.gif' =>  ":rolleyes:",
            'idea.gif'     =>  ":idea:",
            'neutral.gif'  =>  ":|"
        );
        
        $smilie_path = preg_replace('/\//i', '\\\/', $smilie_path); // escape slashes
        
        foreach($smilie_map as $img => $smilie)
        {
            $img = preg_replace('/\./i', '\\\.', $img); // escape dots
            $message = preg_replace('/\[img\][^\[]*'.$smilie_path.$img.'\[\/img\]/im', $smilie, $message);
        }
        
        return($message);
    }

    function convert_posts($message){
        $pattern = array(
            // returns and linefeeds
            '/\r/i',
            '/\n/i',
            
            // <br>
            '/<br>/im',
            
            // bold, italic, underline
            '/<b>/i', '/<\/b>/i',
            '/<i>/i', '/<\/i>/i',
            '/<u>/i', '/<\/u>/i',

            // Mail
            '/<a href="mailto:([^"]+)">([^<]+)<\/a>/im',

            // URLs
            '/<a href="http:([^"]+)"(?:[^>]*)>([^<]+)<\/a>/im',
            
            // Images
            '/<img src="([^"]+)"(?:[^>]*)>/im',
            
            // Font color
            '/<font color="(#[0-9,a-f,A-F]{6})">([^<]*)<\/font>/im',
            
            // Illegal HTML
            '/<[^>]*>/'
        );
        
        $replace = array(
            // returns and linefeeds
             '',
             '',
             
             // <br>
             "\n",
             
            // bold, italic, underline
            '[b]', '[/b]',
            '[i]', '[/i]',
            '[u]', '[/u]',
            
            // Mail
            '[email=$1]$2[/email]',
            
            // URLs
            '[url=http:$1]$2[/url]',
            
            // Images
            '[img]$1[/img]',
            
            // Font color
            '[color=$1]$2[/color]',
            
            // Illegal HTML
            ''
        );

        return html_stuff(convert_smilies(preg_replace($pattern, $replace, $message)));
    }
?>

I only added convert_smilies() and modified the two arrays in convert_posts(), so if you already made other changes (mine is based on beta 3), you can simply copy/paste those.

Woot

in that case, you'll be arguing against everyone who's ever implemented a search engine before you

think about it: if I'm searching for "PunBB", and an important post doesn't turn up in my results because the post said "PunBB's nice features" somewhere in it, and the word was indexed as "PunBBs". This is one of the first problems with developing a search engine.

"More accurate" is not simply the same as "Less results" - in many cases, leaving out results because people use a different form of a word (singular/plural etc.) gives you less accurate results. The technical aspects of searching are one thing, but you have to consider that searching is a human activity - we're not machines, and we do not want to have to learn how to write RegEx expressions or even simple wildcards, before we can get down to business - the computer has to do the dirty work for us, that's what it's there for ... Leaving out results because people fail to spell correctly is another cause for inaccurate results, which is why phonetic searching was invented. These (and many other) are the reasons why modern search engines like Google are so effective...

okay, so then you'll spend HD space and bandwidth on thousands of GIFs instead.

if something like this is implemented, it has to be optional, and IMO shouldn't be switched on by default.

just add a function to functions.php, encode_email(email) or so, and reuse that. If there's a simple call to that function in one or two other places in the source code, that should hardly cripple the readability