L3Y

Hi Tyson, Seems like this return another array. I am looking to only display only the tld name and price. Is there any better way? Here is what i am getting now. Array ( [0] => stdClass Object ( [id] => 1903 [pricing_id] => 1903 [package_id] => 165 [term] => 1 [period] => year [price] => 23.4000 [setup_fee] => 0.0000 [cancel_fee] => 0.0000 [currency] => CAD ) [1] => stdClass Object ( [id] => 1904 [pricing_id] => 1904 [package_id] => 165 [term] => 2 [period] => year [price] => 46.8000 [setup_fee] => 0.0000 [cancel_fee] => 0.0000 [currency] => CAD )

Hi André, It's better if you can build your own set of rules, with Naxsi. You may want to check on this tutorial : https://blog.stickleback.dk/compiling-nginx-with-naxsi-on-ubuntu-14-04-lts/ There was a method to generate quick rules with the Learning Mode. You may want to take a look at my reply here : http://www.blesta.com/forums/index.php?/topic/1338-blesta-naxsi/ ...but please be aware this automated method is now deprecated. ...it may still help though. Cheers

I also think the same... ...or maybe one of the well know plugin dev's will know? Here is my current loop : foreach ($response as $item) { foreach ($item->pricing as $pricing) { var_dump($pricing->price); } }

Good question I also wanted an answer on this. Then i found this where Tyson explain how it work : http://www.blesta.com/forums/index.php?/topic/2962-api-users-login/ Hope that help

Hi, Thank you for trying to help on this, but i am able to fetch the info from the api. I just can't loop through the response. Here is my code : $api = new Api($url, $user, $key); $model = "packages"; $method = "getAllPackagesByGroup"; $params = array('package_group_id'=>'2'); $response = $api->get($model, $method, $params); The api response (sorry about the formatting) : Array ( [0] => stdClass Object ( [id] => 965 [id_format] => {num} [id_value] => 413 [module_id] => 3 [name] => .biz [description] => .biz [description_html] => .biz [qty] => [module_row] => 2 [module_group] => [taxable] => 1 [single_term] => 0 [status] => active [company_id] => 1 [prorata_day] => [prorata_cutoff] => [id_code] => 413 [module_name] => Namecheap [pricing] => Array ( [0] => stdClass Object ( [id] => 1903 [pricing_id] => 1903 [package_id] => 165 [term] => 1 [period] => year [price] => 23.4000 [setup_fee] => 0.0000 [cancel_fee] => 0.0000 [currency] => CAD ) [1] => stdClass Object ( [id] => 1904 [pricing_id] => 1904 [package_id] => 165 [term] => 2 [period] => year [price] => 46.8000 [setup_fee] => 0.0000 [cancel_fee] => 0.0000 [currency] => CAD ) Here is what i tried : foreach ($response as $item) { foreach ($item->pricing as $pricing) { var_dump($pricing->price); } } I've also tried : $i = 1; $response->pricing[$i]->price; And i've also tried : foreach($response as $resp) { foreach($resp->pricing as $key=>$pricing ) { echo $pricing[$key]->price."<br>"; } } .

Hi, I'm able to fetch the info from the api, and return the BlestaResponse Object. However, i am having a hard time trying to loop through what's the API replied. Here is my code : $api = new Api($url, $user, $key); $model = "packages"; $method = "getAllPackagesByGroup"; $params = array('package_group_id'=>'2'); $response = $api->get($model, $method, $params); Here is what i tried : the following returned an error : "Cannot use object of type STDClass as array" foreach ($response as $item) { foreach ($item->pricing as $pricing) { var_dump($pricing->price); } } I've also tried : $i = 1; $response->pricing[$i]->price; And i've also tried : foreach($response as $resp) { foreach($resp->pricing as $key=>$pricing ) { echo $pricing[$key]->price."<br>"; } } ...but nothing is working and my third attemp to loop returned only a blank page with no errors in the logs. All i want is to display the price per year in a table.

Ok. Here is how. The model is packages, the method get, and the parameter is package_id. The api is easy to use... ...once you get familiar with it First create a product group with all your domains. Then, fetch the products lists to return all the infos (including the pricing). Example : $response = $api->get(packages, getAllPackagesByGroup, package_group_id'=>100);

Hi, As per ICANN recent policy changes we must list all our domain prices on our website. I am trying to fetch a list of our tld through the external API, and return the price + the tld. I am wondering what is the best way to do this using the current available methods. Someone can point me to the right direction? Thank you, Carl

Hi, It would be easier to change if the variables were not changed. I would much prefer to do a search and replace for {{ in the db (that's the original values of the library Blesta is using i think... ) Thank you to confirm there won't be any issue doing this. Cheers! Carl

Hi, What's the best way to list only domains in Blesta? What i want is separate the domains and the other services in the client area. Thank you, Carl

Hi, What are the required privileges to run blesta with mysql if i do not want to grant all privileges on the db? The ones i was using were working fine, until i upgraded to the latest version of the database server : then i got a blank page everywhere in Blesta until i temporary granted all privileges on the db. I must be missing something. Thank you, Carl Edit : seems like if i switch them back to the original ones, it's working now. I am going to read a little on this upgrade I'll leave this open, just curious to see if my privileges are correct or not.

Hi, I would like to change this parameter, in /config/blesta.php Configure::set("Blesta.parser_options", array( 'VARIABLE_START' => '{', 'VARIABLE_END' => '}', )); but just before those lines, it say : // Sets parser options DO NOT MODIFY Why the "do not modify" exactly? Is it a bad thing for any reason i can be missing to change this setting? ...cause this change seems pretty much straight forward, if you also update the variables in the db. I see it seems to be working fine on a test install if i change the old tags everywhere. It don't seems to cause any problems. Thank you for clarifying this for me Cheers! Carl

Hi, It seems like the passwords of the support departments are not encrypted with the hashkey in the database. See the field : <input type="password" name="pass" id="pass" value=""> at : /plugin/support_manager/admin_departments/edit/ Possible for Blesta dev's to check on this? I don't see why all other infos should be encrypted, while those very important passwords are not. That's important imho Cheers and keep up the good work! Carl

Hi, The integrated support manager in Blesta is very nice. BUT : if you enable the plugin, then you need to disable many mod_security / naxsi rules just to be able to post a couple of lines in a ticket. Customers want to send very long codes, and you may ask them to send stuff like email sources, debug codes, etc... It can take a lot of time and efforts before you get a stable and secure set of mod_security / naxsi rules. We all know blesta is very secure, but it's always better to use an application firewall, like mod_security or naxsi. However, doing this can turn into a nightmare. While trying to submit codes, or any other content with special characters, your customers may see 503 error codes. That's not beautiful Some peoples may end up by doing stupid things like completely disabling mod_security while they should not. Other peoples will simply start disabling everything they see in the logs. They may disable too many rules, or whitelist too many ip's. I found a very good way to avoid 503 errors, while keeping most of your naxsi / mod_security rules intact. With theses little changes in your files, your customers will be able to copy/paste and type everything they want in a ticket textfield or subject line, and you won't need to disable all your rules. I can use the support manager plugin with only a couple rules disabled, in fact. You can re-enable most of your rules for the support plugin paths, by doing this : 1) Go to the support_manager plugin folder and open /views/default/client_tickets_reply.pdt Add the following at the end of the file, just after the ?> <script>function deleteextra() { var initVal = $(this).val(); outputVal = initVal.replace(/[^0-9a-zA-Z\n\/'@-]/g," "); if (initVal != outputVal) { $(this).val(outputVal); } }; $().ready(function(){ $("#summary").keyup(deleteextra).blur(deleteextra); $("textarea").keyup(deleteextra).blur(deleteextra); }); </script> 2) do the same in client_tickets_add.pdt And voilà You are now able to use mod_security with the support manager, on client side - you may also do the same on the admin side (in admin_tickets_add.pdt and admin_tickets_reply.pdt) What it does? When a customer will copy and paste, or type something in the ticket reply or ticket add textarea the unwanted special characters will just disappear before the ticket is submitted. It will only keep the following : @.-_ It will also remove the http:// and https:// before an url, to make sure your staff won't click on any link by mistake. i love jquery! You may want to adapt the regex to your requirements, but this work fine for us. I hope this will help someone!

Hi PauloV, Seems like you may have also forgot about the global variables. ...or is it only for the Alpha? ...for example : public function validateConnection($key, $user, $sandbox) { global $connectData; Seems dangerous! If the goal of using global variables in simply to log the module requests, then i invite you to check on the Namecheap and eNom modules : they don't seems to log every requests this way, so i do not think it's absolutely required to leave them in place. Otherwise, opensrs allow us to see the API requests, so there is no need to keep this into Blesta. ...maybe for debugging purpose in Alpha, it's a good idea, but i don't like to have a global for this. I would definitely work on this before the beta version cheers and thank you for your help Carl

Hi Paulov, please note i do not define myself as a developer (i'm a system administrator). ..but i think i saw a couple of problems with the code. Should may want to take a look at this page : http://www-01.ibm.com/support/knowledgecenter/SSUS3D/com.ibm.wbpm.mon.admin.doc/sec/entitlement_system_sample_interface.html?lang=en you will see it seems like you should be using /** * TODO Create an Event to change the Type from domain to domainrenew $package->module_id * OpenSRS 100% completed * Adds the service to the remote server. Sets Input errors on failure, * preventing the service from being added. * * @param stdClass $package A stdClass object representing the selected package * @param array $vars An array of user supplied info to satisfy the request * @param stdClass $parent_package A stdClass object representing the parent service's selected package (if the current service is an addon service) * @param stdClass $parent_service A stdClass object representing the parent service of the service being added (if the current service is an addon service and parent service has already been provisioned) * @param string $status The status of the service being added. These include: * - active * - canceled * - pending * - suspended ...what i can see in the opensrs.php file is : /**TODO Create an Event to change the Type from domain to domainrenew $package->module_id * OpenSRS 100% completed * Adds the service to the remote server. Sets Input errors on failure, * preventing the service from being added. * * @param stdClass $package A stdClass object representing the selected package * @param array $vars An array of user supplied info to satisfy the request * @param stdClass $parent_package A stdClass object representing the parent service's selected package (if the current service is an addon service) * @param stdClass $parent_service A stdClass object representing the parent service of the service being added (if the current service is an addon service and parent service has already been provisioned) * @param string $status The status of the service being added. These include: * - active * - canceled * - pending * - suspended Does the @params are still evaluated by php if the recommended @params format is not in place? The IBM documentation (as well as phpdoc) seems clear on the fact this may expose your plugin to a security vulnerability. I see this for many functions in the opensrs.php file... ***Also, it seems like the spyc.php version and a couple other libraries that seems to come from the opensrs dev kit and the whmcs module are not up to date with their latest versions. I would suggest to find another way to do things other than by modifying the libraries, so it will make things easier for everyone to upgrade them I see you also commented our a line that seems to secure the opensrs loader file : On line 11 of openSRS_loader.php, i may seems like you forgot i think to remove the comment after testing : //define("OPENSRSURI", dirname(__FILE__)); You module is working fine even if this security is enabled. I saw no problem on this side. I see /api/commands file are modified : public function __construct ($formatString, $dataObject) { parent::__construct($dataObject); Is there any other better way to do this? Another question : do you have an official git where we can push improvements on your plugin? Will you accept those requests? Cheers and thank you for providing us with the module . Carl

Hi, I ended up by doing this on our production website : <a href="https://blestadomain.com/order/config/preconfig/n-domaines"> <div class="well"><form action="#" id="form"><div class="form-group"> <input type="text" name="domain" value="" placeholder="yourdomain.com" class="form-control input-md"> </div> </div> <div class="search"> <div class="btn-group"> <button class="btn btn-default" type="submit" name="lookup" value="1"> <i class="fa fa-search"></i> Register</button> <button class="btn btn-default" type="submit" name="transfer" value="1"> <i class="fa fa-sign-in"></i> Transfer</button> </div> </form> </div> </a> Using the <a> tag, with no action in the form, if a user click on the form, then he get redirected to the order form. ...no need to disable csrf, no need for a csrf bypass method, and no risk of loosing sales Trying using curl was too much of an exploit attempt against our own services, so i re-enabled the csrf. Much better like this.

Hi Paul, I tried to find the ticket, but i can't. I've had lot of tickets open with them. I.e. : terminate / suspend a customer may delete another account, + all data on the server. haha. It was just before i closed a ticket, i've asked something like "let's say i decide to try another provider, Blesta, do you have an import tool if something turn bad?" And the reply was something like "Some may say we are not good developers because of this, but we are simply unable to decrypt the database in Blesta. We tried many times, but we can't". Concerning encryption, it's for security reasons. i think it may be useful to provide your users with a way to update or change the encryption passphrase, and/or perform security audits on their data. For example : Whm** do not provide any way to change the encryption key, but they provide a whmcs to whmcs migration plugin you can use to migrate the install to another, while changing the key. - please note i did not liked this idea, There was bugs / missing data after. I suggest to allow this option only through the command line for better security. A tool like drush for Drupal would be nice to manage this side of Blesta (and updates) : https://github.com/drush-ops/drush i'm dreaming of : apt-get install blesta-manage-encryption ...and then blesta-manage-encryption /var/www/index.php --decrypt #please enter your password:

Hi, Not that i want to argue with you on this, but... How can i make it quick and easy to see if there is a major problem somewhere if i cannot decrypt the whole database, and look at it's content? How can i know if there was some code injected in the database? I understand Blesta peoples thought about protections on this, but if there was injections in framework like Rails, then there may be the same on other frameworks (a LOT harder to find, but still : everything is possible). In such case, or if there is a validation missing somewhere and someone is able to save corrupted data in the database, then we may never see it. That being said, i can see Blesta have nothing to hide on this. That's what i like : // Handle decrypting/encrypting the private key $rules['private_key'] = array( 'empty' => array( 'rule' => "isEmpty", 'negate' => true, // Decrypt the old passphrase whether it be with a previous passphrase or the default passphrase 'pre_format' => array(array($this, "systemDecrypt"), !empty($vars['current_passphrase']) ? $vars['current_passphrase'] : null), // Encrypt the private key with the new passphrase or the default passphrase if not set 'post_format' => array(array($this, "systemEncrypt"), !empty($vars['private_key_passphrase']) ? $vars['private_key_passphrase'] : null) ) ); ...looking at this, i am wondering why WHM** developer warned me about Blesta, because in case if something happen and i use the systemEncrypt function, they won't be able to decrypt the database and help on a migration. He said he tried, a lot to decrypt it, but he cannot create an import plugin that work if the db is encrypted As far as i can see until now, the problem don't seems to be on Blesta side, but on whmcs dev. side I suggest if you are just afraid to help them to create an importer if you provide a way to decrypt the database, to simply Ioncube this tool.

Hi Serge, I mean : -> because of two factor, now peoples always have their phones near of them, listening to the key pressed on the keyboard. This can be done using common Android malwares. Two factor introduced new problems. It's not a solution, it's the patch of another problem. What will be next? Three, four, and then five factor authentication?

Any news on the new domain module? Are you still planing a beta for this?

Hi PauloV, We are testing this and saw a problem while changing the dns for a domain. If the domain is locked then OpenSRS will deny any DNS changes. You require to unlock the domain to change the dns settings. But, if you update the dns through the Blesta module it does not return an error while updating the dns if the domain is locked, in the client and admin areas. You need to go to the logs, to see this error : :"Registry error, domain's nameservers not updated [Object status prohibits operation Reason:clientUpdateProhibited]" I suggest to add a message saying something like "This domain must be unlocked to perform dns operations" on the tabClientNameservers if the domain is locked + to return the API error to the customer and the admin. Thank you, Carl

Thank you This is going to be useful for other plugins while Blesta dev. complete their work on the new domain functions Someone know when they are going to release the new domain features? I thought it was going to be in a next release, or so? On our side, this was a problem while migrating to Blesta : we were using different prices for renewals, transfer, etc... We ended up by setting a unique price for all our domains, and we are using coupon codes added in the url to provide discounts. It will be much easier if we can get different pricing. ...but in the meantime, it's just more clear for the customer : unique prices.

Just do better : add DNA login to Blesta. Login with your blood! haha I would like to see something better than passwords coming. ...but it's always a new "second factor" method. It never really change the problem : passwords.

Good work Please : think about adding a button to get the EPP code. I suggest If the user do not click the button, then it won't don't perform the query to get the EPP in the client area. Also : what about a feature to add an email adress corresponding to the current domain? Or maybe you would like create an other module to create an email and update it's password? I think OpenSRS is simply the best provider at this time, and i am happy to see you started back to work on this. Cheers p.s.: On line 11 of openSRS_loader.php, you forgot i think to remove the comment after testing : //define("OPENSRSURI", dirname(__FILE__)); It seems to work even if it's not commented.