CityOfBoston / boston.gov-d8

The official repository City of Boston public website, boston.gov.

Home Page:https://boston.gov

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Content authors unable to add / edit components or upload photos

duffy-james opened this issue · comments

There appears to be an issue where content authors are unable to add or edit components, or upload or search for any photos. I've also had content authors report that they're unable to open "discussion topics" or add documents to the "details" section of the "public notices" content type.

As an example, a user sent a screenshot saying that they couldn't click the "edit" button here in a components section of a page in Drupal:

image

So far, we've only had content authors report having an issue, but that's the majority of our users. We should investigate as soon as possible. Potentially it's a permissions issue.

@davidrkupton I wonder if this is potentially related to ticket #2498

The latest update to contributed module drupal/honeypot (2.0.2 => 2.1.0) in last maintenance release (#2515 ) seems to be causing the issue.

I have rolled back honeypot to 2.0.2 which also caused composer to reinstall drupal/paragraphs_edit (v2.0.0). Given the name of the module, paragraphs_edit is likely to be the module at the root of the error and it was updated from 2.0.0-beta1 during the #2515 maintenance update. However the downgrade of honeypot only seems to cause the paragraphs_edit module to be re-installed, not downgraded or removed.

Maybe the issue is that paragraphs_edit need to be installed twice to properly register the service which throws the error - I will try re-upgrading honeypot after downgrade will cause paragraphs_edit to be re-installed again and also have honeypot on latest version ??? (-update: didn't work)

Going to reopen this until we confirm it's fixed.

This PR locks honeypot at v2.0.2 and stops it upgrading past that version. I need to do some review on why it affects our Drupal installation when upgraded to 2.1.0.

In the meantime, as well as that fix I have relaxed the honeypot setting so that authenticated users do not have honeypots added to their forms. This also solved the problem, even for honeypot v2.1.0.

I have discovered that Honeypot is not well configured on the site. Honeypot module was added because at one time there was some evidence that a bot was doing an ineffective but annoying flood style attack on our contact us form. To protect manually generated forms (e.g. the contact us form) the honeypot needs to be added manually in code to those forms - I will review to confirm if this has happened. At the moment I suspect honeypot is mainly protecting our content input forms, which are only ever used by authenticated CoB employees. By default honeypot does apply to webforms as well, and I think the integration is in place and protecting for those forms.

Closing this one out. Need to create a separate ticket for investigating the honeypot configuration.