LaCollision

Thanks for your sound advice, I'll keep that in mind.

Not to mention a government website. Any respectable-sized company today has become so procedural that they make you sign a 4 zillion-page document when you want to develop an HTML page for their website. All I'm saying is that, as a developer, exposing the database structure of a customer's application is really frowned upon. The reasons are obvious. There shouldn't even be a debate about this.

Of course, anyone can retrieve the basic structure of Invision applications, no doubt about it. But for developers who sell their applications to customers, I find this rather awkward. Let's imagine an important customer who orders an application to enhance his Invision community site. And let's imagine that this application contains more sensitive information than the default Invision databases. The developer will create an application specifically for the customer's needs. And I don't find it particularly comfortable to tell the customer "Yes, your database structure is freely accessible on the web, but don't worry, it's not a big deal".

I'm well aware that these files have been there for eternity; for so long that we no longer even question their existence. Well, I find that freely exposing the structure of databases, application parameters (even if these are their default values), or all URLs, well, I don't find that very reassuring for a potential customer. Publicly displaying database structures mechanically exposes applications to SQL injection attacks much more easily.

Hi, I've just realized that all applications information in JSON and XML formats is freely available on the web. For example: https://invisioncommunity.com/applications/core/data/schema.json https://invisioncommunity.com/applications/core/data/settings.json https://invisioncommunity.com/applications/core/data/furl.json => Isn't it dangerous to leave sensitive information such as the database structure of all applications, default settings, or even all existing URLs accessible? For example, settings.json contains the parameter recaptcha2_private_key… This applies not only to Invision applications, but also to third-party applications. Thank you,

I can confirm that this bug is present in other parts of Commerce. For instance in \IPS\nexus\Package->upgradeDowngrade(), at line 3524: try { $currency = $purchase->original_invoice->currency; } catch ( \OutOfRangeException $e ) { $currency = $purchase->member->defaultCurrency(); } Here, the consequence of this bug is that after upgrading/downgrading, the purchase ends up with a currency different from its current currency. If we go back to the example in my message above, then a purchase currently in Euros will end up in US dollars after the upgrade/downgrade. To solve this bug, the solution is the same: $currency = $purchase->renewal_currency; Thank you,

Hi team, I think I may have found a bug in Commerce, where the cost to upgrade a package is calculated. In \IPS\nexus\Package->costToUpgrade(), at line 3334: try { $currency = $purchase->original_invoice->currency; } catch ( \Exception $e ) { $currency = $purchase->member->defaultCurrency(); } The $currency used for the calculation is either the purchase original currency, or the member default currency. But then, at line 3423, a difference is calculated: $diff = $purchase->renewals->diff( $renewalTermToUse ); And if the $currency calculated above is different from the current package currency, this difference throws an exception: DomainException currencies_dont_match /applications/nexus/sources/Purchase/RenewalTerm.php 257 In /applications/nexus/sources/Purchase/RenewalTerm.php, at line 257: /* Sanity check */ if ( $this->cost->currency !== $otherTerm->cost->currency ) { throw new \DomainException('currencies_dont_match'); } That's because the 2 RenewalTerms don't have the same currency. Let's get an example: I create a purchase with renewals, for instance in US $. So we have $purchase->original_invoice->currency = 'USD' Later, I change the purchase renewals for a new currency; Euros for instance. Now, I cannot upgrade my initial purchase, as a 'currencies_dont_match' exception is thrown. This exception is thrown because the difference in the cost to upgrade is calculated between a purchase in USD, and my current package currency, which is Euros. To solve this issue, we should have in \IPS\nexus\Package->costToUpgrade(), at line 3334: $currency = $purchase->renewal_currency; … instead of : try { $currency = $purchase->original_invoice->currency; } catch ( \Exception $e ) { $currency = $purchase->member->defaultCurrency(); } In this way, the difference will be correctly calculated between two identical currencies, rather than between the currency of the original invoice and my current currency. Please note that this bug may be present in different parts of Commerce. There are indeed several instances of '->original_invoice->currency' in Commerce source code, and I think some of them might lead to the 'currencies_dont_match' exception. Thank you for your help!

