Jump to content

John

Moderators
 View Profile  See their activity

  • Posts

    217

  • Joined

  • Last visited

  • Days Won

    1

 Content Type 

Posts posted by John

  2. Upgrader not disabled after upgrading

    in Bugs

    Posted

    It appears that you can still go to ~/admin/upgrade after upgrading to the latest version, and this page is not disabled after running the upgrader. This could be a security issue as it shows the full path to the Blesta installation, and someone could run the upgrade again, using up database resources.

  4. 'Remember Me' by default for admin login

    in Support

    Posted

    Hello,

    I'm trying to get the admin login page to check the 'Remember me on this computer.' option by default, but I don't see the 'input type="checkbox"' in /app/views/default/admin_login.pdt anywhere, so I'm unable to set it to checked by default.

    Does anyone know the proper way to do this?

    Thanks.

  6. Theme cannot set all colors

    in Bugs

    Posted

    24 minutes ago, Licensecart said:

    Have you edited the colours on the client side themes under Look and feel?

    Yes. You can not set it from there. It is hard coded into CSS (/app/views/client/bootstrap/css/styles.css). 

    #my-info .panel-blesta > .panel-heading {
    background:#f1f1f1;
    color:#656565;
}

     

  7. Theme cannot set all colors

    in Bugs

    Posted

    Specifically, we are concerned about the location in the image that I have attached below. The color that is hard-coded into the template clashes with our theme. We have modified the CSS manually for now, but it would be nice to have an option to set this color.

    color-change.png

  8. Deleting Support Tickets

    in Extensions

    Posted

    21 hours ago, Paul said:

    No immediate plans for this, but we're open to the idea. Why do you want to delete tickets? We see deleting tickets as something that generally shouldn't happen, except under unusual circumstances. Which is probably why it has thus far not been implemented.

    IMHO, I believe that tickets fall under a different category than invoices or transactions, which cannot be deleted. We have multiple departments set up that anyone can email in to, and many of them are spammed constantly. Generally we just close the ticket, but an option to purge the ticket would be nice. We have no plans on deleting client or prospective client tickets, but if we want to review our support tickets, we have to sort through the spam to see tickets that really mean something.

    As a temporary workaround, we could create a 'Trash' department that no one is assigned to, and transfer all the junk tickets there, but an actual delete option would be really nice.

  12. Get all packages, not just active ones

    in General

    Posted

    Hello All,

    I'm pretty new to this development stuff, so bear with me here.

    I'm trying to get a list of all packages, not just the active ones. The code I am currently using is below, and I have not found a way to list all (active, restricted, inactive) packages.

    Quote

    $packages = $this->ArrayHelper->numericToKey($this->Packages->getAll($this->company_id, array('name' => "ASC"), "active"), "id", "name");

    I'm guessing I need to change the bolded part above to something else, but I have not found what that is yet.

    Thank you!
    John

  16. See How a Ticket Was Created

    in Feature Requests

    Posted

    27 minutes ago, naja7host said:

    First . We never change password to a password that client want . We change the passwords to a generated one and send email about the new password .

    The client can request password change but can't determinate it via ticket .

    Also is good to see a lebel about how this ticket was opened (manager, email piped,  import email, Api ... )

    A good workaround. Yes, even a label would be nice.

  17. Fraud Screening: Screen Every Order

    in Support

    Posted

    I'm trying to change our fraud screen settings so that every order (not just the first one made by a client) gets run though the fraud screening system. We have had a rash of fraudsters that order twice, and their second order automatically gets approved even though the first is marked as fraud.

    I swear there was a way to do this, and I must just be going crazy. Could anyone point me in the right direction?

    Thanks.

  19. Duplicate Client Email Addresses ??

    in Bugs

    Posted

    5 hours ago, Paul said:

    I don't see how it's possible to login and access a different customer account. The username must be unique, and when you select "Use email as username", Blesta just saves the email address you entered as the username. Usernames are all stored in the same location, and you must authenticate with the username, not the email address.

    Now, back to the topic. Quite a few people have asked for the ability to restrict additional signups using the same email address. This would go hand-in-hand with a setting to force email addresses as the username, and effectively remove the option to specify a different username.

    Now, as is the case with us, we have customers who have multiple accounts as a matter of necessity. The same person manages the accounts, but the accounts are for different entities. So, for us this restriction would be detrimental. We created a task for this as part of CORE-1387.

    Paul, would you consider changing the login page to include email as well? Example: https://secure.inertianetworks.com/client/login

    Especially if you are going to allow forcing the email to be the username, this would prevent confusion.

  20. See How a Ticket Was Created

    in Feature Requests

    Posted

    5 hours ago, Paul said:

    Some people will consider the confirmation link an unnecessary hassle for the vast majority of ticket requests. However, I do think showing the method by which the ticket was created would be useful in helping staff determine how to proceed. The link would need to be a setting, and is more complicated to implement, so I'm thinking mainly shorter term.

    Sound good? Any suggestions of where we would want to show how the ticket was opened?

    If we went the confirmation link route, it would only get sent out for tickets that were opened by email, and it could be a per-department setting if it was turned on or not.

    The ticket could just have a red "Untrusted" button both in the list, and in the ticket details when you open the ticket. Kind of like client labels when you list all clients.

    If the client replies to the ticket via email, this should clear the red or 'unsecure' flag, as they need the ticket number and hash code in order to successfully reply.

    If you do it this way, you could forget the confirmation link entirely, as if it was a sensitive ticket, you could just make a predefined response saying "Please reply to this ticket for us to be able to proceed."

  21. Duplicate Client Email Addresses ??

    in Bugs

    Posted

    6 minutes ago, siteAdmin said:

    Don't know about front end registrations. I am trying to customise this app for Admin creating clients and issuing invoices. This way the client gets an invitation email. I have not sent any email msgs yet because I am only simulating these issues on a localhost. But again, when you do create clients through Admin panel then the first client gets the wrong mail even if the second client is supposed to receive the invitation e-mail. This happens only if the admin panel creates clients. I have not tested the front end regs yet.

    Ah, that might be the case then. We rarely create clients via the admin interface, and when we do, we know that the person has never had an account with us before.

    This is probably an oversight on Blesta's part then.

  23. Duplicate Client Email Addresses ??

    in Bugs

    Posted

    6 minutes ago, siteAdmin said:

    At present it is a Huge Security issue. Because I tested it few mins ago.

    It's like this........

    Supposing Admin or somebody creates a second (or third or fourth... client) client account duplicating the email address of an existing customer, then if the first client logs in using his/her email address he/she gets access to the last account of the client who has the same email address. This is what I see in the trial v3.6.2 I am testing right now. If there are production account with similar issues then it is a HUGE security issue.

    This has to be addressed immediately and inform all Blesta users. This is NOT a joke.

    I'm not sure if that is possible, as you can log in either with the email on file OR the username you chose. You choose this at sign up, and it cannot be changed without administrator intervention. It will not allow duplicate usernames or email addresses (if you chose that as your username).

  24. See How a Ticket Was Created

    in Feature Requests

    Posted

    With Blesta (and most other ticket systems), you can create a ticket by sending an email to the email address associated with the account. While this is a very nice convenience for clients, it also poses a security risk.

    Say I am trying to attack David Smith (david@smith.com), and I know he hosts with 'XHost'. All I need to do is find the support email for 'XHost' and spoof an email coming from david@smith.com saying something like this:

    Quote

    Hi 'XHost'!

    Can you please reset the password on my VPS to '123456Seven'? For some reason, the control panel is not working for me.

    Thank you,
    David Smith

    Now, I just have to keep trying the password I asked for, and soon it will be changed.

    The best way to prevent this is to have an indication on each reply to say if it came in via email or the client area. That way the host could take extra precautions, like asking for a reply via the client area before sensitive actions are taken.

     

    Another thought would to have a "BoxTrapper" type system, where if you open a ticket via email, the system sends you a link to click on, and it would then mark the ticket safe.

  25. Duplicate Client Email Addresses ??

    in Bugs

    Posted

    51 minutes ago, ariq01 said:

    And how to force user, to only use email as login. Not username.

    I would really like this as well. Clients sign up, set their username as their email, and then when they come back to log in, they see a "Username" field so they try their most common usernames. They never even think to try their email address. We had to modify our login page to say "Email/Username".

    If we could just force everyone to use their email addresses, then this would not be an issue.

    If someone needs to open two different accounts, then it's not that hard to use an alias in gmail or cPanel email (such as user+alias@domain.com) for multiple accounts.

×
×
  • Create New...