Jump to content

Community

Mark

Invision Community Team
  • Content Count

    36,137
  • Joined

  • Days Won

    109

 Content Type 

Profiles

Downloads

IPS4 Documentation

IPS4 Providers

Release Notes

IPS4 Guides

IPS4 Developer Documentation

Invision Community Blog

Forums

Everything posted by Mark

  1. It looks like (though I am still waiting for more details to emerge) that it can be done on standalone websites but you'd need to sign up for Apple's Developer Program, which costs $99/year. We can't create one thing and use it for all sites because each domain and email address you will send emails from to cloaked addresses has to be registered, and there's a limit of 10.
  2. It took a lot of careful consideration and elaborate engineering to come up with the sophisticated solution for keeping track of the entries. But I think it was worth the blood, sweat and tears I poured into it. (It's a .txt file)
  3. If you mean for buying our products: we only accept payments by card or PayPal. But if you mean for taking payments on your own community: our Stripe integration supports iDEAL.
  4. You should invest in a password manager πŸ˜‰
  5. For a straightforward total of all account credit: SELECT SUM( CAST( JSON_EXTRACT( cm_credits,'$.USD' ) AS DECIMAL(20,2) ) ) FROM core_members WHERE cm_credits IS NOT NULL To count only positive amounts (because people can have negative balances): SELECT SUM( GREATEST( CAST( JSON_EXTRACT( cm_credits,'$.USD' ) AS DECIMAL(20,2) ), 0 ) ) FROM core_members WHERE cm_credits IS NOT NULL; Requires MySQL 5.7 or higher. Replace "USD" with the currency code you're using.
  6. I think you may have misunderstood the way the header works. X-XSS-Protection basically provides a way to the browser "if anything on this page looks suspicious, don't run it" (either the whole page or just the bit that looks suspicious). It isn't supported by all browsers (Firefox, for example, doesn't support it). In theory it's a reasonable idea, although a pretty weak protection - it only benefits the users of those browsers from being victims of XSS attacks if your server has already been compromised. Web applications therefore need to take much more sensible measures against XSS protection such as ensuring proper escaping of output (to stop them happening at all), http-only cookies (so even if there is an XSS exploitation it can't access your cookies), etc. We do all of this. So in other words: all it provides is a very weak level of protection against something the backend already has much better protection for. And, as @Makoto points out, it kind of sucks at doing even that; it is known to have bugs and ironically, some of those bugs cause security issues themselves. Also, there are known ways to bypass it. That's probably why some browsers don't even support it. Normally, it would barely be worth any thought and we would leave it at the default value. But it was breaking things with false-positives (i.e. it was thinking that code we deliberately wanted to run was suspicious) so turned it off. Apparently we are not alone in going for this option: I just quickly checked Google and Facebook, and both have it turned off (full disclosure: the other two sites I checked, Twitter and Amazon, don't). You can turn it back online with a plugin or via your server configuration if you really want to, and it's also possible that the Content-Security-Policy header which we do have a setting for will override it (you'll have to check each browser), but we're not going to add a setting specifically for it. -- tldr: It's a thing that isn't supported by all browsers, with a much grander sounding name than it deserves, which is buggy, and was breaking things. You don't need it on.
  7. Have you submitted a ticket so the support team can look into it?
  8. It won't get overridden unless you're uploading the full set of files every upgrade.
  9. Just don't create add any servers - the features sort of have to be specifically enabled.
  10. If you don't want to change anything, you don't have to. Everything will continue working as it does now. If, however, you did want to migrate to Braintree, you have two options: The sensible option is probably to set up Braintree and use it for new purchases. Keep your PayPal gateway set up but disabled to new purchases. That way, new purchases will use Braintree, but any existing billing agreements will continue to churn away without lost revenue. If you wanted, you could cancel all the Billing Agreements with PayPal, and then when it gets to people's expiry dates, they will receive an email asking them to pay, and that would allow them to set up a new billing agreement using Braintree.
  11. You should see this: And then the form your screenshotted is what appears if you click "Continue as New Member".
  12. I still use an RSS client πŸ˜…
  13. PHP 7.1 or higher required (no particular recommendation beyond that other than of course the latest is always a good idea). MySQL 5.5.3 or higher required, 5.6.2 or higher recommended (though again, latest is always a good idea).
  14. There is backwards compatibility so you should be fine πŸ™‚ If you want to update it, we don't have any specific documentation, but if you take a look at one of our login handlers, the methods are all well documented.
  15. Not to the end user. Mostly from people who either didn't read the terms and got their accounts closed or are confused about how chargebacks work (which is not something the gateway has any control over).
  16. End-to-end encryption is not really possible as there is no method for storing the keys in a browser with reliable persistence (unlike in a mobile app). Note that "secret comversations" in Facebook Messenger, for example, can only be created and viewed on their mobile app, not their website.
  17. Not at this time. Most gateways, including Stripe, Braintree, and PayPal, do not allow most types of adult content. It was probably that. Obviously this is out of our control. I have expensive tastes πŸ˜‚ (also specific purchase amounts trigger certain behaviours when in testing mode).
  18. Yes it is. Just like with Stripe you set up each as a separate payment method (but using the same credentials). This allows you to control where they are available (for example, since Apple Pay cannot handle recurring payments you might want to offer that only for products which don't have renewals). They will automatically hide if the user's device doesn't support them (Apple Pay can only be used on Apple products, for example). You can set the "Available To" setting in a payment method (which controls which countries it is available to) to none of them, which effectively "disables" a payment method. You can keep using Stripe for cards and just switch to Braintree for PayPal. If you wanted to switch everything to Braintree to have everything in one location, you would lose cards customers have stored on file (though this would be handled gracefully - they'll just be sent an invoice like they would if their card had expired).
  19. Other than notifying Commerce about a dispute (which does use a webhook), everything is initiated by Commerce's end. If a user revokes permission for the recurring charges from their PayPal account then the next time Commerce tries to charge it, it will treat it the same as it would a declined/expired credit card: it will try to use any other payment methods they have on their account and, failing that, will send them a renewal invoice.
  20. So if there are two packages: one costing $10 and another costing $30, you want a user upgrading between them to be charged $30? Why would the user not make a new purchase and get a full renewal cycle? Wouldn't $20 (which can be achieved by choosing the "Difference between the purchase prices" option) make more sense?
  21. Braintree is a payment gateway provided by PayPal which provides some great additional features for PayPal transactions including a significantly improved recurring payments model. We are delighted to be bringing full support for Braintree for Commerce in Invision Community 4.4. What is Braintree? Braintree is a payment gateway provided by PayPal which supports taking payments by credit cards (including Apple Pay and Google Pay) and Venmo as well as PayPal, providing a good option for communities wanting to use a single payment gateway, and also brings improved functionality for recurring PayPal transactions. For PayPal transactions, there are no additional fees and the checkout experience uses the normal PayPal experience your customers are used to. Recurring PayPal Improvements Recurring payments / Billing Agreements in PayPal have up until now been initiated by PayPal. Invision Community tells PayPal what the renewal terms of a purchase are, but then it's up to PayPal to take that payment and notify your community when it succeeds (or fails). This comes with a number of limitations and problems. It makes it difficult for you as an admin to modify an existing purchase or for the customer to upgrade/downgrade. It also means the customer has to create separate Billing Agreements for each purchase. Most significantly though, it means if there is a delay in receiving the payment (such as an expired card) it is sometimes unclear what should happen on your community's end, and how it can be resolved if/when the payment is received. Other payment gateways work the other way around. When a customer pays by card, for example, they have the option of storing their card details. Later, if they make another purchase or a renewal invoice is generated, Invision Community can tell the gateway to recharge the same card - and if it fails, allow the customer to provide an alternative payment method. This allow both you and your customers to have much greater control, and is much more reliable. Braintree resolves this by allowing customers when paying with PayPal to save their PayPal account in the same way they would save a credit card on file. When paying with PayPal, users will see a simple checkbox which, if checked, will allow future payments to be taken with PayPal automatically. Storing PayPal Accounts for Recurring Payments Other Features In addition to an improved checkout experience, our integration with Braintree supports: Taking payments by Credit Card, including 3DSecure checking and the ability for customer to store card details on file. Braintree uses a fully PCI-compliant method of taking card details in a way that ensures the card information never reaches your server. Apple Pay and Google Pay Venmo, which also allows storing accounts in the same way as PayPal accounts. Offering PayPal Credit Handling chargebacks/disputes Support for Braintree's Advanced Fraud Tools A Disputed PayPal Transaction Existing Setups and Upgrading The existing PayPal gateway will continue to be available for basic PayPal integration, and your existing set up will continue to work exactly as it does now after upgrading. If you are using PayPal, especially if you are using Billing Agreements, we strongly recommend switching to Braintree after upgrading. While it isn't possible to convert existing Billing Agreements, you can allow existing ones to continue to work and use Braintree for new purchases. Please note that while existing setups will work fine, from 4.4 it will no longer be possible to set up a new PayPal method with either Billing Agreements, or to take payments by card, as PayPal has deprecated the API this was using in favour of Braintree and it can no longer be enabled on new accounts. As mentioned though, this does not affect any existing setups, which, if you do not switch to Braintree, will continue to work as they do now. This blog is about our upcoming release Invision Community 4.4.
  22. We have no plans to remove the \IPS\Ftp classes, which are used by the upgrader. But the ability to set up the system to store uploaded files like attachments on an external FTP server was deprecated in 4.3.0 (i.e. 8 months ago).
  23. It's actually still there so people who were using it wouldn't suddenly end up with things broken. You could add a row to the table in the database where the configurations are stored if you really wanted to.... but I wouldn't recommend it. It was notorious for causing errors where the FTP server's flood protection or other limitations would suddenly block the connection and then suddenly the community would be unable to upload anything and have other issues caused by the communication not working. While some who knew what they were doing were able to configure the FTP server in a way that these issues wouldn't happen, it was used by such a small number of communities (like... less than 0.1%) and the percentage of those it caused irreparable issues to was so high, it just made sense to deprecate it. Especially in today's world where more robust solutions like Amazon S3 are available. Or, as you mention, a virtual drive on the webserver.
  24. Happy New Year from Sydney! πŸ™‚
  25. To clarify since @Joel R mentioned me specifically... πŸ˜‚ We will be sticking with CKEditor 4 for a little while. While we will presumably move to CKEditor 5 some time in the future, it is currently still very new and maturing (when Joel asked me, it was before 5.11.2.0 was released which is when they re-added paste from word). But most importantly, to move would require a lot of development time (to upgrade our custom plugins) for what will be, to the end-user, very little change. And since CKEditor plans to continue releasing updates to version 4 for the foreseeable future we're not missing out on bug fixes or security patches. Obviously if you're experiencing issues, please submit a support ticket and we can look into that - if you're not seeing the same problems on CKEditor's demo, the problem is likely our end and so it's probable that moving to CKEditor 5 wouldn't resolve it.
Γ—
Γ—
  • Create New...