L3Y

I was going to ask the same Happy to know you are working on this

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

The reason why it worked was because i copied / pasted by mistake the csrf token from the real form No comments lol i was probably tired It still doesn't work. I even tried to add Configure::set("Blesta.verify_csrf_token", false); to the file plugins/order/config/order.php but it still doesn't work. What the correct controler to add?

Hi, I am sorry to open this as a bug request, but imho, this may become a security bug, if the person who configure the universal module don't want to configure the email notification, or just want to configure the notifications at a later time. In /components/modules/universal_module/universal_module.php i see those lines : if (!isset($vars['package_email_html'])) $vars['package_email_html'] = "{% debug %}"; if (!isset($vars['package_email_text'])) $vars['package_email_text'] = "{% debug %}"; if (!isset($vars['service_email_html'])) $vars['service_email_html'] = "{% debug %}"; if (!isset($vars['service_email_text'])) $vars['service_email_text'] = "{% debug %}"; As a result, if you forget to add your own tags, then it may send emails with the server SSL key, as well as the Blesta encryption key. The email is also stored in the Blesta logs, and i am not sure this is the correct place to store this kind of stuff. I would strongly recommend to add a feature in the config files to disable this tag, or at least to comment those lines, and give us the choice to enable this or not! Or maybe someone can explain why it's there and what's the exact purpose of this, because the debug logs sent by this tag do not seems to include anything that can help to diagnose template issue! This tag seems dangerous. Thank you for taking this into consideration! Cheers! Carl

Ok. I finally understood i needed the whole thing : Configure::set("Blesta.csrf_bypass", array('client_login::index','domain_form::index')); Someone can explain why i need to disable the csrf on the client login in order to let the domain form work? Why does Configure::set("Blesta.csrf_bypass", array('domain_form::index')); is not working for me? Thank you Carl

You have no obligation to provide services to someone : it's a privilege, and your terms and conditions should reflect this. Just refund and kindly ask the customer to re-do the order without any vpn, from he's real address, etc... When it's a fraud, the customer know what he is doing, so he won't bother you. Such person already know not every hosts will accept them. As long as you provide a refund in a short delay, you won't have any problem imho. Do not ignore the requests, simply explain you already answered the questions, and you cannot help anymore. Cheers p.s.: i'm pretty sure in 2025 or something, Blesta will handle this part of the customer service Automated support replies is a feature planned in CORE... ???

Krosoft lost me a long time ago I tried Windows 8 for a couple of days. I won't bother trying the next version

Hi, I know i can globally disable the CSRF, and i also know i can disable the CSRF only for the client login, like this : Configure::set("Blesta.csrf_bypass", array('client_login::index')); ...but what is the correct array to only disable the CSRF for the domain search form? I tried a couple, for example the one suggested here Configure::set("Blesta.csrf_bypass", array('domain_form::index')); ...but nothing is working. Someone can help and provide this info? Thank you, Carl

Hi PauloV, It makes 1 week now How are you going? I hope you are feeling better! I am available to provide feedback on your module whenever you want. We need such module. I encourage you to go ahead on this : there is a lot of peoples waiting such module before they migrate to Blesta! I worked a little on this on my side, but i am not familiar with Blesta / opensrs api. When are you going to release your plugin in stable version? I am asking because it say "while("its FREE")" in your signature, so i assume those are beta plugins/modules? ...are you going to open a module store or something, and then sell your work? Also : should you be available to work on some other projects, please let me know more about your services in pm. Thank you, Carl

Hi, Namecheap is giving a free year upon domain transfer. But if i transfer a domain using the Namecheap module, then it doesn't seems to take this into consideration : the expiry date is set to the original one. Am i missing something? Thank you, Carl

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, How can i get the client side in French by default and the admin area in English by default? Seems like i have only the choice to make everything English, or French, but most French peoples i know are working only with English versions of softwares, since most documentation is only available in this language. It's just easier Also : a little suggestion If you get an error in Blesta, while you are using it in French, then the error won't provide any infos. Most of the time, the translation is not good, it doesn't really mean the same thing as the English error, and you know searching the error in Google will just be a waist of time. As a result, seems like i have to change the language back to English and then re-do the same operation to see the correct error I already forgot to switch it back in French, so all customers received an English invoice one day later Bilingual errors should be a future feature imho ...or have the option to display english only error messages. Thank you! Carl

