dragonfly411

More people are affected.
https://twittercommunity.com/t/wordpress-fails-to-embed-tweets/194433

The only thing exposed with that is IPS version 4.  That is more than 7 years of releases.  In fact well more than 100 releases during that time frame.  There is not a lot of information exposed even if there was someone motivated enough to look. 

A real attacker would be able to tell a site is using IPB simply by viewing the source and looking at the structure of the code to figure out a site is using IPB. The purpose of removing a SPECIFIC version number such as 4.6.1 is to prevent exploit of something that might uniquely exist in that version. This does not expose that. 

Follow-up on the AWS S3 configuration issue I encountered
https://invisioncommunity.com/forums/topic/465562-aws-s3-storage-http-400-issue-v4610/
Just a suggestion for feature improvements to save potential bandwidth costs 🙂
S3 Outgoing bandwidth costs money and we host video uploads as well. So I had given public access via a policy and set a Referer condition to limit bandwidth leaching.
This works for own uploads but not for forum uploads as IPB explicitly grants public LIST access.
Policy on the bucket
{ "Version": "2012-10-17", "Statement": [ { "Sid": "PublicReadGetObject", "Effect": "Allow", "Principal": "*", "Action": "s3:GetObject", "Resource": "arn:aws:s3:::MyBucketName/*", "Condition": { "StringLike": { "aws:Referer": [ "https://www.domain.com/*", "https://domain.com/*" ] } } } ] } Permissions set by IPB

Just a suggestion for feature improvements to save potential bandwidth costs 🙂
S3 Outgoing bandwidth costs money and we host video uploads as well. So I had given public access via a policy and set a Referer condition to limit bandwidth leaching.
This works for own uploads but not for forum uploads as IPB explicitly grants public LIST access.
Policy on the bucket
{ "Version": "2012-10-17", "Statement": [ { "Sid": "PublicReadGetObject", "Effect": "Allow", "Principal": "*", "Action": "s3:GetObject", "Resource": "arn:aws:s3:::MyBucketName/*", "Condition": { "StringLike": { "aws:Referer": [ "https://www.domain.com/*", "https://domain.com/*" ] } } } ] } Permissions set by IPB

 

Thanks Dude! Saved my bacon, I would have NEVER EVER figured this one out, and had already invested hours of doing it over and over again hoping for a different result.

Follow-up on the AWS S3 configuration issue I encountered
https://invisioncommunity.com/forums/topic/465562-aws-s3-storage-http-400-issue-v4610/
Just a suggestion for feature improvements to save potential bandwidth costs 🙂
S3 Outgoing bandwidth costs money and we host video uploads as well. So I had given public access via a policy and set a Referer condition to limit bandwidth leaching.
This works for own uploads but not for forum uploads as IPB explicitly grants public LIST access.
Policy on the bucket
{ "Version": "2012-10-17", "Statement": [ { "Sid": "PublicReadGetObject", "Effect": "Allow", "Principal": "*", "Action": "s3:GetObject", "Resource": "arn:aws:s3:::MyBucketName/*", "Condition": { "StringLike": { "aws:Referer": [ "https://www.domain.com/*", "https://domain.com/*" ] } } } ] } Permissions set by IPB

Correct so done
 

Correct so done
 

When using facebook logins you had to have a facebook developer account and create a facebook app so that's nothing new, not sure why IPS can no longer support oEmbed,
Once again a developer has stepped in and restored the feature back so quickly, not knocking the developer of the plugin. They all have my respect and thanks for restoring dropped features or improving the IPS software. Thank you all
At this particular time i have to stop buying plugins as they all total up per year and start to make the software expensive.