Joomla! site syndication http://www.brettbrewer.com Fri, 18 May 2012 18:26:14 +0100 FeedCreator 1.7.2 http://www.brettbrewer.com/images/M_images/joomla_rss.png http://www.brettbrewer.com Joomla! site syndication http://www.brettbrewer.com/content/view/124/2/ I recently did a hasty implementation of PayPal ExpressCheckout for a client and while talking to a PayPal sales rep prior to the integration he directed me to x.com for documentation, but then couldn't explain exactly how it related to PayPal and the traditional PayPal developer site. I was left wondering whether to use the docs on x.com or the docs on the paypal developer site. Then today I was reading the JanRain technical blog looking for some info about their social sign-in API and stumbled across this line in a blurb about the Innovate Developer Conference (http://www.innovate-conference.com/). Now in its third year, Innovate has evolved quickly from a developer conference put on by eBay’s PayPal unit to a broader event featuring X.commerce, which unifies the commerce tools and technology platforms of eBay, PayPal, Magento, Milo and other eBay companies for developers and merchants.So now I know. News - Web Technology Mon, 26 Mar 2012 20:56:08 +0100 http://www.brettbrewer.com/content/view/123/45/ Ever been annoyed when your custom error handlers or exceptions don't catch fatal PHP errors and leave you with the dreaded white screen of death on your web pages instead of a useful stack trace? Me too. So I was happy to find this helpful article (http://insomanic.me.uk/post/229851073/php-trick-catching-fatal-errors-e-error-with-a) that shows a trick you can use to catch fatal errors such as out of memory errors. <?phpset_error_handler('myErrorHandler'); register_shutdown_function('fatalErrorShutdownHandler');function myErrorHandler($code, $message, $file, $line) function fatalErrorShutdownHandler() }?> You may also need to put this in your script to get fatal errors onto the error stack...<?phperror_reporting(0);?>Also keep in mind, if you have any other functions registered as shutdown functions and one of them throws an error, your custom fatalErrorShutdownHandler will not work. Tips & Tricks - PHP Tips Thu, 01 Dec 2011 13:39:38 +0100 http://www.brettbrewer.com/content/view/122/2/ Google finally annnounced Google+ support for Google Apps users (http://googleenterprise.blogspot.com/2011/10/google-is-now-available-with-google.html) . Now those of us that have been using google apps to host our email and other domain services can finally see what all the fuss is about. Previously, if you wanted to use Google+ you had to use a Gmail account, which for many Google Apps users like myself meant creating yet another gmail account just to use Google+. And since many of us tend to stay logged into Google under our Google Apps account, this meant that most of us have been ignoring Google+ entirely. This has been especially bad for the Google+ adoption since power users who host their own sites also tend to be the early adopters that new services like Google+ need. In fact, early reports on Google+ suggest that many users have tried it and then not returned and I suspect that some of that behavior was caused by early adopters who needed to create new accounts for Google+ access. Perhaps now the Google+ metrics will start improving as an influx of Google Apps users join the ranks. News - Web Technology Tue, 01 Nov 2011 18:55:14 +0100 http://www.brettbrewer.com/content/view/121/2/ I recently had the unpleasant experience of weathering a rather nasty distributed denial of service (DDoS) attack on one of the sites I manage. It's a high traffic site that does many tens of thousands of dollars of business each and every day. Downtime on the site costs a lot of money and makes us look really bad. Earlier this week we received a short, poorly worded email from an anonymous email address informing us that our site was under attack and demanding an unspecified ransom to cease the attack. The attack took the site down early Monday morning and I, along with a few other people, scrambled to find a solution, working with our dedicated server company and Akamai to block the deluge of traffic that had maxxed out the connections on our firewall. This particular type of attack is known as a SYN Flood Attack . It is very hard to defend against. We tried blocking IP addresses with our firewall and some POS software from Cisco called Cisco Guard which proved utterly useless. Akamai tried some other things that took hours to implement and also proved fruitless. In the end, both the dedicated server company and Akamai advised us there was little we could do other than wait it out . That was simply not an option. By late in the day, we had lost thousands in revenue, not to mention the sinking feeling of utter helplessness at the hands of some asshole hackers who we could not hope to track down or identify. We suspected they were in eastern Europe, possibly in Hungary, but that was about all we could deduce. We called the FBI and got a recording and a message about submitting an incident report on their web site. I called CERT's 1-800 number to see if they had any advice or knew who I could report this to and they nearly laughed at me when I told them I'd tried to call the FBI to report it. CERT also directed me to a web form where I could fill out a report, but advised me that most likely nothing would be done. Apparently the WWW in internet addresses really does stand for Wild Wild West . When it comes to dealing with a DDoS attack, you really are on your own. So what were we to do? Would we pay some unknown stranger an unspecified ransom? Would we wait another day and lose thousands more? Would we hire our own hackers to fight back? Finally as the day was quckly turning to evening and financial losses were piling up, we called one of our business associates who runs an even bigger and more prominent web site and told them what was happening to us and asked if they had any suggestions. They had two words for us..... Call Dosarrest.com , they said. We'd already done some research online looking for solutions and came across dosarrest's web site, but we were hesitant to try them at first. There were dozens of companies out there claiming to be experts in stopping DoS attacks. Some were big, some were small, some had proprietary hardware they would want to sell us to install at our datacenter, some were just services with no explanation of how they would help. But after the recommendation from our business associates, we decided to give dosarrest.com a call. Our associates assured us that when they had gone through a similar situation, they used dosarrest's services and though it wasn't particularly cheap, dosarrest got them back online within an hour or two. We had nothing to lose. Our mounting lost revenue had already cost us far more than dosarrest wanted to get us set up with their service. We made contact with dosarrest's sales rep who told us that depending on how quick we could make the required config changes to our site and DNS, they could have us back online within minutes or at most an hour or two. The sale rep wasn't joking. Within a few minutes of agreeing to the terms of their contract and making our initial paypal payment, their support team had sent us all the required configuration information, set up a proxy server to filter our traffic and were waiting on us to make the needed changes to our web server and dns config. Within the next hour we had completed the DNS and web server updates and our site was back in business. Throughout the process, I emailed their support with questions and had answers within minutes. When I called them, I was quickly connected to a tech-savvy support person who had all the answers I needed. Each time I have contacted them via email since, I have had a response within minutes. I think the longest response time from them was about 20 minutes for a non-emergency email, but usually it's much quicker. In fact, this evening, after several days of running with their service, I made a major update to the web site. About 100 files were changed and out of that 100 files I made 1 mistake in a config file that caused an endless redirect loop on the site. Because I had updated so many files at once, it took about 15 minutes to find my mistake and correct it. When I finished fixing the redirect problem, I checked my inbox to find an email already waiting from dosalert.com support informing me that they had detected that our site was down, had determined that it was not the result of an attack, had added some additional traffic filters as a precaution and were continuing to monitor the situation. It was not an automated message, it was from an actual support person who was actually on top of the situation. I immediately emailed them back to let them know the problem was caused by a stupid mistake on my part and to tell them how impressed I was that they were so diligent in monitoring our site. And then I sat down to write this post. I'm just not used to service this good. We pay a lot of money to our dedicated server company for 24/7 support and though they are often good, they don't come close to the level of service we've gotten from dosarrest so far. In fact, our web server company is supposed to be monitoring our server for downtime too, but I didn't get any messages from them tonight when I took our server down for 15 minutes. Dosarrest was on top of it within a few minutes. My only complaint with dosarrest is that they don't offer dedicated server hosting because I'd probably bite the bullet and go through all hassles to switch to them for that too. So, in summary, if you are dealing with a DDoS attack on your servers and don't know what to do, call dosarrest.com. Tell 'em Brett Brewer sent you. I won't say they are cheap, but I will say that if your business lives and dies by its web site, there is no substitute for the kind of service they provide. They are the real deal. News - Web Technology Thu, 23 Jun 2011 03:45:06 +0100 http://www.brettbrewer.com/content/view/120/45/ I've been getting cozy with Github lately and I thought I should share my experiences of getting a post-receive URL hook working so that when someone does a git push to my main development repository it will force my dev site to do a git pull to deploy all the latest changes from the repository to the staging server. In my case, I have a fairly secure development server running on a domain that has no public DNS records. This means that to view the site, someone must have the ip-hostname mapping in their computer's host file. This also means that Github has no way of finding the site to call any post-recieve url scripts to trigger the git pull on the remote site. What follows is a list of everything that needed to be done to make this work. First off, if you're using PHP like me, and your server has the slightest modicum of security, there's no way you're going to be able to successfully issue a shell_exec('git pull') command via php and have it work because php will only have the priviliges of your web server and chances are your repos and site files are owned by a different user. Enter a nice little apache module called suphp . I can't get into the details of how to prperly set up suphp because I had my dedicated server experts do that for me, but assuming you can get that set up so that your staging server serves your development site under the same user that owns the site files and git repos, you can then set up a php script that can successfully do a shell_exec('git pull') and have it work. So, assuming you got suphp set up, or you're running a really insecure setup that allows your webserver user to run shell commands, you can create a php script on your server such as this: <?php$payload = json_decode(stripslashes(@$_POST['payload']));$message = print_r(@$payload,true);$message .= shell_exec('/usr/bin/git pull');mail('me@mydomain.com','gihub post receive hook fired',$message);echo $message;exit;?> That was my first post-recieve URL hook script. I saved it on my staging domain's webroot folder and then in the Github admin for my repos, I just entered something like http://my.staging.server.com/Github.php. This worked great so long as my staging domain had a public dns record that allowed Github to find it, but for security reasons I didn't really want most people having access to the staging server, so I removed the public dns records and just added a hostfile mapping for my domain to my computers so I could browse it like it had a normal dns record. Of course, this broke the Github post-receive url hook. The first thing I thought to do was to ask Github support for a way to map my ip to my staging server in their system so I fired off an email to them to see if they would comply and then immediately thought of a rather simple solution. Github can't find a site with no DNS records, but it could easily find my server via its ip address. Since my staging server serves some other domains, I couldn't just give Github the server ip and expect it to find the right domain to call the script on, so I created a new apache config file to handle all requests that don't map to a specific server. For example if your staging server is on ip address 123.123.123.123, you could create an apache VirtualHost container such as this: <VirtualHost 123.123.123.123:80> ServerAdmin me@mydomain.com ServerName 123.123.123.123 ErrorLog /var/log/default.error CustomLog /var/log/default.access combined DocumentRoot /var/www/html #turn on suphp for this site suPHP_Engine on AddHandler x-httpd-php .php .php3 .php4 .php5 suPHP_AddHandler x-httpd-php</VirtualHost> This makes any requests to your main ip address look for files in the defaut apache docroot at /var/www/html. The suPHP_Engine directives force the requests for php files to be handled by suPHP so it uses whatever user you've got configured for suPHP. There are ways to get suPHP to use different users based on directive you put in the VirtualHost containers, but that's another story. We only needed one user so we've got suPHP configured to always use that user and restricted to only work in certain directories. Securing your system is up to you. So anyway, I threw my post-receive URL php script in /var/www/html and add some things to allow it to update the proper dev site.... <?php //put your own email address here if you want to receive email updates //when commits happen otherwise leave it blank or set it to false $email = gitadmin@mydomain.com ; //set $output_message to true if you want to be able to //view the output of the script in a browser $output_message = true; $message = Github script called on staging server<br/> ; //look for a request var named 'site'. This way you could theoretically //have the same script update different sites depending on the site //you pass in when you call the script. $site = isset($_GET['site'])?$_GET['site']:isset($_POST['site'])?$_POST['site']: ; if($site=='my.staging.domain.com')else if(!empty($email))if($output_message)exit; ?> Then for the post-recieve-url hook in Github I used something like this: http://123.123.123.123/?site=my.staging.domain.com There is an apparently undocumented feature in the Github post-receive-url hook that converts any $_GET vars passed in the url into $_POST vars, so in addition to the payload post var you will get any other vars you passed as $_GET vars in your $_POST array. I just included the check for a $_GET['site'] var in my script so that I can also call the script from a normal request in my browser. The above script obviously provides very little security, but since the domain I'm using it for has no public dns records, there's not much chance of someone stumbling across it without knowing the site's IP. Since the script restricts the git pull command to running only on the domains specified in the $_GET['site'] request var, the worst someone could do is update my staging server with the latest code in my repos if they called it with the right site in the request, which is sort of the whole point of the script anyway so that's not much of a worry. Having the script email me the results every time it runs keeps me informed of what is going on, so if anyone starts messing around with the script it will be hard to miss in my inbox. Now all is well in my Github world. Tips & Tricks - PHP Tips Tue, 24 May 2011 19:54:32 +0100