Not able to run phpGSB code

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Downloaded phpGSB Main Version – 0.1 (phpGSBV0.1.2.zip) 
2. Extract and kept directory inside doc root.
3. Created a database (GSBDB) and ran install.php. 
4. It created 12 tables in database.
5. Ran listupdater.php. It populated all tables.
6. Running lookup.php for test. 

What is the expected output? What do you see instead?
Expected: Should return TRUE for http://www.gumblar.cn and FALSE for 
http://www.google.com
ACTUAL: returning FALSE for both URLs.

What version of the product are you using? On what operating system?
Main Version – 0.1 (phpGSBV0.1.2.zip) 

Please provide any additional information below.
Also tried one more URL:http://malware.testing.google.test/testing/malware
FALSE is returned for this URL also.

Original issue reported on code.google.com by rahul.bi...@gmail.com on 27 Jul 2010 at 7:37

[GoogleCodeExporter]

You should have the listupdater.php on a cron running every minute. (It won't 
actually download updates every minute but is required to meet the 
documentation). You have to leave it after that basically overnight before 
it'll fully populate the database as it downloads updates in chunks. If you've 
tried this please let me know.

Original comment by sam%beav...@gtempaccount.com on 21 Aug 2010 at 12:10

• Changed state: Awaiting

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I tried the same... updated the list many times, but lookup.php still thinks 
that gumblar.cn is a safe page. Tried it with different malware site, always 
the same problem.

Has someone eventually a fix for this?

Original comment by jo...@crambl.com on 15 Oct 2010 at 9:40

[GoogleCodeExporter]

Original comment by sam%beav...@gtempaccount.com on 18 Nov 2010 at 4:04

• Changed state: Investigating

[GoogleCodeExporter]

Original comment by sam%beav...@gtempaccount.com on 18 Nov 2010 at 4:05

[GoogleCodeExporter]

Same issue here. 

I'm testing with the following URLs:
http://www.mozilla.com/firefox/its-a-trap.html
http://www.mozilla.com/firefox/its-an-attack.html

Both return FALSE.

Original comment by rjb1...@gmail.com on 13 Dec 2010 at 6:42

[GoogleCodeExporter]

Okay just a couple of questions:
1) Does it flag up gumblar.cn?
2) Have you got the updater on a cron (and left it running for more than 12 
hours?)

Original comment by sam%beav...@gtempaccount.com on 14 Dec 2010 at 6:49

[GoogleCodeExporter]

I initially did not have it running every minute in Cron. Specifically because 
as soon as you run one listupdater.php, the second time you run it Google asks 
you to wait 30 minutes. I have since enabled it to run every minute per your 
documentation.

At this point, running my test after waiting a few days I get results as 
follows:
var_dump($phpgsb->doLookup('http://www.google.com')); FALSE

var_dump($phpgsb->doLookup('http://www.mozilla.com/firefox/its-a-trap.html')); 
FALSE

var_dump($phpgsb->doLookup('http://www.mozilla.com/firefox/its-an-attack.html'))
; FALSE

var_dump($phpgsb->doLookup('http://www.gumblar.cn')); TRUE

So it now looks like it's sort of working - after waiting for a bunch of cron 
runs, the gumblar.cn is flagged, but the others are not.

Original comment by rjb1...@gmail.com on 15 Dec 2010 at 8:09

[GoogleCodeExporter]

Ahh that would be why. The updater takes this into account, it recognises this 
30 minute delay, however it must be set to every minute in case Google returns 
any errors etc (then the client runs again a few minutes later as per the 
backoff procedure).

The behaviour you are seeing is correct, the two mozilla URL's are hard-coded 
into Firefox (and may have been inserted into Phishtank etc) but are not in 
Google's database. 
For more information on this please see:
http://groups.google.com/group/google-safe-browsing-api/browse_thread/thread/6e6
e290d45d7bc4e/0319569664c8122e
Garrett on that thread is a Google developer.

If you require another test URL that will return a match then the following 
should give a (Phishing) match:
http://elspecmont.ru/photo/usrefundportal/allaccounts/zions/index.html 

Original comment by sam%beav...@gtempaccount.com on 15 Dec 2010 at 9:39

[GoogleCodeExporter]

Cool, in that case it's working for me. Thanks very much for the reply. The 1 
minute cron and waiting for it to populate definitely helped.

Original comment by rjb1...@gmail.com on 15 Dec 2010 at 10:00

[GoogleCodeExporter]

Status: Closed
Reason:
Many people seem to forget the 1 minute cron (which perhaps the lookup function 
could check for by checking the size of the tables). The 1 minute cron adds 
minimal overhead to the server as it doesn't actually "run" every minute, it 
only checks if its time to run according to the timeout procedures.

Original comment by sam%beav...@gtempaccount.com on 15 Dec 2010 at 10:04

• Changed state: WontFix