Hello ispcomm, (what's your real name ? ) I alredy fix the 2 issues above. Right now if the admin creates an order with an "active" status the site will be also active in ISPConfig. BUT, when a user buys a package the Order isn't sent to ISPConfig until he pays via paypal, then the order status will be change to "Active" and then the Order will be sent to ISpConfig. I also fix the invoices sent empty. Thanks!! I'm going to check you patch.
I have an issue with paypal payments too, but it's the same in THT and bnpanel, so I opened a thread on tht forum. The issue is that after payment is processed the order still stays in the "unpaid" state. This is off course confusing for the user. I have paypal sandbox accounts to test out. I will have a look at that part while waiting for your review of my patch because right now I have too many merge conflicts to resolve them by hand (talk about fast pace of development ) ispcomm.
I added your patch here: http://code.google.com/p/bnpanel/source/detail?r=40eaf78411b442bb0451d110d451ca837c59c5eb Any more patches are welcome. Thanks!
Great! I'm fighting with the paypal ipn right now. It seems that the class that is used tries to connect to the clear-text address of paypal. paypal redirects to the SSL version ... https://www.sandbox.paypal.com/cgi-bin/webscr Unfortunately the class is not able to understand this and leaves the order unpaid Ouch. Class is dated 2005. ispcomm
There's an updated class from the same author, dated year 2007. Url is http://www.micahcarrick.com/php-paypal-ipn-integration-class.html. However it does not fix the ssl issue. I guess a rewrite using curl is in order. Do you agree? ispcomm
Hello, The URL depends in a BNPanel configuration in Settings->Paid configuration -> Paypal Mode (live, sandbox), I do not understand what is the bug? I test it with a common Paypal account and it seems to work for me (in the sandbox) but I found a bug while dealing with Paypal bussiness accounts, it just not work.
Paypal is fixed now. I'm attaching a patch ( am I speaking to myself ? ) First... I've kept the patch to a minimum, but hell... that class is written badly. I don't like at all the paid module (will put it on a todo for the future).... a good security audit would be in order. Here's the patch (well... quite simple in reality): Code: diff -r f5987256b27e includes/class_invoice.php --- a/includes/class_invoice.php Thu Aug 26 14:42:16 2010 +0200 +++ b/includes/class_invoice.php Thu Aug 26 15:19:27 2010 +0000 @@ -811,4 +811,4 @@ $this->update($params); } } -} \ No newline at end of file +} diff -r f5987256b27e includes/paypal/paypal.class.php --- a/includes/paypal/paypal.class.php Thu Aug 26 14:42:16 2010 +0200 +++ b/includes/paypal/paypal.class.php Thu Aug 26 15:19:27 2010 +0000 @@ -151,8 +151,18 @@ } $post_string.="cmd=_notify-validate"; // append ipn command + if ( $url_parsed[scheme] == "https" ) { + $url_parsed[port]="443"; + $ssl="ssl://"; + } else { + $url_parsed[port]="80"; + $ssl = "" ; + } + // open the connection to paypal - $fp = fsockopen($url_parsed[host],"80",$err_num,$err_str,30); + // $fp = fsockopen($url_parsed[host],"443",$err_num,$err_str,30); + $fp=@fsockopen($ssl . $url_parsed[host],$url_parsed[port],$errnum,$errstr,30); + if(!$fp) { // could not open the connection. If loggin is on, the error message @@ -174,7 +184,7 @@ // loop through the response from the server and append to variable while(!feof($fp)) { $this->ipn_response .= fgets($fp, 1024); - } + } fclose($fp); // close connection Please test it when possible. ispcomm PS: There's some commented out lines for clarity of what was changed. You can delete them off course.
Well... I didn't debug enough. Could be my local problem with my setup, but I had 2 distinct problems: 1. The paypal "callback" is (was?) not working at my side because I was trying the panel behind a firewall with local IP address. The invoice class assumes that both the url and the notification url are the same. 2. The second problem (perhaps exposed by the first...) was that the call to the "paid" page returning from paypal tries to verify the order via IPN. The paypal class was connecting to port 80 using http. Paypal (sandbox) was redirecting me to port 443/ssl, which the paypal class simply ignored. It's just looking for the VERIFIED text in the response (ouch!). My patch fixes that: It uses the same URL as in the original POST to paypal. If it was "HTTP" it uses port 80 and http. If it was HTTPS it uses SSL to connect back to the IPN. This fixes the problem for me now, but I should really look if the notification part is working. ispcomm
Ok, I got it, I applied your patch and is working right now! Thanks! I'm sent your patch to trunk: http://code.google.com/p/bnpanel/source/detail?r=65facf44f38791caff09c50b5eba6623a1713bd7 btw that fix my problem with bussiness accounts...
Quota problem Here's another problem that I think I've hit. I'm not sure if it's a ispconfig or bnpanel or no problem at all (?): In brief: site quotas seem off. I created a package with 100MB in ispconfig. I ordered the package from BNPanel and paid with paypal sandbox. The client and site were created automagically on ispconfig (wow!). However, both hard disk quota and traffic quota for the site are set to 5MB. The client has the correct "package" assigned in ispconfig. question is: is this a todo item I han help with or just a bug to fix ? ispcomm.
This is nice! It seems paypal enforces SSL usage for business accounts. Please revert the "log file" that I enabled in the module. Lines 99/100 from http://code.google.com/p/bnpanel/so...t=side&path=/includes/paypal/paypal.class.php ispcomm.
The 5mb is created because is hardcoded in the servers/ispconfig.php BNPanel class. This is a todo issue but we don't have the time yet to resolve it! Some help will be welcome! What I proposed to do is to get the client_template information of ispconfig for that the selected package, then getting the hd_quota and traffic_quota and assign it to the new site. So you will have 100Mb instead of 5Mb
Solution forthcoming? Seems like this thread might be veering a bit off-topic..? In any case, to get back to sites_web_domain_add - I do not believe that it has been fixed in the latest SVN. The basic problem is that the domain id is not known to you before you call the sites_web_domain_add method - and that the sites_web_domain_add method requires you to fill in variables which assumes you have this knowledge for it to work properly. A chicken or the egg problem. I've made a (very) ugly hack to get this working so far which consists of finding the next auto increment value in the web_domain table. It works, but the problem is that I am guessing at what the next domain ID will be ... If another user creates a domain in the same split second this code is running, the ID might be wrong. So not a perfect solution. If someone is interested - here is the code: PHP: $tablename = "web_domain"; $next_increment = 0; $qShowStatus = "SHOW TABLE STATUS LIKE '$tablename'"; $qShowStatusResult = mysql_query($qShowStatus) or die ( "Query failed: " . mysql_error() . "<br/>" . $qShowStatus ); $row = mysql_fetch_assoc($qShowStatusResult); $next_increment = $row['Auto_increment']; $domain_id = $next_increment; //Now we need to generate doc root and apache basedir etc. as well... Nothing works without them //Document root $document_root = "/var/www/clients/client".$client_id."/web".$domain_id; //system user $system_user = "web".$domain_id; //system group $system_group = 'client'.$client_id; //This stuff comes from config usually in ISPCP - We don't want to do a hard include to their config so rather we generate it here $php_open_basedir="/var/www/clients/client".$client_id."/web".$domain_id."/web:/var/www/clients/client".$client_id."/web".$domain_id."/tmp:/var/www/".$input_domain."/web:/srv/www/".$input_domain."/web:/usr/share/php5:/tmp:/usr/share/phpmyadmin"; //Do the update $params = array( 'server_id' => 1, 'ip_address' => '*', 'domain' => $input_domain, 'type' => 'vhost', 'parent_domain_id' =>'', 'vhost_type' =>'name', 'hd_quota' =>'-1', 'traffic_quota' => '-1', 'cgi' =>'n', 'ssi' =>'n', 'suexec' =>'n', 'errordocs' =>'1', 'subdomain' =>'www', 'ssl' =>'n', 'php' =>'mod', 'active' => 'y', 'redirect_type' =>'', 'redirect_path' =>'', 'ssl_state' =>'', 'ssl_locality' =>'', 'ssl_organisation' =>'', 'ssl_organisation_unit' =>'', 'ssl_country' =>'', 'ssl_domain' =>'', 'ssl_request' =>'', 'ssl_cert' =>'', 'ssl_bundle' =>'', 'ssl_action' =>'', 'stats_password' =>'',//! //everything below will be ignored if you are not SOAP admin user - I used a hack before but after SVN update this works without haxxing 'document_root' => $document_root, 'system_user' =>$system_user, 'system_group' =>$system_group, 'allow_override' =>'All', 'php_open_basedir' => $php_open_basedir,//! 'apache_directives' =>'' ); Now - the ideal solution would be that you can just call sites_web_domain_add with empty values for sys user, group, doc root and open basedir and the method fills this in for you. As it should. Alternatively allow you to do a web_domain_update with the correct values and ISPConfig would then actually update everything on the server (doesn't seem like it does so now) As mentioned I have closely read the earlier posts that posit a solution here - but my tests show that they are flawed - It is of course possible that I am messing things up meself - but what I then would like is a more detailed explanation of how to take a virgin 3.0.2.2 installation and mod it with files from the SVN to get this working properly without my ugly hack... Thanks for an otherwise awesome remoting framework tho!
It has been fixed in SVN. All fields like the path of the website that need the ID are filled in by ISPConfig automatically, you have to leave the fileds empty in the remote function. The fix has been implemented by creating a plugin for the new action based plugin system in the interface and this plugin system is not present in 3.0.2.2, so you can not use the plugin in 3.0.2.2. You have to update to SVN or to 3.0.3 final when it gets released.
This was already fixed in ISPConfig SVN trunk! You don't need to generate the $php_open_basedir because this will be also overwritten by ISPConfig If you see. I created a plugin in SVN Commit 1922 and added a file here /interface/lib/plugins/sites_web_domain_plugin.inc.php Well it seems that Till wins me in my reponse ...
Nice! Oh alright - thanks a bunch! The thing was that the replies earlier in the thread were a bit vague and I had a tough time figuring out which files needed to be updated from the SVN to make things work. I guess my best course of action would be to do a complete update to the latest SVN - and then things should automagically work. I'm glad you guys fixed this - It was a bit of a showstopper. All other methods have worked flawlessly for me however, so you are close to having the ideal framework up and running Keep up the good work fellas!
Oh another thing - have you done any DB changes since 3.0.2.2 and the latest SVN? I was just wondering what the easiest way to update and maintain all my data on my server would be .... I was thinking I'd make a test where I had a virgin install with a couple of sites configured and then just update all the files from the SVN and see if it works. You could maybe save me some time by telling me whether a simple file replace with the files from the newest SVN will work - or if I will have to start from scratch and make a fresh install with the latest SVN. Mucho Gracias fellas!
That database layout has been changed from 3.0.2.2 to the current svn trunk. The ispconfig updater (ispconfig_update.sh command and then select svn as source) is able to deal with the layout changes as long as you have not added any custom tables or renamed fields in your ispconfig 3.0.2.2 database.
I agree. Perhaps we should open a thread for bnpanel specific issues and keep this for for integration of bnpanel+ispconfig. At least until a mailing list is set up for bnpanel development (btw: do google code support a mailing list?) ispcomm
Hello everyone, If you want to sent bugs/fixes/problems you can do it here: http://code.google.com/p/bnpanel/issues/list You need a gmail account to log in and create a issue.