Matt

Hi Sonya, this looks to be a bug. I'll raise a bug report on this.

Hi, I've moved this to a ticket, one of our developers will claim it shortly.

We check for a bad key, if we detect this more than once in 5 minutes, then we return a 429 header ('TOO_MANY_REQUESTS_WITH_BAD_KEY', / '1S290/D') We can also return a 403 header 'IP_ADDRESS_BANNED' on subsequent checks if a bad key has been used with this IP address more than 10 times. Using an incorrect API key, \IPS\Api\OAuthClient::accessTokenDetails() failing, or trying to set a scope that doesn't exist/not having any scopes can trigger bad keys being added to the error log.

I agree, having a user option to turn these off would be useful.

@Jonas Erlandsson What sort of guides would you like to see?

Hey Russell, In an ideal world Facebook would have an open embed endpoint and we could use that. Sadly they don't, so you need to set up an App at Facebook and get it through approval. More info here:

Thanks for the through and detailed feedback. I'm sorry that you had issues with the disable/enable 3rd party customisations tool. Generally we find this to be robust but as with anything in code, it's possible edge cases arise. I'll happily take any logs or information you may have as to way your custom app failed to come back online so we can look for any issues with our code. I realise it's the "can you turn off your modem and turn it back on again" step is frustrating but when you come onto our side of the fence, you see dozens of tickets a day where something is broken, so we investigate and it sometimes goes through a T1 tech (20-30 mins) then into a developer (60-90 mins) to determine that it's an issue with third party code. This happens daily. In your case with a skilled developer, there's only a slim chance it's the case, but we have to pitch this at the lowest common denominator unfortunately. We are in a bit of a bind as we're committed to low renewal fees, so the forum app renews at $80/year or just under $7 a month. This doesn't cover a lot of support time or development time, so we really have to make it as streamlined as possible. It's why we're still able to offer email support for our cloud community plans. I would imagine it's why Rackspace are also able to offer support. In terms of documentation, we do review it but not as often as we would like to. That's a fair comment and I'll review our policy.

It's worth noting that posts not claimed by post by register are automatically removed after a short period of time and never shown on your community.

Unfortunately as this domain is in our cloud system, there isn't a static IP address assigned. May I ask why you need to whitelist it?

Hello, I'm sorry for the delay. There was an issue with your payment which needed a senior member of the team to investigate for you. I believe this took significantly less time than the 10 days you mention, however. General support issues are answered generally within a day but billing issues do take a little longer to resolve as fewer of our team have access to those systems.

Hi, I'm a little confused as to what help you need, if you let us know what you need a hand with, we'll be happy to assist. As always, if a ticket needs investigation by a developer or is sensitive in nature, one of our team will convert it into a private email ticket for you. Thanks

It would be tricky as RSS doesn't really have a provision for nested items. It would need to send each comment with a unique URL and ID, which would mean some sort of processing would be needed to nest them on the other side.

What would this look like?

I've just raised a bug report for this (6503). We'll get it fixed.

This issue is in our tracker. It's quite complex based on the editor we use, but we are aware of it.

I'm reviewing this for you. I would suggest restoring the default .htaccess file which can be downloaded via ACP > Search Engine Optimisation > Friendly URLs (the link is in the description of the setting 'Rewrite URLs'. invisioncommunity.com/ and invisioncommunity/index.php will both load without a redirect. The htaccess file looks for files that do not exist and rewrite based on that. index.php does exist, so this will not be rewritten or redirected. https://invisioncommunity.com/forums/index.php is not a real page and there is not a friendly routing path of that specific URL. /forums/ is a "fake" directory itself. Likewise https://invisioncommunity.com/forums/topic/index.php is not a real page and will result in an error page. I think the software is working as expected for you.

It's why you guys are the best. You help make us better.

Ok, I've added an issue in our tracker to restrict the JS to just Nexus.

Fair points, I'll take it to the team.

Stripe records this information to help detect suspicious activity as part of their fraud management. https://stripe.com/docs/disputes/prevention/advanced-fraud-detection

There is no limit right now. I'll add it to our internal tracking.

I'm not sure why this happened. It's possible an upgrade removed some of the metadata from the template row which allows it to be used for specific database views.

The most common reason for a CSRF failure would be a change of session ID. Have you noticed any issues with sessions recently?

That reminds me, I need to search the database for ... something.