blestatester

I am posting this "solution" (bug?) in case anyone else had my issue. I realize there are previous threads about this here, here, and here (for example) but I didn't want to further hijack or necro their threads as neither involved NameSilo. In my case, I am using the NameSilo module(s) I tried both the original and the fork: https://github.com/NETLINK/Blesta-Namesilo https://github.com/mrrsm/Blesta-Namesilo I ended up using the latter because it dynamically pulls all the valid TLD's that NameSilo currently supports I did not test any other Domain Registration modules. Issue: It ALWAYS generates a "That domain name is not supported." and does not show the TLD under "Check Domain Availability" Solution: it was because I (intentionally) set the Package as a "Restricted" package -- it simply does not work with the NameSilo Blesta modules(s). Once the Package is set to to "Active", it works. I followed Paul's documentation about "Selling Domains" to the letter I did not find documentation or posts stating that Domains couldn't be Restricted Packages. The documentation simply says "'Active' is the default, 'Inactive', and 'Restricted' are also available." I actually did want to use the module as a Restricted Package to only some existing customers I used "Set Packages" prior to testing the Order so that the appropriate user(s) had access to it I only have a "Domain Package Group" selected and not "Package Group" selected as suggested here. Hope this helps someone else. Thanks

Disagree. It would make multiple databases each of similar size (because they contain all of the necessary tables necessary to run Blesta). So, maybe more storage requirement overall. In summary: It possibly requires more storage because each database would require any required elements that Blesta needs upon creation of a new company Databases would only be "massive" if you had "massive" amounts of data associated with a particular company. It would in fact make the databases easier to browse because each database would only contain data associated with the specific company it represents It is better from a security perspective as well All data, including user registrations. would be separated -- with separate database credentials to even open the database It would also be irrelevant what username/email address someone wants to use if they had business with each company -- they could use the same or different if they wanted to In fact, you could have completely independent ADMIN user for each site It would potentially reduce customer confusion for those who use multi-company that may have customers in common This particular case became a problem for me because of customer confusion when they tried to make a purchase from the 2nd/unrelated company and they couldn't register with their preferred username (their email address) which should be uniquely theirs So, the question then asked of me was "how did someone else register in your secure system with my email address??" I had to then figure out what was going on ... and here we are This would make Blesta be true "multi-tenant" and not just "multi-site" Reference: (rudimentary explanation of WordPress multi-tenancy vs multi-site, add http : //) torbjornzetterlund.com/multi-tenant-wordpress-enterprise/ Reference: (explanation of Drupal multi-tenancy vs numerous other options, add http : //) drupal.stackexchange.com/questions/78328/does-drupal-support-multitenancy This could be an additional selling point and differentiator for Blesta vs competitors I am not trying to imply that this would be trivial for the Blesta team to code -- I understand and appreciate the complexities and prioritization needed here. But, it is a better solution for the long-run. And, for me, this is a of a show-stopper with what I thought multi-company could do, and what I had hoped to use it for. Thanks

