PLEASE NOTE: These forums are no longer utilized and are provided as an archive for informational purposes only. All support issues will be handled via email using our support ticket system. For more detailed information on this change, please see this blog post.

Security Issue: Setting page available to non-Super Admins on multisite

  1. gabe736

    Hello. I found a security issue: The Gravity Forms 'settings' page is available to non-Super Admins when using Gravity Forms provided add-ons.

    Before using add-ons, I could simply disable the settings page based on user role. Unfortunately, the settings pages for add-ons are tied to the same page as the Gravity Forms settings page. This means disabling the settings pages for non-Super Admins also prevents users from setting up add-ons with the appropriate account information for integration.

    Another issue is that on for the add-ons the 'Uninstall' option is available at the bottom of the page for non-Super Admins on multisite networks. It's hidden on the main Gravity Forms settings page, but not on the add-on pages as it should be. I believe this is a bug.

    Recommended fixes:
    1) Separate the main Gravity Forms settings page and add-ons settings pages so the main page can be hidden based on user role without preventing users from setting up the add-ons. For example, make it two pages: 'Settings' and 'Add-On Settings'

    2) Fix the auto-disabling of the 'Uninstall Add On' button on add-on settings pages on multisite networks just as it is disabled on the Gravity Forms settings page for non-Super Admins. Non-Super Admins should NOT be able to uninstall add-ons just like they aren't able to uninstall Gravity Forms.

    I've tested on both local and live sites and tried to be as clear as possible. Let me know if I've missed anything or there are any questions.

    Posted 11 years ago on Sunday February 17, 2013 | Permalink
  2. I'll bring this to the attention of the development team for their feedback. Thank you for the report.

    Posted 11 years ago on Monday February 18, 2013 | Permalink
  3. gabe736

    Thanks Chris, I really appreciate it.

    Posted 11 years ago on Monday February 18, 2013 | Permalink
  4. Sure thing. Thanks again for the report.

    Posted 11 years ago on Monday February 18, 2013 | Permalink
  5. After talking it over with the development team, we see your point, but this is the first time this issue has been brought up. We'll keep it in mind and see if there is anything we can improve in future versions.

    Posted 11 years ago on Wednesday February 20, 2013 | Permalink
  6. gabe736

    Thanks Chris. I get triaging by demand but I'm just curious, are those acknowledged to be bugs and/or security issues or they classified as feature requests? Just trying to understand the policy. Thanks, I appreciate you looking into the issue for us.

    Posted 11 years ago on Thursday February 21, 2013 | Permalink
  7. Feature request at this point. We'll leave this open to see if there is any additional feedback from other users.

    Posted 11 years ago on Saturday February 23, 2013 | Permalink
  8. gabe736

    Ok, thanks Chris.

    Posted 11 years ago on Tuesday February 26, 2013 | Permalink

This topic has been resolved and has been closed to new replies.