Jump to content

Callum MacGregor

Clients
  • Posts

    80
  • Joined

  • Last visited

  • Days Won

    1

 Content Type 

Downloads

Release Notes

IPS4 Guides

IPS4 Developer Documentation

Invision Community Blog

Development Blog

Deprecation Tracker

Providers Directory

Forums

Events

Store

Gallery

Everything posted by Callum MacGregor

  1. I got it working now. Thanks @Adriano Faria for offering to help. I had to create a dummy extension in admincp, then the extensions.json was created correctly. This is exactly why I am so reluctant to upgrade Invision to newer versions.
  2. I don't have an extensions.json file, its an old application. I'll try and create it myself.
  3. Its my own application. For a bit more information, in the admincp the extension does show up as expected: However, I logged what ItemsIterator collects from \IPS\Application::allExtensions call, and my extension is no longer listed there:
  4. I have an application that creates a custom commerce package, extending \IPS\nexus\Invoice\Item\Charge. Up until the latest update it worked fine, but since the latest update the ItemsIterator expects all extensions to be in the 'nexus' application, and therefore cannot load the class of my package object. How it works now, I don't think its possible any more to create custom chargable items, but I desperately need this functionality.
  5. You're right, its working as intended. I would say that opting to store billing details wouldn't necessarily count as giving consent for continuous billing; but that's a separate issue. But back to the main topic: please could I officially request the ability to disable automatic billing for account credit? Or if its not possible to do it on a granular level, to disable automatic billing entirely for all payment methods.
  6. There is no such setting for account credit, so payment is taken for users automatically who have enough account credit to cover it. EDIT: Sorry I forgot to clearly clarify in the original post that this affected account credit only.
  7. In the automated task generateRenewalInvoices.php, Commerce will try to automatically take payment when a renewal invoice is generated (and a billing address is stored). While I don't think this is wrong necessarily, its not behaviour I desire, and my customers definitely do not want this. The offending line of code is: /* Try to take payment automatically, but *only* if we have a billing address (i.e. the customer has a primary billing address set) otherwise we don't know how we're taxing this and the customer will need to manually come and pay it - we can skip this if tax has not been configured */ if ( $invoice->billaddress OR \count( $availableTaxes ) === 0 ) I would request to have an option to disable this, as right now I have to comment this code out manually to prevent my users from being charged automatically (even if it is to account credit). Kind Regards.
  8. Thanks for reporting it as a bug. I'll await the fix as it does appear to still be an issue even in the latest update.
  9. User ID: 105995 The user is banned now, for obvious reasons, but wasn't at the time. EDIT: I actually think I might know why. Maybe Maxmind changed their API results format, because in the code within Rule.php, the expected syntax is 'riskScore'. But in the maxmind API response, its 'risk_score'. Rule.php: /* Score */ if ( $this->maxmind ) { if ( !$this->_checkCondition( $maxMind->riskScore !== NULL ? $maxMind->riskScore : round( $maxMind->score * 10 ), $this->maxmind, $this->maxmind_unit ) ) { return FALSE; } } Maxmind API response for this particular transaction (redacted): risk_score : 99
  10. Hello I think commerce fraud rules are broken. I had a transaction that came back with a 99% risk score from maxmind, but was approved anyway, despite the second rule in my anti-fraud rule set being to refuse any transaction with a score greater than 55%.
  11. Email ticket support is not primarily how it works. Its an optional component to the ticket system that without, it can continue to function perfectly fine.
  12. Why bother paying your developers when your customers will do it for you for free, right? Same attitude that EA takes with "LiVe SupPorT" aka using paying customers to test their unfinished games for them with no cost.
  13. From the link you sent I can see this, which is the app I need to update. How did it even expire to begin with? Anyway, if I go through the marketplace in my admincp to update the app (as is the recommended way), I am only shown the option to re-purchase again at full price:
  14. It seems like every time I need to update an app, I have to buy it at full price again, despite having done that multiple times? If I buy an app it should be mine, this subscription model is just capitalist madness. Same goes for an IPS update: it seems like every major IPS update breaks every app I own, then I have to rebuy all the apps again in order to get the fixed version. As it stands, I am just not updating my IPS installation any more because of this exact situation. Who made the decision to employ this model, and what is my motivation to upgrade if every time I do I have to spend a bunch of money on getting a fixed app?
  15. Line 1224 in applications\nexus\sources\Fraud\Rule.php is currently: 'subscriptions' => iterator_to_array( \IPS\Db::i()->select( 'p_id', 'nexus_member_subscription_packages' ) ), But should be 'subscriptions' => iterator_to_array( \IPS\Db::i()->select( 'sp_id', 'nexus_member_subscription_packages' ) ), Trying to check my anti-fraud rules in the admincp results in the following exception due to the this faulty code: SELECT p_id FROM `nexus_member_subscription_packages` IPS\Db\Exception: Unknown column 'p_id' in 'field list' (1054) #0 /var/www/vhosts/[snipped]/httpdocs/system/Db/Select.php(388): IPS\_Db->preparedQuery() #1 /var/www/vhosts/[snipped]/httpdocs/system/Db/Select.php(446): IPS\Db\_Select->runQuery() #2 [internal function]: IPS\Db\_Select->rewind() #3 /var/www/vhosts/[snipped]/httpdocs/applications/nexus/sources/Fraud/Rule.php(1224): iterator_to_array() #4 /var/www/vhosts/[snipped]/httpdocs/applications/nexus/sources/Fraud/Rule.php(102): IPS\nexus\Fraud\_Rule->isSubsetOf() #5 /var/www/vhosts/[snipped]/httpdocs/system/Patterns/ActiveRecord.php(335): IPS\nexus\Fraud\_Rule->get__description() #6 /var/www/vhosts/[snipped]/httpdocs/system/Node/Controller.php(223): IPS\Patterns\_ActiveRecord->__get() #7 /var/www/vhosts/[snipped]/httpdocs/system/Node/Controller.php(113): IPS\Node\_Controller->_getRow() #8 /var/www/vhosts/[snipped]/httpdocs/system/Helpers/Tree/Tree.php(130): IPS\Node\_Controller->_getRoots() #9 /var/www/vhosts/[snipped]/httpdocs/system/Node/Controller.php(99): IPS\Helpers\Tree\_Tree->__toString() #10 /var/www/vhosts/[snipped]/httpdocs/applications/nexus/modules/admin/payments/fraud.php(66): IPS\Node\_Controller->manage() #11 /var/www/vhosts/[snipped]/httpdocs/system/Dispatcher/Controller.php(118): IPS\nexus\modules\admin\payments\_fraud->manage() #12 /var/www/vhosts/[snipped]/httpdocs/system/Node/Controller.php(69): IPS\Dispatcher\_Controller->execute() #13 /var/www/vhosts/[snipped]/httpdocs/applications/nexus/modules/admin/payments/fraud.php(54): IPS\Node\_Controller->execute() #14 /var/www/vhosts/[snipped]/httpdocs/applications/nexus/modules/admin/payments/paymentsettings.php(81): IPS\nexus\modules\admin\payments\_fraud->execute() #15 /var/www/vhosts/[snipped]/httpdocs/system/Dispatcher/Controller.php(118): IPS\nexus\modules\admin\payments\_paymentsettings->__call() #16 /var/www/vhosts/[snipped]/httpdocs/system/Dispatcher/Dispatcher.php(153): IPS\Dispatcher\_Controller->execute() #17 /var/www/vhosts/[snipped]/httpdocs/minad/index.php(13): IPS\_Dispatcher->run() #18 {main}
  16. Thanks for this, I have forced a password reset. Also thanks @Marc Stridgen for your assistance. I'll consider this resolved now.
  17. I was searching for a way to do this but couldn't find any. Is there an option within admincp?
  18. Yes, ok, I see your point. Even if the member control panel would be inaccessible the attacker could still just set up 2fa and access it thereafter... In that case, can you recommend any security settings in the admincp that would mitigate this? @Marc Stridgen
  19. To give you some context, a database leak from my site (from 2016, before I started using Invision), surfaced on the web. Many users do not use password manager and use the same password for all sites they visit. Consequently, a malicious actor could (and has) obtained the leak, grabbed some passwords and logged into to user accounts. Even with 2fa on, they were able to get into the account, change the passwords and email addresses, and hijack control of many user accounts. This, to me, seems like a major security flaw. In my mind, a user shouldn't be able to change such important information when 2fa is on. Until they have verified 2fa and correctly set it up, this area should not even be viewable let alone able to manipulate member info.
  20. Hello One of my members alerted me to a bug by which any user can bypass the 2fa check. To replicate: Sign into a new account that has not yet set up 2fa, when prompted to set it up simply edit the URL so that it only contains https://<domain>/settings rather than the 2fa generated url (https://<domain>/settings/?do=initialMfa&ref=<ref>) By doing this, a user can enter the member control panel and has the ability to change username, password, email etc - completely negating the purpose of 2fa! If needed I have a video demo I can DM to a dev/admin but don't really want to post it publicly. Thanks
  21. I've updated the market place listing to support 4.4
  22. As the developer of Support Ticket Notifications, I can tell you it still works. It hasn't been updated only because it doesn't need updating.
×
×
  • Create New...