Jump to content

Community

Mark

+Clients
  • Posts

    36,207
  • Joined

  • Last visited

  • Days Won

    113

Reputation Activity

  1. Haha
    Mark reacted to Matt in Thank you IPS for detailed changelogs since 4.3.5   
    I'll take the credit, even though it was really @Mark who pushed for it.
  2. Like
    Mark got a reaction from AtariAge in New registration notifications by email stopped v4.4.3   
    Sorry about that. Will be fixed in our next version.
  3. Like
    Mark got a reaction from Meddysong in 2 Factor Auth via e-mail   
    Two Factor Authentication significantly improves your security and is certainly not just dumbing things down.
    Generally speaking, there are three ways of proving you are who you say you are: knowledge factors (something you know, like a password), possession (something you have, like a mobile phone) and inherent (something you are, like a fingerprint).
    Using a strong password helps address some of the shortfalls of the knowledge factor - it protects you against someone trying to guess (or bruteforce) your password. However, it doesn't prevent you against a variety of other attacks (for example, if someone was able to compromise your system and install a key logger).
    But two factor authentication adds an additional factor into play: usually a possession factor. In addition to providing your (hopefully strong) password, it requires you to prove that you have in your possession a device which belongs to you.
    It should be used whenever available, especially for things which require additional security.
     
     
    To address the original question: email is generally not a great 2FA method as it is already the method of recovery if a user forgets their password. If you use email as the second authentication factor, it means an attacker only has to gain access to the desired victim's email account in order to compromise their account - which effectively brings you back to a single-factor authentication system.
  4. Like
    Mark reacted to Lindy in Dismiss recommendations   
    Is there a reason you're opposed to following the recommendation? 
  5. Like
    Mark got a reaction from Claudi in New registration notifications by email stopped v4.4.3   
    Sorry about that. Will be fixed in our next version.
  6. Like
    Mark got a reaction from Joy Rex in New registration notifications by email stopped v4.4.3   
    Sorry about that. Will be fixed in our next version.
  7. Thanks
    Mark got a reaction from Markus Jung in New registration notifications by email stopped v4.4.3   
    Sorry about that. Will be fixed in our next version.
  8. Like
    Mark got a reaction from Fierce God in New registration notifications by email stopped v4.4.3   
    Sorry about that. Will be fixed in our next version.
  9. Like
    Mark got a reaction from Elshara Silverheart in Use payment options like iDeal and wire transfer   
    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.
  10. Like
    Mark reacted to Nathan Explosion in Will you complete the API?   
    Why don't you tell them what endpoints it is that you want/need, so that they understand what it is that you want/need?
  11. Like
    Mark got a reaction from Adriano Faria in Password Recovery   
    You should invest in a password manager 😉 
  12. Like
    Mark got a reaction from sobrenome in Displaying only date, year etc from a JSON date   
    Or if you do...
    $timestamp = strtotime( $res['date'] ); ... then you can do...
    date( 'j', $timestamp ) // Day date( 'n', $timestamp ) // Month date( 'Y', $timestamp ) // Year See https://www.php.net/manual/en/function.date.php for other values you can use instead of j/n/Y
    Or if this is within Invision Community you can do...
    {datetime="strtotime( $res['date'] )"} To get the "relative" date
  13. Like
    Mark got a reaction from media in Password Recovery   
    You should invest in a password manager 😉 
  14. Like
    Mark reacted to Adriano Faria in Format of dates - Long   
    A lang bit para a index e forum view é _date_this_year_long.


  15. Thanks
    Mark got a reaction from Cyboman in Where to see total outstanding amount owed to contributors?   
    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.
  16. Thanks
    Mark got a reaction from SJ77 in Where to see total outstanding amount owed to contributors?   
    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.
  17. Like
    Mark reacted to Colonel_mortis in X-XSS- Protection   
    I've not read through the whole topic in detail. However, for what it's worth, enabling X-XSS-Protection (XXP) breaks embeds in Safari under certain circumstances.
    Also, XXP has absolutely nothing to do with ddos attacks, it is just a rudimentary safeguard against reflected XSS attacks.
    Of the handful of XSS attacks that I can recall finding in IPS, only one could be blocked by XXP (and as it happens, it was on a page where XXP was enabled and the attack was blocked in the browser which support it).
  18. Like
    Mark got a reaction from Rhett in X-XSS- Protection   
    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.
  19. Like
    Mark got a reaction from Makoto in Where to see total outstanding amount owed to contributors?   
    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.
  20. Like
    Mark got a reaction from Joriz in X-XSS- Protection   
    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.
  21. Like
    Mark got a reaction from Makoto in X-XSS- Protection   
    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.
  22. Like
    Mark reacted to Makoto in X-XSS- Protection   
    It's not an opinion, it's a matter of fact.
    IPS utilizes Content-Security-Policy headers in place of X-XSS-Protection by default (though you can explicitly disable these, it is strongly discouraged).
    There is nothing to "fix." No matter how much you repeat that. It's working as intended. X-XSS-Protection is not necessary on modern browsers when CSP is utilized, which it is on IPS.
    You probably just read this off one of the hundreds of random automatic website scanners you use all the time and think because it reported this header was missing IPS absolutely must use it, without actually understanding what the header does or why it is not actually used.
    Funnily enough, not only is X-XSS-Protection flawed and prone to being bypassed, enabling X-XSS-Protection can and has introduced new security vulnerabilities in the past, and even Facebook has had to disable it due to a bug that allowed attackers to hijack your account.
    So please read up on things before you complain that IPS is not doing their jobs properly or that their code is broken, when it is in fact working exactly as it should.
  23. Like
    Mark reacted to liquidfractal in Why do updates toast CKEditor layouts?   
    Well, I just recreated my button configuration so this time around I don't see a point.  But it does appear as if something at least resets the CKEditor to its default configuration not only with stated editor updates (which I understand), but with other updates.  I guess I'll just keep an eye on it next update and submit a ticket if it happens again.
  24. Like
    Mark reacted to MANOJ KUMAR AGRAWAL in Mobile App for our Forums   
    Has anyone developed a mobile app for Invision forums? If not, I am willing to spend some capital to get it developed (if someone here can develop one) as I want my community members to be notified using a mobile app so that they can be notified while on the go and they don't need to log into the forum everytime?
  25. Like
    Mark reacted to Lucas James in GEOIP BASED FOLLOWER SUGGESTIONS   
    @fix3r
    These marketplace plugins might be interesting. Perhaps, the plugin author @Boris_ might be able to extend its functionality.
     
×
×
  • Create New...

Important Information

We use technologies, such as cookies, to customise content and advertising, to provide social media features and to analyse traffic to the site. We also share information about your use of our site with our trusted social media, advertising and analytics partners. See more about cookies and our Privacy Policy