L3Y

...and ICANN require us to display a list of our current tld pricing.  Why this list doesn't show up in Blesta, in order to help us to comply with the ICANN terms and conditions?
 
I think ICANN policies should be followed the same as you would follow security best practices while programming : we can't live without.

Yup : it's true. 
 
It's hard to manage domains, and customers are all completely lost in the product list, should they have more than (let's say) 10 domains / services.
 
It's all mixed together, and hard to separate domains and the other products using the existing functions.
 
Also, the industry require different pricing for registration, renewal and transfer.  I understand we can use a coupon code, but what if we want our regular price to be lower at registration?
 
It must allow us to invoice the way we want

Yup
 
A domain name should be considered as a different kind of service.
 
It should be easy to list customer's domain alone, while it's not right now.
 
I would invite Blesta dev's to take a look at the views feature in Drupal : https://www.drupal.org/node/1912118
 
This is great because if you want to list, or display something on some page, then you can do it very quick, and it's a great, powerfull feature of Drupal (the main reason i like it
 

Hi PauloV,
 
Thank you for the new version, however, there still seems to be missing validations...
 
I see a lot of things like this one  : 
 
$callArray[$contactType]["address1"] = $this->osrs_normalize_special_characters($client->address1); $callArray[$contactType]["address2"] = $this->osrs_normalize_special_characters($client->address2); $callArray[$contactType]["address3"] = ""; $callArray[$contactType]["city"] = $client->city; $callArray[$contactType]["state"] = $client->city; $callArray[$contactType]["postal_code"] = $client->zip; $callArray[$contactType]["country"] = $client->country; $callArray[$contactType]["email"] = $client->email; $callArray[$contactType]["phone"] = $this->formatPhone(isset ($numbers[0]) ? $numbers[0]->number : null, $client->country); $callArray[$contactType]["fax"] = ""; $callArray[$contactType]["url"] = ""; $callArray[$contactType]["lang_pref"] = "EN";   You sanitize with pregmatch in the function "osrs_normalize_special_characters" only address1 and address2, but not address3, and all other fields will send whatever you type.   The module do not seems to validate what's sent to the opensrs API.   The validateConnection should be private, since it work as private, and not required to be public.  There is a couple other functions like this.   I would strongly suggest to review the module before using it.   I did not verified to see if the domain lock functions got improved, so the customers can see if yes  or no a domain is locked or unlocked, but i may check on this within the next few days and get back if there is still a problem...
Cheers,
Carl

Hi,
 
For prosperity, here is how you can display a list of all TLD's through the API in a table...
echo "<table>"; if (($packages = $response->response())) {     foreach ($packages as $package) {            echo "<tr>";         $pricingsArray=($package->pricing);     foreach ($pricingsArray as $pricing) {         $priceArray = ($pricing->price);     echo "<td>". $priceArray . "</td>";     }     } } echo "</table>"; Thank you for your help on this
 
I was simply missing another loop

Hi,
 
Possible there is missing validations on user input?  I am not yet an expert in object oriented programing, but it seems like the different forms make it possible to submit whatever you want to the Tucows API.  I understand it return errors if the input is not valide, but is this really the best way to go?
 
I mean, for example, the $ns variables, and the $callArray[$contactType].  
 
Also, there seems to be a bug on the ClientSettings page.  It doesn't grab the current status before showing the fieldRadio's.    As a result, a customer will alway's see he's domain as locked, while it is unlocked.
 
After a couple of months/years, i imagine many customers will have unlocked domains, while their domain show up as locked...
 
Thank you,
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

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);

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,
 
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,
 
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,
 
 
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,
 
 
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,
 
 
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,
 
 
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,
 
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 

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. 

I guess you need to do this manually, or create an import tool.
 
We used the universal module on our side to migrate, and the Blesta import plugins.  

Hi,
 
I finally decided to forget about disabling the csrf for the domain form.    I want to sleep at night - didn't like this idea, and i preferred to do not build a plugin only for the purpose of retrieving the csrf  
 
Instead, i just have to parse the html of the form remotely using curl into a variable, work a little on the DOM, and output the form.
 
It works, and i did not had to disable any security.  The CSRF token is always valid, unless the user wait until it expire before searching.  In such case, i can redirect the request somewhere else  
 
 
...to answer Tyson : 
 
 
I saw a couple of conditionals like this one, so i thought i can override this setting?
 
in plugins/order/controllers/checkout.php i saw :
 public function preAction() {                 if ($this->action == "complete") {                         // Disable CSRF for this request                         Configure::set("Blesta.verify_csrf_token", false);                 }                 parent::preAction();                 $this->components(array("Input"));         } Cheers 

Hi,
 
I want to write my own testimonial - but i am waiting for the OpenSRS module before...hahah
 
Seriously : Blesta had absolutely no bugs.   Each time something was not working, it was our own fault, and there was always someone available to help on the forum.  The way Blesta peoples deliver support is much better than opening a ticket / having to provide a test install for a  whm** employee.  I already waited 3 weeks for support at your main competitor, while i never had to wait more than a couple of hours (sometimes minutes) to get an answer here.
 
Thank you and i wish a long life to Blesta

Hi,
 
I want to write my own testimonial - but i am waiting for the OpenSRS module before...hahah
 
Seriously : Blesta had absolutely no bugs.   Each time something was not working, it was our own fault, and there was always someone available to help on the forum.  The way Blesta peoples deliver support is much better than opening a ticket / having to provide a test install for a  whm** employee.  I already waited 3 weeks for support at your main competitor, while i never had to wait more than a couple of hours (sometimes minutes) to get an answer here.
 
Thank you and i wish a long life to Blesta

I hope they will provide email, SSL and dns management with the OpenSRS module

Here is why we like GlobalSign :
 
-> because you do not have to deal with someone to perform a change on the SSL : you can manage your ssl same as if you are working at GlobalSign. 
 
We never had to contact them for any problem, and are always able to fix any issues that may happen by ourselves using their tools. 
 
SSL are very cheap.  You can get alpha ssl starting at 10$ if you are an authorized partner while GlobalSign is selling them 49$ on it's website.
 
Wildcard ssl are sold 149$ on alphassl.com, but you can get them at 49$ if you get to be a GlobalSign partner.
 
Very good provider Blesta must support
 
Cheers