That would be great. But, i think it would be best to support Docker, not just the LXC itself. http://www.docker.com/ If this become available by tomorrow, then i see tons of ways to use this module right away Docker is much better, and easier to manage I suggest to build a kind of "universal installer" for Docker. Something simple like 1-2-3. You copy and paste your dockerfile and configs in Blesta, then you press a button, and your docker get build wherever you want. A simple copy and paste to provision as much servers you need with apache, php, mysql, and a cms, i.e. Wordpress

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

+1 on this.

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

I think this reply may help other with a similar issue. If you can connect to the remote server from the command line using this : openssl s_client -connect hostname:2087 ...but you still get this error : server.hostname.com curl_exec threw error "Failed to connect to 111.00.00.00: Permission denied" for https://server.hostname.com:2087/json-api/listpkgs? Then check if SELINUX is set to enforcing in /etc/selinux/confing, on your Blesta Server. If yes, then you may want to issue this command for testing : echo 0 >/selinux/enforce To re-enable after testing : echo 1 >/selinux/enforce If it worked with SELINUX disabled, then DO NOT leave SELINUX disabled only for this reason In fact SELINUX is doing it's job : it blocked a connexion from Apache / Nginx to another port than the standard one. It act as a kind of firewall. If your firewall prevent a connexion to happen, then you do not shut down the firewall : you open the port. Same thing also apply for SELINUX. You may fix any issues to communicate through the port 2087 like this : First, install the required package to mange selinux : yum install policycoreutils setroubleshoot then, do this to allow the apache, lighttpd or nginx to communicate through the port 2087 semanage port -a -t http_port_t -p tcp 2087 This way, you keep as much possible of protection, and you can use the cPanel module. To keep your system clean, you can undo the last yum install by doing : yum history undo last so it will uninstall the last installed package and it's dependencies. Hope that help Carl

Hi, In the meantime, i found we can also test using : openssl s_client -connect hostname:2087 This way, there is no need to modify the code for testing. See here for some infos i found on how to diagnose connexion issues with cPanel : https://forums.cpanel.net/threads/unable-to-create-email-account-via-xml-api.369361/#post-1494952

Hi, I am trying to setup the cPanel module with a reseller - i do not want to use root for this. If i add or modify a server in the cPanel module config, i get this error : "A connection to the server could not be established. Please check to ensure that the Hostname, User Name, and Remote Key are correct." I saw if i remove those lines from the cpanel.php file, then i can add the server, but still : i have no cPanel package listed upon modification of existing package. 'valid_connection'=>array( 'rule'=>array(array($this, "validateConnection"), $vars['host_name'], $vars['user_name'], $vars['use_ssl'], &$vars['account_count']), 'message'=>Language::_("Cpanel.!error.remote_key_valid_connection", true) ) There is nothing on the server's log. No other error. The reseller is ok with he's ACL : we do allow listpkgs, password change, suspension, create and "Allow the reseller to use all global packages" - this should be enough imho. Under Blesta, in Tools > Logs, it's strange : i see a success for listpkgs each time i try to access the package creation page ( in fact, all automated task return a success even if there is no request made) The reseller already have a couple of packages. I tried without firewall (and also without phpids just in case) While i was trying to add the server, and i was trying to create a package, i was running a tcpdump on both cPanel and Blesta servers, and i saw absolutely no request made to the remote cPanel server (same thing on the cPanel server). There is no attempt to log in through the API There is no logs on the cPanel server, and no logs on the Blesta server for the API requests. ...why am i getting a success result in the logs under Blesta while no request is made, and why the cPanel module do not work for me? I even see success for cPanel API requests even if the key is an old key, that's no longer valid. What's wrong exactly? Any clue? Thank you, Carl

Hi, + 1 on the question : any news on this ?

Hi, If someone else get the same error, please have a check on : session.cookie_domain in the php.ini file. Problem fixed : hope this post will be useful for someone, someday I was all confused, because i am coming from another well know billing solution i won't even pronounce As a result : i may think it's Blesta's fault, but it's an evidence for me now : Blesta just cannot have a bug.

...and i am able to reset the password without any error. after i am still unable to login.

Hi, i tried this already 2 times. still the same. I noticed if i disable the csrf it seems like the password is validated, cause if i use the wrong password, then i am getting a username / password error. But if i try with the correct password then i just don't get any error. weird

Hi, I just tried with Configure::errorReporting(-1); ...still no luck : there is no errors on the login page, and there is no errors in the logs upon login. I am trying with csrf disabled. If i re-enable the csrf check then i am getting a token error. Without csrf i have nothing (no error, no login). Thank you, Carl