Jump to content

Community

skizzerz

+Clients
  • Content Count

    82
  • Joined

  • Last visited

About skizzerz

  • Rank
    Member

IPS Marketplace

  • Resources Contributor
    Total file submissions: 1

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. The disabling PHP functions bit is pure security theater and does not increase the security of your site. If an attacker is capable of running arbitrary PHP code on your server due to some vulnerability, it's already game over. Restricting those functions does not in any way, shape, or form prevent them from doing whatever it is they want to do. Using functions that are required to be enabled just to make pieces of Invision Community function, an attacker can read/write files, read/write the database, and open sockets (network connections). The combination of these is plenty to establish a persistent backdoor and/or gain a foothold into your network to launch attacks elsewhere. open_basedir is potentially a good idea though, depending on your setup. In places where you can safely enable it and enabling it won't break anything, it's a good idea to do so. A better setup for securing PHP would be ensuring that the user account PHP is running as for your Invision Community install is unprivileged (i.e. not root) and is dedicated to your site (i.e. not a shared apache user). If you have multiple sites, run each site under a separate user account. Then, set up file permissions appropriately so that the user accounts have read-only access to their own files and no access to the files of other users. Directories that must be writeable, such as cache and uploads, should have script execution disabled via server config. This ensures that a compromise is unable to write backdoor scripts to your filesystem (although they can still manipulate the database), which will limit the damage an attacker can do. By manipulating the database, an attacker can still establish persistent backdoors into your site with certain configurations (for example, by manipulating cache entries if they're stored in the db or by creating a new admin account), so this is not foolproof. As I wrote above, if an attacker is able to execute arbitrary PHP, it's game over. The setup I described in this paragraph blocks some of the ways they can do that, but not all of them.
  2. Uploaded version 1.1.0 which brings the ability to modify what identifier is being associated with the Duo enrollment (member id, display name, or email address). Please see the changelog for full details on the implications of changing this setting. Additionally, both 1.0.0 and 1.1.0 have been tested on and work for Invision Community 4.4.
  3. Tested v1.0.0 on 4.3 and everything appears to work correctly, so I'm marking the existing version as compatible.
  4. Sorry I somehow missed this... I'm following the topic yet seemed to have missed the email. Anyway, yes, this works for Admin CP logins in addition to regular logins, just like the built-in multifactor auth schemes.
  5. This is the support topic for Duo Authentication. https://invisioncommunity.com/files/file/8811-duo-authentication/
  6. Version 1.1.0

    28 downloads

    Duo Authentication lets you add Duo as another Multi Factor Authentication (MFA) option. Duo is a paid service with a limited free tier (up to 10 users) which allows centralized management of all authorized users. Setup Instructions Upload the plugin XML file to your Admin CP to install it. Sign up for an account at Duo: https://signup.duo.com/ On your Duo dashboard, create a new "Web SDK" application. See the screenshot above (with 3 arrows and numbers) for an image of how to do this. Make a note of the Integration Key, Secret Key, and API Hostname. Additionally, ensure that "Let users remove devices, add new devices, and reactivate Duo Mobile" is checked. If it is not, you will need to enroll your users yourself and they will be unable to manage their Duo account (add/remove authorized devices) from within Invision Community. If enrolling manually, ensure that the username in duo matches the "Duo identifier" setting in Invision Community. By default, this is the Member's ID number, but it can be changed to their Display Name or Email Address instead. See the screenshot above (with the 2 red boxes) for an image of where to find these settings. Copy the Integration Key, Secret Key, and API Hostname into the Duo settings in the Multi Factor Authentication area of the ACP. Toggle Duo from "Disabled" to "Enabled" -- your members can now use Duo! To manage which types of notifications are supported (push, SMS, phone call, passcode), edit the policy on the Duo dashboard. You can also enable a "remember me" checkbox on the Duo dashboard which will allow the user to bypass MFA for a set number of days on the same device.

    Free

  7. I highly doubt IPS would be willing to shell out tons of money every month to $RANDOM_DEVELOPER. Also, how would renewals work? Or do you only get whatever version was offered for free and if you need to upgrade you gotta pay for it?
  8. The only two places I know of with official documentation are that site you just linked and what is available by clicking the "Help" link on the footer of every IPB site (for example: http://community.invisionpower.com/index.php?app=core&module=help). Beyond that, if you have questions or are confused about something you might be able to find the answer by searching here or by just asking :smile: If something isn't intuitive to you, also consider opening a feedback thread in the appropriate forum. While there are no guarantees anything will be done with that feedback, at least it'll be out there so IPS knows there is an issue there for some people.
  9. Consider this (possibly quite common) workflow if what you ask for gets implemented: 1. User opens support ticket, and in process of getting support adds suggestion for improvement 2. Support staff creates new topic on feedback forums in appropriate area and alerts user 3. User doesn't use the forums at all, so doesn't bother checking back on the topic once there aren't any replies after a day (or maybe even after a couple hours), if they even check to begin with 4. Someone posts a reply after that period asking for clarification or some sort other sort of response that requires more knowledge on the issue than what was posted originally. Who's going to reply? The support staff can't read minds and are probably busy enough as-is, and the one who originally raised the suggestion is not only nowhere to be found, but may never come back to the topic. There are quite a few advantages for everyone by keeping the system as it is versus your suggestion. On the IPS side of things it means the support staff don't have to take extra time on possibly quite a large number of tickets typing up new feedback topics. On the user's side of things it gives them an opportunity to reword and better clarify their feedback as its own thing rather than an idea tacked onto a support request. On the community's side of things it gives them the ability to have a conversation with the original author about it without having to worry as much that they may never get a reply back. Finally, on the random forum reader's side of things they aren't confused seeing staff opening feedback topics and thinking that it means those things are going to be implemented (considering random forum reader as someone searching for an answer for something and finding that thread, not being familiar at all with how anything works here).
  10. All developers have the ability to get the email addresses of those who purchased their files (only for paid files, not free downloads). However, that information may only be used to provide support to the customers. The fact that your email address is being collected and available to the developer of the file you purchase is right in the purchase terms: "By purchasing a paid file your email address will be revealed to the author of that file." (last sentence of 3rd paragraph). There is no need to state on an application description that emails are being collected because it is global across all paid apps in the marketplace, and is made aware to you via the terms whenever you make a purchase.
  11. One cannot just relicense GPL "like that" -- EVERY contributor to that source code file (or documentation page as the case may be here) needs to agree to relicense (or their changes to the file need to be removed/reverted before relicensing), and that is incredibly difficult to accomplish when one accepts contributions from the community at-large.
  12. So use the reputation system and remove the public-facing display on the member profile page and wherever else it might appear via template edits -- that way a user has no way to see their "average" across all posts, so the only thing that matters is the count on each individual post. For what it's worth, the "like" system works the exact same way as reputation -- it increases your global average. It's just that there is no way to decrease it with the likes system.
  13. Preferably just one, but I'm not sure which you would prioritize... I suppose if someone says notify for quote + notify for profile link, and someone does both, only do the quote notification? Would likely have to add in other edge cases though, and that could quickly be a mess, but I suppose priorities would be (given current notification options): Following a topic (current functionality has following before being quoted, so keeping it first makes sense)Being quoted, because they mention both you AND your contentBeing mentionedOf course when you introduce other means of producing content (other than the forums) that list could quickly explode, and there would be a need to have some framework automatically determine which notification to send in the event multiple notifications would be sent for the same bit of content. One use case of a mention is when you want to bring a user's attention to a thread that they have not yet participated in, that possibly concerns them. In this case there is no post to quote, so currently the only way to bring it to their attention is to either wait for them to read it themselves or to send them a message saying "hey check this out"
  14. Yes, if I had known my own personal opinion on some of the phrasing would turn into a page of back-and-forth, I would have simply not said it, as that is not the point of this thread. I apologize for the mess that I've caused with that. As a developer and someone who's worked in support myself, I understand and value your position in all of those points, I just thought it could have been phrased somewhat more nicely in some areas. Can we all please go back on topic now? :smile: OT: Perhaps a happy medium would be some bbcode tag to automatically link to a user's profile and a new notification option that whenever someone posts a link using that bbcode, they get a notification? That way you don't have "magic" characters that gobble text and do formatting you may not want while still seeing mostly all of the functionality.
  15. I think the @mentions and #hashtags have passed "fad" stage and have become "the way of doing things" on social networks. That said, not every community/forum is designed to be a social network, so I don't really see the need to prioritize adding a feature such as @mentions over any of the other numerous improvements IPB needs. A mod already exists (although I would personally never install it simply due to the mod author's unprofessional attitude on the description page, but that is besides the point here), and people so inclined can use that.
×
×
  • Create New...