kiss-o-matic

Hi This is my first time trying to install a library w/ pecl. Just typing "pecl install v8js" did not work, as it's still apparently in beta. So, I changed it to install the beta. It compiles for a bit, then I get the following error. /tmp/v8js/v8js_convert.cc: In function 'v8::Handle<v8::Value> php_v8js_php_callback(const v8::Arguments&)': /tmp/v8js/v8js_convert.cc:44: error: 'tsrm_ls' was not declared in this scope /tmp/v8js/v8js_convert.cc: In function 'int v8js_to_zval(v8::Handle<v8::Value>, zval*, int, void***)': /tmp/v8js/v8js_convert.cc:572: error: cannot convert 'void***' to 'zval*' for argument '1' to 'int _array_init(zval*, uint)' make: *** [v8js_convert.lo] Error 1 Possible I'm missing some other type of prerequisite?

Hey Looks like I was doing some stuff before I included the connection to the database I needed. Anyway, all sorted. But, both of your suggestions are wise and I should take them into account. It's a pretty old site, and I was cutting my teeth on PHP. Lots of code to change. :?

Sorry if I'm incoherent... had a few whiskeys. The script executing this stuff would look like <?php require( inc_db.php ); require( inc_other_db.php ); require( funcs.php ); do_something( "user", "pass" ); ?>

Okay, some code broke. I was doing this, basically. inc_db.php <?php $link_db = mysql_connect('localhost','user','pass') or die('Could not connect: ' . mysql_error()); mysql_select_db('main_db') or die ('Could not select database'); ?> inc_other_db.php <?php $other_db = mysql_connect('localhost','user','pass') or die('Could not connect: ' . mysql_error()); mysql_select_db('other_db') or die ('Could not select database'); ?> funcs.php <?php function do_something( $a, $b ) { $query = "SELECT id FROM users WHERE a = '$a' AND b = '$b'"; $result = mysql_query( $query ) or die ( 'Query result failed: ' . mysql_error() ); // do something with result } ?> Caveat: One script pulls in inc_other_db.php *after* the inc_db.php so it uses that. New funcs.php <?php function do_something( $a, $b ) { global $linkdb; $query = "SELECT id FROM users WHERE a = '$a' AND b = '$b'"; $result = mysql_query( $query, $linkdb ) or die ( 'Query result failed: ' . mysql_error() ); // do something with result } ?> Runs, but mysql_query() always fails, and mysql_error() always returns a blank error. Any ideas? Something big changed in PHP5 that I'm totally missing? I'm getting jack in the PHP error logs. How can I print out some info about $linkdb in my function? I checked it with if ( !$linkdb) and isset(), and both seemed fine. Totally frustrated. Sleeping now.

Okay -- I'm comparing packets (again) and the magic is happening within <noscript> tags... or within <script> tags. One of the two. There are javascripts loaded (very,very convoluted ones) and there are alternatives within the <noscript> tags. I've yet to decipher what they do exactly. However, not being a JS pro, I'm not exactly sure what's going on. My headers & POST data match exactly, byte for byte. However, they could be storing something server side, denoting that I might not be human. Can something be set server side in a javascript? Also, is there an alternative to Curl that executes a javascript? I guess I should go through the script but it's a few thousand lines long. Cheers

I've done some digging. My CURL session is now sending byte for byte the same information as Firefox (according to HttpFox) and what looks like perfectly fine values. I believe the server is detecting Javascript either enabled or disabled from the first time I view the page. Is this possible? The flow, again is: 1: Slurp page (Cookie set here) 2: Read form 3: Follow form to login page 4: Login using that form (this requires said cookies, but the server isn't satisfied -- forces Captcha) I've been able to spoof the other side into thinking Javascript was off by deleting the cookie set in step 1. So, my assumption is that the magic all starts here, which seems very tricky to me. The page is loaded via a GET request, and I'm sending the exact same headers. There are some <noscript> tags in the page, but these couldn't have an effect on the cookie, could they? I'm not all up to date, but last I checked, they're sent in the headers (before the page contents).

Well, I can't modify the old one, and it turns out the topic (arguably the most important part for getting help) is misleading after I did some research. Alas, apologies...

Sorry, should have mentioned. 1) I tried that 2) In the browser, you're sending nothing (as it's within a <noscript> tag) and that's what I'm trying to emulate at the moment. I think I've tried just about every sane approach here. I'm just curious how they're detecting it's not a browser if I'm sending the same headers & post data. Frustrating.