Hi team, The bug mentioned in my first post has been corrected, thank you. However, I realize that there's another bug in the same part of the code: In \IPS\nexus\Package, at line 3579: if( !$diff->invert and $diff->days > 0 ) { $purchase->expire = $purchase->start->add( $diff ); } The problem is that the above code adds the $diff difference to the purchase date, which is incorrect. Let's take an example: Today is December 7, 2023. The purchase date is November 12, 2023. The initial term is 1 month. We therefore have : $initial = new \DateInterval( "P{$newPackage->initial_term}" ) = 1 month $diff = \IPS\DateTime::create()->diff( $purchase->start->add( $initial ) ) = difference between today and (purchase date + initial term) = difference between December 7 and (November 12 + 1 month) = difference between December 7 and December 12 = 5 days The code : $purchase->expire = $purchase->start->add( $diff ); ... will then set the purchase expiry date to : $purchase->expire = $purchase->start->add( $diff ); = November 12 + 5 days = November 17 ... whereas the expiry date should be December 12. This code therefore causes the purchase to expire prematurely: it is considered to have expired on November 17, whereas it should be valid until December 12. To correct this problem, add to $purchase->start the initial term, not the difference in days. The correct code should be as follows: $purchase->expire = $purchase->start->add( $initial ); Thank you for your help!

Hi Marc, Thanks for your reply! By analyzing the Apache logs, I found that the problem comes from SendGrid calls: "POST /applications/core/interface/incomingemail/sendgrid.php HTTP/1.1" 500 4540 "-" "Sendlib/1.0" In \Email\Incoming\Email, there is indeed at line #523: $body = $parser->parse( $body ); We can see this parse() method calls the \Text\Parser->_parseContent() method… which is exactly where I have the issue of a PHP Fatal error (maximum execution time of 240 seconds exceeded): if ( $img->hasAttribute( 'data-ipsEmoticon-plain' ) ) So, there might be an issue with the method analyzing SendGrid calls. But now… it's beyond my capabilities! 😅 It would be interesting for the Invision development team to take a look at this issue. Thanks again,

Hi! Every 3 hours, I can see in my PHP logs: Has anyone ever encountered this problem, and knows where it might be coming from? Its regularity (every 3 hours) makes me think of a task that cannot be completed. Thanks a lot! 🙏🏻

Thanks a lot!

Hi team, I have no news about this issue? Thank you,

Hi Team, I think there is a bug in the Commerce app for the Package->upgradeDowngrade() method. When upgrading or downgrading, you check if the new Package has a longer initial term, and then modify the current $purchase->expire date accordingly. In \IPS\nexus\Package, in upgradeDowngrade(), at line 3533: /* Initial Term, apply the difference if the new package has a longer initial term */ if( $term and $newPackage->initial_term ) { $initial = new \DateInterval( "P{$newPackage->initial_term}" ); /* If we're still in the initial period of the new package */ $diff = \IPS\DateTime::create()->diff( $purchase->start->add( $initial ) ); if( $diff->days > 0 ) { $purchase->expire = $purchase->start->add( $diff ); } } You calculate the difference between now and (the purchase start date + the initial term): $diff = \IPS\DateTime::create()->diff( $purchase->start->add( $initial ) ); Then you check if this difference has days: if( $diff->days > 0 ) The issue is the following: the $diff->days will always be positive, as you forget to check if the difference is negative. As a result, the $purchase->expire date could be set in the past, which is really problematic. The correct test, at line 3540, should be: if( !$diff->invert && $diff->days > 0 ) Thank you!

Hi, I found a typo in \Email\Incoming\Email::route(), line 709 : $analyze = NULL; This var is then called « $analyse » in the rest of the code: switch ( $row['rule_criteria_field'] ) { case 'to': $analyse = implode( ',', $this->to ); break; case 'from': $analyse = $this->from; break; case 'sbjt': $analyse = $this->subject; break; case 'body': $analyse = $this->message; break; } /* Now check if we match the supplied rule */ switch ( $row['rule_criteria_type'] ) { case 'ctns': $match = (bool) ( mb_strpos( $analyse, $row['rule_criteria_value'] ) !== FALSE ); break; case 'eqls': if ( mb_strpos( $analyse, ',' ) !== FALSE ) { $match = (bool) \in_array( $analyse, explode( ',', $analyse ) ); } else { $match = (bool) ( $analyse == $row['rule_criteria_value'] ); } break; case 'regx': $match = (bool) ( preg_match( "/{$row['rule_criteria_value']}/", $analyse ) == 1 ); break; } This has no impact thanks to the switch, bit it's still a typo 🙂 Thank you,

Perfect! Thanks a lot to both of you