Jump to content

Leaderboard


Popular Content

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

  1. 1 point
    original code from the thread below... <?php use WHMCS\View\Menu\Item as MenuItem; add_hook('ClientAreaPrimarySidebar', 1, function (MenuItem $primarySidebar) { GLOBAL $smarty; $templatefile = $smarty->getVariable('templatefile'); $client = Menu::context('client'); if (!is_null($client) && in_array($templatefile, array('clientareahome'))) { $SupportPIN = generatePinCode($_SESSION['uid'], 8); $primarySidebar->addChild('Support-Pin', array( 'label' => "Pin de Soporte", 'uri' => '#', 'order' => '10', 'icon' => 'fa-ticket' )); $primarySidebar->getChild('Support-Pin')->setBodyHtml($SupportPIN); } }); the second hook in the file would remain the same as that refers to the admin area.
  2. 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.
  3. 1 point
    Include once includes/registrarfunctions.php and then call the module function via MyCustomRegistrarModule_myfunction($params) ; registrarfunctions.php should be loading the registrar modules and the function will then be available. Just do a function_exists check first .
  4. 1 point
    My short answer: I only want to change a couple things in the CSS. I don’t want to maintain and diff an entire template every time I update for a small security patch. Perhaps a “custom css” field in the admin area would be a better fit for this.
×
×
  • 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