Jump to content

Community

Colonel_mortis

+Clients
  • Posts

    1,380
  • Joined

  • Last visited

  • Days Won

    4

 Content Type 

Profiles

Downloads

IPS4 Providers

Release Notes

IPS4 Guides

IPS4 Developer Documentation

Invision Community Blog

Forums

Store

Everything posted by Colonel_mortis

  1. Your submission has been noted, and the poll will reappear when you refresh the page. This is a bug that IPS has fixed for the next release, which afaik is probably going to be 4.2.
  2. It isn't IPS cookies that are being sent to your static subdomain, it's cloudflare and google analytics cookies. Cloudflare cookies are mandatory, but won't have a significant impact on page load times. Google analytics cookies can have the domain set by adding _gaq.push(['_setDomainName', 'www.losdurosdelgenero.com']); just before the </script> in the google analytics code that you pasted into ACP. On an unrelated note, you probably want to turn off directory indices within your apache settings for the static subdomain, because the root is showing the directory structure.
  3. The problem with following that section, or even getting emails when new versions are released, is that security updates aren't always flagged at the time that the notifications are sent - .19 wasn't flagged when I got the email about it, and .19.1 has only just been flagged (PSA: upgrade asap).
  4. On the edited post, there is a "show edit history" button, but it will only be populated with edits that were made after enabling the setting.
  5. I reported this in a ticket, along with another related issue, and Matt said he would look into it. Then again, he also said that he would flag 4.1.19.1 as a security release today, because it contains fixes for additional XSS vulnerabilities, but that has not yet happened.
  6. It's been around for a while, certainly since 4.1 and maybe 4.0. It is a complete copy of the post.
  7. Currently, plugins rely on information stored in the database in order to work, and the only time that they are present in a file is when the plugin is exported. This is annoying, because it means you can't use source control to sync changes between computers and it's much more awkward to back up data. It would be really helpful if the key information (notably hooks) was written to a JSON file, or something like that, so that it can be more easily portable.
  8. IPS overrides the error handler to write it to the system logs instead of to the server logs, so provided that the error is not so severe that the IPS handler can't run, there will be nothing logged to the server's PHP logs. If the OP was able to determine that it was a 500 error, it should have displayed the IPS error page, so should be in the system logs. However, if it's a database issue, it might be in the system file logs instead of the database - that is accessible by clicking the button at the top of the normal logs page.
  9. Full post versioning exists - under posting (I think), you can enable full edit history. However, I do agree that the reported post should have the version as reported displayed in the report center, or at least easily accessible and clearly marked as having been changed, so people can't edit the comments away and avoid action.
  10. I can completely understand not wanting to change the app that it defaults to when you omit the app tag, since that is potentially backwards incompatible. However, I can't figure out why there are objections to explicitly stating the app for that one template, where it shouldn't be able to break things except in the most extreme edge case. What is preventing other staff members from agreeing with the suggestion, so that we can understand what potential issues we might face by making the change manually, or find workarounds?
  11. The problem with this feature is that it doesn't actually offer any significant security benefit to balance the considerable loss of usability (and yes, it is considerable, because before I patched it, it was one of the most common complaints that I received). I know you disagree with that sentiment, but please hear me out. I am all for being automatically logged out of a device that you last used 90 days ago. I can understand being logged out of a device 90 days after you last authenticated with it, though that will frustrate users and drive them away, so I don't think it's a good idea. I cannot accept being logged out of a device the day after you logged into it, just because you logged into some other device 90 days ago, and happened to log into something else today. I am curious though, what do you actually think this timer protects against? The ways that I can think a session could be hijacked are: A malicious intermediary intercepting your ips4_pass_hash cookie, and setting it in their own browser to be logged in as you (this doesn't protect against that at all - you must have been logged in when it was intercepted, so the attacker will also be logged in for plenty long enough to do whatever damage you are afraid of) A stolen device (this doesn't protect you against that, because you were logged in before and will therefore remain logged in to the stolen device, at least until you log in somewhere else and the 90 day check is run to invalidate the session, giving the attacker plenty of time to do whatever damage it is that they want to do to your forum account). You log in to your account on a public/shared/friend's machine (this doesn't help because you will remain logged in until the 90 days is up and you log into a new device). You're logged into some old device that you forgot about, and give it away to someone else (it is pretty stupid not to at a minimum clear cookies before doing that, and the cookie will expire in the browser after 90 days anyway, but in principle the timeout would protect against this (if it was still within the lifetime of the cookie but the 90 days on the server have passed), provided that you have logged into a different device since (all the other websites that you logged into are screwed though)). So basically all it does is limit the amount of time that an attacker has access to your account, but not by enough to stop them from being able to do pretty much anything, and not in a way that is predictable to the user (being logged out of other devices when you log into a new one is not at all intuitive), and potentially protect against a particular edge case when you have given away a device that is less than 90 days since you last used the site but you forgot to clear your browsing data. That doesn't sound like a reasonable tradeoff to me. I'm assuming there must be some reasons that I have missed, which are why you are so insistent that this is important. Please do tell me so that I can assess whether I should remove the plugin from my site.
  12. I have had feedback from users, which I am inclined to agree with, that the hovercard that appears when you hover over a topic title takes far too long to dismiss when you move your mouse out. It currently takes 3 seconds [citation needed], but I think 1 second would be more appropriate, and if you click outside the card it should dismiss almost immediately.
  13. Yeah, that is all that plugin does. Unfortunately, IPS have made it clear that they are happy with it working as it does currently It continually logging out isn't quite what they intend, I hope though, so you might have more luck if you're able to track down the issue and report it.
  14. In theory, that shouldn't happen (the code shouldn't log out very frequently, though it does intentionally automatically log you out sometimes), but this plugin fixes all issues related to being automatically logged out for me
  15. The plugin to fix this absurdity has been published on the marketplace (actually it was published a while ago, but I've had several requests for it so I figured I should probably post it in here too).
  16. Basic auth is just a way of the server asking for a username and password. It doesn't have any mechanism for specifying that the user's computer's password should be sent, and in fact there is no way for the browser to access the windows password anyway. If no login box was displayed, or the login box was dismissed, there is no chance of any information being leaked; if (and only if) they did enter anything into that box and submit it, there is a chance that it was being stored, so they should take the appropriate actions. I am surprised that the other browsers didn't prompt for it though, since I have seen it happen with images.
  17. Is there any chance that any of this might be implemented in 4.2?
  18. That is just your host trying to get more money out of you. Unless you pay a large amount of money for an EV certificate (which is what this site uses, though the EV status seems to have been revoked by Firefox...), there is no difference in what is displayed to users between a free certificate and a paid certificate, and no difference in the actual security of your site.
  19. The next release of Firefox will insecure login forms in the same way as the latest Chrome release, and they are also planning in the future to add a more scary warning https://blog.mozilla.org/security/2017/01/20/communicating-the-dangers-of-non-secure-http/
  20. No, the dropdown login box, #elUserSignIn_menu, is embedded into every page, including the ones loaded over HTTP. The form submits to a HTTPS origin (probably, I've not actually checked since I don't have a site with that configuration to hand), but, as I explained in my previous post, that is not sufficient. My site uses HTTPS for everything, so I can't submit a ticket (which would result in me being told to submit a feature request anyway), but this is an issue. Admins should have the option to remove the dropdown login box.
  21. Every page is a login page, since every page has a login dropdown. That means that it is not secure (even if you submit to HTTPS, because an attacker can modify the page), and Chrome and Firefox both flag it as such.
  22. Can you still add the ability to sort activity feeds by created date, and show only the first post/item rather than any replies/comments in the activity feed, to make it significantly more useful?
  23. I'm seeing quite a few instances of "this member is not awaiting validation" in my error logs. Rather than giving them an error if they have already validated their account, they should just be transparently redirected to the site index, so that they don't think the site is broken or anything like that.
×
×
  • 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