Details
-
Type:
Sub-task
-
Status: Done/Fixed
-
Priority:
Minor
-
Resolution: Fixed/Completed
-
Affects Version/s: 4.6
-
Fix Version/s: 4.6.12
-
Component/s: CiviCRM API, Core CiviCRM
-
Labels:
-
Documentation Required?:User and Admin Doc
-
Funding Source:Core Team Funds
Description
When discussing support issues online (via forum, stack-exchange, blog, JIRA, etc), we expect commenters to post relevant details about their configuration. This has a few gaps:
- The forums have a neat feature where you can put some details on your profile, but this doesn't carry over into any other medium, and it's liable to grow stale.
- You can only list details if you know them or feel comfortable collecting them. People often don't know details like their MySQL version or PHP version.
- If details are chosen adhoc, then you might include details which seem obviously connected to the problem. But bugs often involve details which are not obviously connected to the problem.
Of course, the most effective solution is to give other developers/implementers full access to the problem system (or to an identical test system), but that comes with huge trust/security/admin issues. The goal of this ticket is to provide some streamlined tooling to publish as much supporting information as possible while minimizing trust/security/admin issues.
My belief is that we should aim to share these details:
- Version numbers of Civi, CMS, PHP, DB
- List of add-ons in Civi, CMS, PHP
- (This list is probably incomplete, but I'm not specifically advocating any others. Feel free to comment about additions.)
My one concern about this is the potential for systematic abuse. If you tell someone "I'm having trouble, and here's the server address", then they're in a good position to attack/exploit it. If these details are freely published, then attackers could search/crawl the data and find systems running old, vulnerable software.
There are a few ways to address this, but my favorites so far are
A. Don't publish any site-identifying information (such as URLs, paths, DB names).
B. Put the details behind captcha (to keep out robots but let humans in).
C. (Maybe) Put an expiration date so that the info eventually disappears.
I flirted with the idea of putting an ACL on each site profile and allowing folks to request access (a bit like Google Doc), but this approach is more complex (for developers and users) and feels hard to justify for data which isn't truly sensitive (no identities, no credentials). Unless there's a lot of pushback or a strong counter-point, I'm inclined to just do A+B+C.
Attachments
Issue Links
- links to
Activity
I've attached a few mockups. The "civiconnect-profile-acl" was a first attempt based on ACLs, and "civiconnect-profile-captcha" is a revision using captcha instead.
Generally I like this.
- Would offering this information as a screen within civicrm, so an admin can copy paste directly into SE, forum without need for involving my.civicrm.org? That seems simpler?
- should we assume that any extension not listed in the extensions repository is "custom" and obfuscate? Many custom extensions contain the site domain.
Good point that extension keys can reveal domain. It's also nice to have some sense for what the extensino does. Maybe we could publish the short-name instead of the long-name?
I'm a bit back-and-forth on whether to copy-paste a blob or post through my.civicrm.org. Trade-offs/considerations:
- Copy-paste approach has fewer moving parts (at least, within our purview). my.civicrm.org has more moving parts (at least, within our purview).
- Copy-paste approach doesn't provide expiration or captcha. my.civicrm.org can do both easily.
- Copy-paste approach conveys configuration at one moment. my.civicrm.org can autoupdate and/or convey history. (Ex: Forum profiles grow stale.)
- Copy-paste approach works on local/dev sites. my.civicrm.org requires a site which is genuinely online.
- Changing the report for copy-paste requires a core release. Changing the report for my.civicrm.org can be done server-side. (Ex: obfuscating extension keys sounds tricky - might need to iterate on that logic a couple times.)
- Regardless of the web-based UI, the current report can be generated via API ('drush cvapi system.get').
Per request, added internal tracking of site_id https://github.com/civicrm/cxnapp/pull/8
Could we please add CiviConnect to the navigation menu? For those of us providing free online support, it's important that we be able to give easy instructions for enabling site profiles to users.
I agree with Jon - given that we've publicly released a service, it seems sensible to hyperlink the page now.
Also, we should probably add a green blurb to the page to explain what "Connections" are.
I'll do a PR.
A quick recap on versions:
- Circa v4.6.5 – Adds CiviConnect. Should be compatible with profile service.
- Circa v4.6.11 – Adds multiple improvements to CiviConnect UI. Reports more config data in System.get API.
- Circa v4.6.12 – Adds menu item "Admin => System Settings => Connections".
Had some discussion about PHP INI settings. Some settings (e.g. memory_limit and safe_mode) are really useful to share. Other settings must not be shared because they could implicitly identify the site (e.g. the include_path or docroot often reveals the domain name – and could even reval credentials (e.g. mysql.default_password). I've updated the System.get API to return redacted data from PHP INI:
https://github.com/totten/civicrm-core/commit/5bbcc82374632713a022a8cc7981e5cc0bdfd0dd