Paul, believe me I know the security implications more than you can imagine. I've worked with a number of "multi-tenant" setups (particularly Drupal) and also, more recently, WordPress. I was hoping that your implementation would have been similar to Drupal's: Separate databases (i.e., with completely separate tables, user registrations, etc) One codebase (which you have) -- so that upgrading once, upgrades many This also means that if you want to do a high-availability setup, each company database would have be replicated separately Given that it is not this approach (with individual database), this likely has some other far-reaching implications ... i.e., PCI. :-( The current implementation: Shares a database (and in particular, usernames) Could potentially expose data elements from multiple companies in a single attack The "right" way (from a security perspective) to do a multi-tenant setup ... is with completely separate databases. (Though admittedly, true security purists would frown upon any shared anything. We all realize that some compromises have to be made with this type of setup). I am not criticizing, I am merely summarizing what I have literally learned today in this thread. Your corrections to my understanding are certainly welcome. Thanks

This. Exactly. I thought that the registration databases would have been "separate but unequal" (i.e., not the same). This is causing me to take a step back after learning this.

I definitely understand that, but I have multiple companies that may have (non-staff) users in common who would want to use their "well-known" email address. :-(

Hi Paul, thanks for your response. I will have to create a feature request when I get a chance. Is there a way to force registering users to only use Username instead of email address (i.e., not giving them that option)?

@BlestaStore, thanks for your response. Aside from the primary admin account, is an individual account valid (i.e., can authenticate) in both companies?

Same with the NameSilo module for me (using the latest version 1.5beta from https://github.com/NETLINK/Blesta-Namesilo)

Hi, I have been testing a multi-company setup with Blesta 4.1.1 and I thought that user registrations were unique and separate from one company to the other. However: I had a user, who is already registered with Company #1, try to make a purchase with Company #2 They were unable to register a new account with Company #2 using the same email address that they used with Company #1 --> "The username has already been taken" BUT, they also couldn't use their login credentials from Company #1, at Company #2 --> "No match found for that user/password combination" Trying the "Reset Password" option on Company #2, using the Company #1 credentials --> "A confirmation email has been sent to the address on record", BUT no such email is actually sent (according to the Blesta logs + they didn't receive any reset email; they receive all other system emails just fine) Note: They were using email address as Username (does this cause the above? i.e., is it just the Usernames are shared/used as an index, or is the entire User Registration information?) Are the user registrations actually separate per company or not? Thanks in advance

Hi @Blesta Addons, it appears you may not understand what I am saying; but I was just trying to say that the Blesta Upload folder already had the proper ownership & permissions -- yet the upload still did not work until I chown'd the webroot to www-data:www-data So, it appears to me that the module is attempting to write to another folder under the webroot. I will have to do a little digging to figure out what/where. Thank you for your replies and feedback on this.

Hi @Blesta Addons, I stated that in my post -- the "uploads" folder was owned by apache and had 777 permissions, but I still had to "chown www-data:www-data /the/blesta/webrootdir" for this module to start working. Is the module writing/updating files in any other folders? Thanks

Hi, I was just able to resolve this -- it was a permission issue (possibly permission inheritance) -- but I don't like how I resolved it. I had to: chown www-data:www-data /the/blesta/webrootdir/ Can you kindly give me an idea of what the recommended ownership and permissions are needed (files/folders) for this specific module? I am trying to keep the install as secure/hardened as possible (it involves multi-company). I already had: chown www:data:www-data /the/blesta/uploadsdir And Blesta's /admin/settings/system/general/basic/ shows Temp, Uploads, and Log directories writable. But that was not enough. Other modules are all working fine with how the permissions were set previously. I have searched but can't seem to find anything documenting this adequately. Thanks in advance. EDIT: To answer @Blesta Addons directly, yes there were two issues: The module's configurable options would not display File Uploads did not happen (progress bar showed but no upload). The only way to get to it was to Copy an existing Package that had been created before the upgrade. But then the upload didn't work anyway As I said above though, I have resolved this but I want to ensure the most secure permissions that will allow the module to work properly.

Hi, it appears that the Digital Products module v1.1.0 has stopped working for us since upgrading to Blesta 4.1.0 Symptoms: When you try to create a new Package using this module, the Configurable Options do not show up (when you choose Digital Products as the module); it will keep the Configurable Options of whatever module was chosen previously. However, switching to numerous other previously installed modules (e.g., Proxmox, ISPConfig, NameSilo, Universal module) all work properly All previously uploaded files are properly listed but you can't upload any new files. In fact, the only way to get the Upload dialog is to copy an existing package that utilized this module, but you still can't upload -- you can choose a file and the progress bar shows up, but it still says "No file selected" after the "phantom" upload happens Note: I verified module configuration using the module "Manage" screen (I am just working with PDF for now) I verified upload folder permissions I verified syslog, apache, Blesta log files (Debian 8 64bit, Apache 2.4.x) had no errors OR bad HTTP return codes Module worked fine until the upgrade to Blesta 4.1.0 (I was going to upgrade to Blesta 4.1.1 but wanted to check extensively that everything worked before performing that upgrade; this module failed that check) Has anyone experienced this? Thanks in advance for any feedback or guidance.

@Blesta Addons, that was it; that worked! Thank you. Can you suggest what we should make the permissions for your plugin directory?

@Nelsa , I am all ears. Note that this install was performed per instructions here: https://github.com/Blesta-Addons/Css_Javascript_Toolbox So I would love to know what was done incorrectly. Thank you

@Blesta Addons Here is the directory structure I see (within your plugin's folder). Note that ownership was changed to www-data:www-data , as I indicated above, specifically because this plugin isn't working and I am trying to rule out any sort of permissions issue for the webserver. /web/blesta/plugins/css_javascript_toolbox -rw-r--r-- 1 www-data www-data 453 Feb 9 2015 config.json drwxr-xr-x 2 www-data www-data 4.0K Feb 9 2015 controllers -rw-r--r-- 1 www-data www-data 571 Feb 9 2015 css_javascript_toolbox_controller.php -rw-r--r-- 1 www-data www-data 276 Feb 9 2015 css_javascript_toolbox_model.php -rw-r--r-- 1 www-data www-data 7.4K Feb 9 2015 css_javascript_toolbox_plugin.php drwxr-xr-x 3 www-data www-data 4.0K Feb 9 2015 language drwxr-xr-x 2 www-data www-data 4.0K Feb 9 2015 models drwxr-xr-x 3 www-data www-data 4.0K Feb 9 2015 views

@Blesta Addons have the plugin show a successfully installation ? YES then the code successfully added ? Yes, but the list never shows the addition; same problem as previously reported by ( @AllanD ) when you add a custom js , you should go to source code of your page to see if is well added to the page . Nothing added you have any files inside the includes directory ? Please be specific about the path you are referring to; what specific path?

@Licensecart , thank you for your feedback. It would be useful and instructive to understand why this does not work for some installations. (BTW, I have reviewed Apache logs etc and I have not found any clues that point to anything of note)

(I realize the last post was over a year ago) @Blesta Addons I've been evaluating Blesta v3.6.2 and experienced the exact same result as @AllanD . - Installed this plugin per the instructions in a fresh Blesta install - Enabled plugin - Managed plugin to add custom JS (for Piwik tracking) - It confirms with a Green checkmark and "Custom JS has been Successfully Added to body_end " - Nothing changes or is listed - Tried multiple installs/reinstalls --> no change in result - Change folder ownership to www-data:www-data, etc etc etc --> no change in result Environment: Debian 8 64bit ISPConfig 3 Blesta v3.6.2 Apache: Server version: Apache/2.4.10 (Debian) Server built: Sep 15 2016 20:44:43 PHP: PHP 5.6.27-0+deb8u1 (cli) (built: Oct 15 2016 15:53:28) MySQL: mysql Ver 14.14 Distrib 5.5.53, for debian-linux-gnu (x86_64) using readline 6.3 Anyone get this sorted out? A bit disappointing first impression as I would have hoped there would be an easy way to simply add analytics tracking to Blesta.