Jump to content


Popular Content

Showing content with the highest reputation on 11/18/20 in all areas

  1. 1 point
    If you have WHMCS on a server that you have WHM access to, it's in tweak settings. Look under mail for "Track email origin via X-Source email headers" and shut it off. That should resolve it. Of course, it sounds like you have your billing system on a server where you have clients, which is typically a lot less secure...
  2. 1 point
    This explains it pretty well. It's not WHMCS, but php. https://www.the-art-of-web.com/php/x-php-script/
  3. 1 point
    I don't think there is such a rate limiter built-in. A ticketopen hook might work to then add the email address to the block list. This would need to have a tracking mechanism to determine how fast they are opening tickets and cron hook to then unblock after x amount of time. Is the tickets being opened via email or the client area ? If via email, on your side make sure your SPF record is correct and set to reject non-listed sources via the "-all" instead of "~all" which is a soft fail. On the other side, they would of course need to be checking SPF but most spam systems do that. If via the client area, a clientarea hook could do tracking via $_SESSION and block via like a redirect or a header 403 maybe.
  4. 1 point
    well this is Kian's baby, but there is a line in the hook... $invoiceAmount = false; // Auto-accept order only if invoice amount is >= $invoiceAmount. Set false to auto-accept everything (Important: currency conversion not supported) if you only have one currency, USD, then you could change that false to 21 and you should be good to go. if you have multiple currencies in WHMCS, then you might need to find the currency of the invoice and alter the hook coding accordingly.
  5. 1 point
    Readonly is an HTML field in the browser. Did you tried deleting that and changing to see if it works? Right click, inspect, remote the read only and try to change the data and see if it works. Agree, the fields should be permissions/roles. I'm the top admin of my installation, I should be able to change anything I want. I already can because I have just change the database fields directly. This is just WHMCS making it more annoying and less productive since now instead of just clicking and typing directly something in the admin interface I need to do it directly on the database. Somehow WHMCS thinks its a great approach to make you less productive. I don't understand what they are trying to achieve with that stuff. Its my database and my data, I can change anything they want when I want. Locking us out from the interface will have no effect, developers will just create a hook or an alternative admin theme that works as expected.
  6. 1 point
    the same as you would with any orderform template - you would either define it as the default orderform from setup -> general settings -> ordering, and/or you would individually assign it to be used in specific product groups.
  7. 1 point
    I know plenty of enterprise systems, far better in security than WHMCS. All of them (admin back end) lets you force a user password change. What purposes does a back end have if you cannot manipulate data...???? From a security standpoint removing this has NO, ZERO effect on the account's security. Forcing a user's password is still hashed, it's not saved in clear text. No risk involved. If WHMCS assumption is here "We don't want, you to know YOUR customers password" this is idiotic. It's my customer, not theirs. As you said, you can just use a dummy email account and still know the password, they now just add another layer of complication to the equation. Also, we already have full access to the database, I can manually change whatever password I want and still know my customers passwords because it's my data. And without mentioning that, well WE DON'T need the customers password in the first place as we can just impersonate the account. We don't care about the user's password. And finally, you can make a hook that does the same. What is the purpose of WHMCS removing this besides making it more complex and killing an especially useful feature in the back end? The only thing that comes to my mind is they don't want your staff to randomly change users' passwords. If this is the WHY they did this, it's a dumb approach. They should just add a permission and problem solved. That way we as admins can set specific staff users not to have the option to change a password or impersonate a user. Therefore permissions exist and you can give or remove specific permissions to your staff. Now completely removing the function is just going nuclear and making the whole admin side less useful. It makes no sense. Forcing a user's password change is one of the most, if not the most common tasks someone will look on a user's account. It seems WHMCS thinks that everyone using WHMCS just has random users online from a website. Don't they understand that some of us know our customers in person? And they are in front of us and we need to tell them now "Sorry, our fancy billing system does not let us change your password manually" This is seriously a joke. An admin software that does not let you change user's password. Then again, I'm not surprised because in v8 it seems you cannot remove users either. People are complaining about this because they either did not upgraded yet or are not even aware something this BASIC was removed from the customer profile. The devil in me tells me something different. I suspect why they are removing things like that. WHMCS is trying to slowly kill the self-hosted edition of WHMCS and move it to a cloud service. Then it makes no sense to offer things like this because you don't have access to the database. Their whole final idea is lock in. The self-hosted edition will be killed, and you will have to pay them monthly to use WHMCS and store your database with them. And your data and customers is now theirs. And eventually they will even email your customers directly and try to sell them things directly and claim it was a mistake. I saw this so many times. This is speculation but this is the only reason I can think why they don't added features like removing sub accounts in v8 or why they remove the password change feature. If someone takes a deep look at what they are adding in terms of features and removing, it all points to a version that will be cloud only and self-hosted killed. This is why they are slowly locking things down more and more and removing things that only makes sense on a self-hosted server edition. WHMCS will claim otherwise but just see each release and what brings and what it removes, and all things start to make sense. I suspect our future with WHMCS is already compromised. I refuse to believe they are doing this things by mistake because nobody would think removing something like this makes any sense at all or not adding a way to remove sub contacts in v8. The reason is they don't need customers to remove things. In their cloud service they will bill per users and customers and they will remove them from their back end. They don't want you to manipulate the database because it will be billed from their side. They already are moving towards that, owned license cannot be purchased anymore. Only leased. Then they introduced it billing by number of customers (your WHMCS now transfers that data) and they already confirmed here in the community that they plan a cloud hosted edition. Eventually they will move towards that and bill for everything, based on the number of customers, products, etc. Maybe even a % of your income in the future. This is why the marketplace makes so much sense for them. Of course they will lose most customers that cannot host billing & users data with them for compliance and regulatory reasons. But I suspect they don't care. Lucky for us, there are alternatives. I'm very disappointed with how the future looks with WHMCS because there is none for us that host it with our own servers. Granted, this is all speculation but the changes they are doing since version 6 are pointing towards that. Its all about vendor lock in.
  8. 1 point
  • Create New...

Important Information

By using this site, you agree to our Terms of Use & Guidelines and understand your posts will initially be pre-moderated