Okay, starting a new thread as I can't modify the old one. I had some pretty stable code scraping a Yahoo site for a while but they've made a change and I can no longer log in. It's not telling me my password is incorrect, but it's forcing a human recognition page. The flow is: load page -> Detect login form -> login via that form -> Bob's your uncle. This all worked, but after I login, I get the human confirmation thing. After tinkering my entire Father's Day away, I have been able to replicate this in a browser (Firefox/Chrome) by doing the following: 1: Turning off Javascript 2: Going directly to the 3rd step above (login via that form) and removing some of the GET variables from the URL. Things of note: The following line is in the page, which I ignore. <noscript><input type="hidden" name=".nojs" value="1"></noscript> However, ignoring it is apparently not enough. Using HttpFox, I'm able to see what I'm sending. I've tried to perfectly emulate my Firefox browser. I'm sending the same headers AND POST data with only one exception: Content Size (which is automatic in CURL). Curl is always about 20 or so bytes smaller than what the browser says. That being said, I'm kind curious as to what it is. I'm not sure that that is the issue though. I'm following the form pretty much to a T. There are 3 variable values it sends that it uses for authentication, and that I appear to be handling right. On a successful login, about 5 cookies are written and the page is redirected. The anti-phishing page itself states to make sure java-script is enabled, and also to check your network settings. Is there anything else in CURL I might be missing? An SSL setting, as it does use secure login? I'm mainly looking for a brainstorm more than anything here, but if someone spots a glaring error, I'm all ears. Perhaps another way that it's detecting JavaScript is disabled. class CURL { var $callback = false; function CURL( $cookie = "" ) { if ( !strlen( $cookie ) ) { $this->cookie = "default_cookie.txt"; } else { $this->cookie = $cookie; } } function setCallback($func_name) { $this->callback = $func_name; } function doRequest($method, $url, $vars, $referer ) { $ch = curl_init(); $header[0] = "Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8"; $header[1] = "Accept-Language: en-us,en;q=0.5"; $header[2] = "Accept-Encoding: gzip, deflate"; $header[3] = "Accept-Charset: EUC-JP,utf-8;q=0.7,*;q=0.7"; $header[4] = "Keep-Alive: 115"; $header[5] = "Connection: keep-alive"; if ( $method == 'GET' ) { $header[7] = "Cache-Control: max-age=0"; } curl_setopt($ch, CURLOPT_VERBOSE, 1); if ( $referer != "" ) { curl_setopt($ch, CURLOPT_REFERER, $referer); } curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, 0); curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, 2); curl_setopt($ch, CURLOPT_ENCODING, "" ); curl_setopt($ch, CURLOPT_AUTOREFERER, TRUE ); curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, FALSE); curl_setopt($ch, CURLOPT_URL, $url); curl_setopt($ch, CURLOPT_FOLLOWLOCATION, 1); curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1); curl_setopt($ch, CURLOPT_TIMEOUT, 5); curl_setopt($ch, CURLOPT_USERAGENT, 'Mozilla/5.0 (X11; Linux x86_64;rv:2.0) Gecko/20110411 Firefox/4.0'); curl_setopt($ch, CURLOPT_HEADER, 1); curl_setopt($ch, CURLOPT_HTTPHEADER, $header ); curl_setopt($ch, CURLOPT_COOKIEJAR, $this->cookie); curl_setopt($ch, CURLOPT_COOKIEFILE, $this->cookie); if ( $method == 'POST' ) { curl_setopt($ch, CURLOPT_POST, 1); curl_setopt($ch, CURLOPT_POSTFIELDS, $vars); } $data = curl_exec($ch); $info = curl_getinfo( $ch ); curl_close($ch); if ($data) { if ($this->callback) { $callback = $this->callback; $this->callback = false; return call_user_func($callback, $data); } else { return $data; } } else { return "There was an error in getting page. Try refreshing your browser.<br>"; // return curl_error($ch); } } function get($url, $referer) { return $this->doRequest('GET', $url, 'NULL', $referer); } function post($url, $vars, $referer ) { return $this->doRequest('POST', $url, $vars, $referer); } }

I have found part of it. There's a <noscript> tag which is setting a hidden input tag. I've ignored it but haven't quite figured out the rest. On the trail though.

Okay, I'm kind of having an epiphany... the only way the remote server can detect if it's enabled or not is to actually have the browser/script execute some type of javascript and send a value back, right?

Howdy freaks, I've got a very simple issue. Some code has been running for a couple of years now relatively hassle free. The code uses a CURL wrapper to do the following: Slurp page->Login->Do something->Log out The login part is borked now, and I have traced it to a very simple, but nasty thing the remote side is doing: they check if Javascript is enabled in the browser (in this case, a PHP script) or not. If it's not, they are employing an anti-phishing human-confirmation thing. This is bad. I see nothing in the CURL documentation to set this, but I would assume it's possible somehow. Thanks

Hmmm... looks like it's actually ISO-2202-JP... which my system doesn't support. Gotta look into that.

Howdy. I'm trying to get UTF8 Encoded text out of an email from an imap server. I can read the mail, but the encoding seems to be jacked up. Hi I'm trying to get Japanese text out of an email from an imap server. PHP is somehow mangling it though. for ( $i = 1; $i <= $mails; $i++ ) { $struct = imap_fetchstructure( $imap, $i ); // $struct->encoding is 0 // The text is UTF8 $body1 = imap_utf8( imap_body( $imap, $i ) ); $body2 = imap_body( $imap, $i ); } In the above code, $body1 and $body2 are the same, and not any Japanese encoding. They're just garbage. Any ideas? My server is fastmail if that helps.

And we're back to square one: "The following From address failed". Hmm....

Err... okay, maybe the "from_failed" isn't the error-code from yahoo. O_o Now to get phpmailer's language file to load.

Hey guys I just moved, and I'm now forced to use Yahoo's SMTP service, and I can't get phpmailer to work. My phpMailer code works. I've gone through the steps of verifying my "from" email address at Yahoo (Plus). I've set up Yahoo's SMTP server in Thunderbird and tested it (works). Still no love w/ phpmailer. Here's the code just in case. I've tried "me@sender.com" as well as my main yahoo account which is also not working, which smells fishy to me. I always get the "from failed" error. I can't get the language to load either, but that's another issue. function pmail( $to, $from, $subject, $body, $charset = "iso-8859-1" ) { printf( "atempting to send mail to $to from $from\n" ); $mail = new PHPMailer(); $mail->SetLanguage( "en", "/path/to/phpmailer/language" ); $mail->setCharset( $charset ); $mail->IsSMTP(); $mail->Host = "plus.smtp.mail.yahoo.com:465"; $mail->SMTPAuth = true; $mail->SMTPSecure = "ssl"; $mail->Username = "myusername"; $mail->Password = "mypassword"; $mail->From = $from; $mail->FromName = $from; $mail->AddAddress( $to ); $mail->AddReplyTo( $from ); $mail->WordWrap = 50; $mail->IsHTML( true ); $mail->Subject = $subject; $mail->Body = $body; if( !$mail->Send() ) { print "problem w/ mail: " . $mail->ErrorInfo . " \n<br>"; return false; } return true; <?php pmail( "me@recipient.com", "me@sender.com", "This sucks", "Don't work", "EUC-JP" ); ?>

preg_quote() worked -- thanks!

Sry, I typed it wrong... it has the open delimiter. This is the error This is what I'm using as the pattern. $pattern = "/<form.+?action=\"(.+this.is.my.string.+)\".+/i"; I'll try preg_quote() in the morning.

Howdy. This still works, but I hate warnings: This works fine -- gets all matches and no warnings. $pattern = "<form.+?action=\"(.+this.is.my.string.+)\".+/i"; if ( preg_match( $pattern, $line, $matches ) ) { // blah } This produces the warnings, but makes the same matches. $string = "this.is.my.string"; $pattern = "<form.+?action=\"(.+$string.+)\".+/i"; if ( preg_match( $pattern, $line, $matches ) ) { // blah } I print the patterns out to make sure it's no weird typo. They are the same. Am I missing something?

Cheers, thanks. Checking the form, I left a zero out. The list of error codes will come in handy. Feel free to mark [sOLVED].

I had some working code, and somewhere along the way, it broke. Not sure where. Printing out the $_FILES['file'] array, I get the following when trying to upload an image: name => ,yjpg.jpg type => tmp_name => error => 2 size => 0 I don't know what error 2 is, but I assume that is the problem. The thing is, *SOME* jpgs will work, while others give this error. Any ideas?

Damn you Microsoft! And thank you kenrbnsn, I will give this a shot!

This is driving me nuts. I have an English client that will be putting in text copied and pasted from UK English (and other Euro) sources. They like to quote text ‘like this’. This is how I get rid of a normal apostrophe. $txt = preg_replace( "/\'/", "\\'", $txt ); The below snippet doesn't work. $txt = preg_replace( "/\‘/", "\\'", $txt ); $txt = preg_replace( "/\’/", "\\'", $txt ); In fact, preg_match doesn't catch these goofy guys (which aren't appart of ISO-8859-1 I see, but are used anyway). Usually I wouldn't care, but MySQL chokes on these. It doesn't treat it as a quotation mark, but it will stop inputting right then and there. The only text that makes it into the database is up to that point. Annoying, no?

Thanks. So Zend Guard basically makes executables out of your php scripts? I'm not so worried about people seeing the code, or the database structure. It's mainly the passwords. I md5() user's passwords, but not the passwords in the mysql table (the ones I'm worried about). I guess it's much more likely in this situation. If apache dies, you shouldn't be able to see *anything* on the box. Can Apache spontaneously lose PHP support? Perl obviously runs on it's own, so is far easier to break while leaving apache running fine. So, I guess when you think of it the odds are somewhat slim.