Jump to content

Community

Mark

Invision Community Team
  • Content Count

    36,157
  • Joined

  • Days Won

    109

 Content Type 

Profiles

Downloads

IPS4 Documentation

IPS4 Providers

Release Notes

IPS4 Guides

IPS4 Developer Documentation

Invision Community Blog

Forums

Posts posted by Mark


  1. It should use whatever your browser has it's region set to, and if there is nothing there, not select anything as the default. Look here and see what your browser is reporting for "Language": https://www.whatsmybrowser.org

    Or, if you enable Google Maps autocomplete information and the user grants access, it will use your real location and autocomplete favouring addresses that are in the same city/etc as you


  2. 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.


  3. 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.


  4. 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.


  5. On 11/4/2018 at 10:16 PM, Dolphin. said:

    End-to-end encryption please!

    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.


  6. 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?


  7. 39 minutes ago, All Astronauts said:

    Can we get some real clarity here? Is the intention that the IPS FTP routines are going to go away (5 series?) or are they going to remain available? There is plenty of 3rd-party stuff floating around out there (private mods) that use this stuff and knowing sooner rather than later would be preferable so we can start falling back now on the usual PHP code and route around the IPS methods.

    EDIT: I know this is all about the file storage option but still, just wanting to be sure these methods ain't getting ditched (you are using them for updating so prob not)

    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).


  8. 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.


  9. 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.


  10. If you're willing to submit a support ticket, I'd be interested to check that there's nothing else going wrong. It seems to me very bizarre that someone would miss the equally sized "Download" button and click "Buy Now" and submit payment 6 separate times.

    If you do, mention this post so the support team know to send it up to me.


  11. If you go to AdminCP > Commerce > Payments > Settings > Checkout. you can set it so guests are not asked for a display name. Also on that page, you can set it so under certain circumstances, the customer's real name and billing address isn't required - however, some payment methods require this information.

    Beyond that, the only thing they are asked for is an email address (which we need to send the order confirmation and details to) and password. So the only thing that it asks for which could be avoided is the "Password" field.


  12. On 12/15/2018 at 10:46 PM, tonyv said:

    Two factor annoys me. I hate when I go to a site like the Sprint site to pay my phone bill and can't even log in because I have to wait for a text message with a ridiculous 4 character code. This extra step is just another example of dumbing things down, of making extra work for everyone just because some (or even many) people have CHS. Use a password that looks like this /?N_cCO{H<u)[4^+ and you won't have a problem. I would avoid my own site if I were forced to use two factor. 

    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.

×
×
  • Create New...