Jump to content

Kal

Members
  • Posts

    23
  • Joined

  • Last visited

  • Days Won

    7

Posts posted by Kal

  1. @Paul, I've done some more tests and worked out that the problem is with the `DirectAdmin.password_length` setting. Regardless of what I set this to, the error appears if I enter a password of less than 12 characters. The `DirectAdmin.password_requirements` setting works as expected.

    For example:

    Configure::set('DirectAdmin.password_requirements', [
        ["A-Z"],
        ["a-z"]
    ]);
    Configure::set('DirectAdmin.password_length', 9);

    With these settings, a password of 'Abcdefghijkl' (12 characters) passes, but a password of 'Abcdefghijk' (11 characters) fails.

    Is this a bug, or have I missed something?

  2. 7 hours ago, Paul said:

    I'm not familiar with DA's 2FA and nobody else has mentioned it, but if you are forcing 2FA then that may be the problem. I would suggest temporarily disabling it to check if it works.

    Okay, so DA has the option 'Allow API logins with the current User/password', which is ticked. Just to be sure, I temporarily turned off 2FA, but the problem persists.

    Any other ideas?

  3. Hi Paul, and thanks for offering to help.

    8 hours ago, Paul said:

    Regarding the issue, are you certain that you have modified the correct file? You don't have another copy of Blesta in another directory? You are using the DirectAdmin module and not another?

    Yes, no and yes. I edited the error message under the same directory, as you described, and I can confirm that the error message has now changed—so it's certainly the correct (and only) copy of Blesta on the server.

    8 hours ago, Paul said:

    The password you provided meets the password requirements for your DA server?

    Yes, it exceeds the requirements. I was testing the 'Add Service' command on an existing account, and the password is the one that is already used by that account. I unticked 'Provision using the DirectAdmin module when activated'. Am I doing something wrong perhaps? The accounts are already set up in DirectAdmin—I just want to link them to Blesta so I can start using it for billing. I also tried creating a new account by specifying a new username and domain, but I just get the same error again, even if I use Blesta's 'Generated Password' feature.

    So despite the error, I suspect the problem is not with the password requirements. What else could cause this error to get triggered?

    8 hours ago, Paul said:

    When Blesta is not the authority on the password requirement, we go with the strictest possible requirement defined by the control panel. If the panel has a setting to force passwords of 12 characters, upper-case, lower-case, and a special character, then we require that so that there is not a failure to deploy a new account or update a password within the panel.

    Last time I checked, DirectAdmin's `enforce_difficult_passwords` option is turned off by default, and if you turn it on, the default minimum password requirements are 6 characters including an upper-case letter, lower-case letter and number. See: Difficult password enforcement option. When you say that you 'go with the strictest possible requirement', how can you know how a user has configured this in DirectAdmin? Password checking is performed by a script, and there is no limit to how the server admin could configure this.

  4. On 1/19/2021 at 6:43 AM, Paul said:

    Open this file to change the requirements:
    /components/modules/direct_admin/config/direct_admin.php

    I have edited this file as described, removing unwanted requirements and reducing the minimum password length to 9, but as soon as I try to add a service I still get the same message:

    image.thumb.png.5051d985603c7f07ba2a1d73ef27b6cf.png

    Help!

    (BTW, for anyone who still believes that character-composition requirements are a good idea, you might want to read the advice of security experts like Troy Hunt, NIST and Microsoft who all advise against this practice. See: Passwords Evolved: Authentication Guidance for the Modern Era. A poor decision for Blesta to turn this on by default IMO.)

  5. Friendly URLs are, in my opinion, an essential element of any content management system. No one likes a long, ugly URL. But more importantly, no one likes link rot—least of all the site owner who may lose their precious search engine rank when a URL changes. For this reason, a URL should never be dependant on the underlying platform. Here's an example of such a URL, from Blesta's Knowledge Base plugin:

    https://blesta.example.com/plugin/support_manager/knowledgebase/view/12/testing-your-website-before-it-goes-live/5/

    Aside from being unnecessarily long, the URL also includes the following, platform-specific data:

    1. Blesta's Knowledge Base is a 'plugin'.
    2. The plug-in is called 'Support Manager'.
    3. The article is the 12th one that was added to the database.
    4. The article belongs to the 5th category that was added to the database.

    Each of these is a point at which the URL is likely to break if and when the underlying software platform changes. A platform agnostic URL, or permalink, is a URL that should never change, and it's a critical element of website design/development. Tim Berners-Lee stated this firmly in the 1998 article, Cool URIs don't change, where he espoused the concept of URI design.

    I request that Blesta introduce a permalink feature, which is accessible via the UI, easy to use, and central to the design of the whole system. The Knowledge Base, perhaps, needs special attention, so that database table row IDs are never part of the article URLs. (routes.php does not fulfil these requirements.)

    Without this feature, the user must go to considerable effort to manually create many individual redirects using Apache configuration files or .htaccess files.

  6. On 8/26/2020 at 9:27 AM, Paul said:

    I believe this is possible by creating a route, similar to the order manager which uses /order/ instead of /plugin/order/ See https://docs.blesta.com/display/user/Configuration+Files#ConfigurationFiles-routes.php for details. If you need help, creating the route, one of our devs may be able to help. It wouldn't hurt if we had some common examples in our docs anyway.

    Thanks for the info about routes.php. I can see from the code, for example, how `/admin/settings/company/general/localization/` really points to `/admin_company_general/localization/`. By the same logic, `/admin/plugin/support_manager/admin_knowledgebase/` should point to `/support_manager/admin_knowledgebase/`, but trying to load that second URL in a browser doesn't work—so I guess there's something I'm not getting about how it works.

    Anyway, I suspect I can't achieve what I want with routes, because the table row IDs for knowledge base articles are essential parts of the URLs. Ideally, I'd like the option of having human-readable and platform-agnostic URLs like this:

    https://account.example.com/help/docs/article-title

    I don't like that the URLs include table row IDs, which don't reflect anything meaningful, only what order I created the articles. That kind of thing should be hidden from the user IMHO.

  7. I had wondered if structure.pdt would get overwritten with an update. Indeed it does. This also makes the official instructions for Removing Branding a temporary fix, which isn't mentioned in the docs. Since that feature is advertised on Blesta's pricing page, I'd have hoped for a more robust method.

    DirectAdmin has a feature where customised config files can be placed within 'custom' subdirectories to protect them from being overwritten. Maybe something like that could work for Blesta? Adding these features to the UI would be even better though. @Paul, you mentioned above that style overrides were coming to themes, and there was talk on this thread of possibly removing branding automatically from unbranded licenses in the future. Are those features still on the roadmap?

  8. Yes, when I said 'departments', I wasn't specifically referring to Blesta's feature for categorising support tickets—rather the actual departments they refer to in your business. They are the common link aren't they, between these currently unconnected elements in Blesta? A simple table of corporate departments could contain the email address, signature and even the support category (Department) for each one.

    While I suppose you're right—it doesn't take that long to go through and change each template—wouldn't this still be an improvement? Is there a good reason to leave it as is, and require the user to update the same email address repeatedly throughout the system? That approach invariably leads to human error, as illustrated by one or two inconsistencies in Blesta's own default templates. This is what relational databases are supposed to save us from, no?

    On 7/31/2020 at 2:52 AM, Paul said:

    Best way I can think of to improve this is to add an option to simply mass update all email templates to use an address or a domain specified.

    Perhaps my suggested feature would break things for existing users. If that's the case, sure, giving users the ability to simply change the domain used for email addresses would be an improvement. You could even make it recognise subdomains and choose the main domain by default, since probably 99%+ of users are going to use email addresses like billing@yourdomain.com, not billing@blesta.yourdomain.com. Edit: I just noticed that this was requested here: Update Global Email Address.

  9. The email templating system pre-populates the 'From Email' fields with addresses like billing@yourdomain.com and sales@yourdomain.com. If you install Blesta on a subdomain, you'll get email addresses that look something like billing@blesta.yourdomain.com, when you probably want billing@yourdomain.com. Or maybe you want something different, like accounts@yourdomain.com. Either way, the only way to fix this appears to be to manually edit the From address in each and every template. (See where others have asked about this: From emails how to change?Problem With Sending From Email Address and Wrong Email.)

    Could Blesta not store an email address for each department (admin, billing, sales, support), much like it stores email signatures? It might also make sense to link a default 'From Name' and Signature to each department, so you only have to specify the address (or the department) and everything matches up automatically. (As if to illustrate the potential for mistakes, when these details aren't linked, the default Account Registration template is from Sales, but the From Name is set to 'Billing Department'.)

  10. Did this ever happen? I'd like to lose the drop shadows too. ?

    Edit: I worked around it by creating a custom CSS file in app/views/client/bootstrap/css/:

    .nav-content .navbar-default .navbar-nav > li > a {
      text-shadow: none !important;
    }

    Then I linked to it from app/views/client/bootstrap/structure.pdt. It works, but is there a better way to do it?

  11. On 11/22/2019 at 5:52 AM, Paul said:

    That's a really good article, kudos to Rack911. Thanks for sharing!

    No worries! I was just checking out Blesta as I consider whether to automate my billing (for a small number of clients), and signed up to the forum when I saw this discussion, as I thought the Rack911 audit could help others here. (Blesta looks great BTW.)

    22 hours ago, webhostingux said:

    This for the information...I also have huge hope for CyberPanel as their panel UI is really users friendly comparing another any free panel version.

    Yeah, sounds like everyone (Rack911 included) had high hopes for it! What a shame they developed it without the necessary security focus or knowledge. For me, this means paying license fees I thought I could save by moving away from cPanel… ? but I figure it's just not worth compromising on security with web servers.

×
×
  • Create New...