Problem/Motivation
Upgrading a development site to 9.3.0 (not -dev!) as advertised a few days ago caused all the views to disclose eventually embedded fields.
All of the affected views had some "pages" for the admin with embedded blocks to select and edit content, and also "blocks" which got embedded in the frontend without embedded blocks.
After upgrading to 9.3.0 all the pages and blocks had the form exposed which would allow visitors to view internal information just by using the now exposed blocks.
Steps to reproduce
As I have no idea what caused the issue, I can only suggest to check all the forms on any site for inadvertently exposed forms.
At the same occasion all of the "language switching" got lost -- the links to translated pages/view/taxonomy pages return 404.
There are the following messages in the protocol, and there were about the same messages (in local language) during 'composer upgrade':
The role Angemeldeter Benutzer has had the following non-existent permission(s) removed: use text format basic_html.
The role Inhaber has had the following non-existent permission(s) removed: access webform submission log.
The role Redakteur has had the following non-existent permission(s) removed: administer builder, administer contexts, create doku content, create full_page content, create gallery content, create terms in slider_categories, create terms in testimonial_category, delete own doku content, delete own full_page content, delete own gallery content, edit any doku content, edit any full_page content, edit any gallery content, edit own doku content, edit own full_page content, edit own gallery content, edit terms in slider_categories, edit terms in testimonial_category, translate full_page node, translate gallery node, translate slider_categories taxonomy_term, translate testimonial_category taxonomy_term, use builder, view doku revisions, view full_page revisions, view gallery revisions.
Because the issue sneaked in silently, this would have gone unnoticed because of the complexity of this very site, and I consider this a quite dangerous situation.
Comments
Comment #2
nofue commentedComment #3
nofue commentedComment #4
alexpott@nofue thank you for this bug report. It is very concerning that user's are able to get access to things they are not supposed to. Reading the messages you've pasted in the issue summary - they concern removing permissions that do not exist from roles on your site. It is hard to imagine how removing permissions could result in users gaining access.
In order to help us debug what is going on with your site you will need to provide more information as to how access was restricted prior to the upgrade and why that is no longer working. If you are unable to do that you could try reaching out to me on slack and I or others in the Drupal community might try to help you provide the information. I'm @alexpott on slack.
Comment #5
catch@nofue ideally we need steps to reproduce the bug here, i.e. a views configuration that can be made with core or a contrib module on 9.2, which then shows different content in 9.3 after update. Could you also check what the access configuration is for the views pages?
Comment #6
catchOne thing that would be useful here would be a config export of the view from 9.2.0, and a config export of the same view after updating to 9.3.0 so we can see the diff.
Could you also go into the views UI (either on a 9.2 or 9.3 version of the site, or ideally both), and see if there are any messages about missing plugins etc.?
Comment #7
nofue commented@alexpott - Maybe I wasn't clear enough: I'm perfectly aware that there had been content types which had been removed from this very configuration in the process of upgrading to 9.x. However: We've been working on this site in this configuration for some four weeks and we built a lot of views in two "flavors" - usually one page which gets used by the editors, and lots of blocks derived from the page, which get injected to front end pages through paragraphs.
The page version of the view holds lots of exposed filters editors can make use of to filter any content to their needs.
The block versions of course do not expose any filter settings to the public.
After the upgrade I found the editor's filters exposed to the public through the views blocks. After reporting the issue, I also found most of the language switching to be broken -- seemingly views ignored the filtering by translation language. We're still in the process of repairing the mess, and as we have to go online before Saturday, I do not have any time to do any forensics. I know, this is not very helpful, but my first priority is to get the project out, and second is to tell people about what happened here.
As I have two more "sibling sites" in the make, which are still 9.2.x because of this incident, I will have plenty of source to dig deeper -- but not for the time being, as deadline is getting closer and this incident set us back about a week.
@catch - Thank you for your "wishlist", I'm trying to replicate things with another "sibling" project which has about the same history as the one affected. As I'm not likely to get there before December 28th, I hope you can come up with a list of things you need, and I'll do my best to support your investigation.
Comment #8
stephencamilo commentedComment #9
larowlanComment #11
xjmThanks again for reporting this, @nofue. Unfortunately, I don't think we're going to be able to get anywhere toward fixing this without some additional info. Let us know if you can reproduce the issue.
Comment #13
kristen polThanks for reporting this issue. We rely on issue reports like this one to resolve bugs and improve Drupal core.
As part of the Bug Smash Initiative, we are triaging issues that are marked "Postponed (maintainer needs more info)". This issue was marked "Postponed (maintainer needs more info)" more than 6 months ago with a request for more information and there has been no activity since that time.
Since we need more information to move forward with this issue, I am tagging for Bug Smash Initiative and keeping the status at Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.
Thanks!
Comment #14
nofue commentedFair enough -- as we're at 9.5.7 now, I doubt there'll be any news regarding this issue anytime soon. Hope your Bug Smashing Initiative gets into things earlier in the future. I'm willing to help, but I need advice as what may help you.
Comment #15
cilefen commentedComment #16
cilefen commented@nofue: Regarding your last comment, @catch asked for a configuration export and you seem not to have responded to that.
Comment #17
nofue commentedSure -- but if I remember correctly, the problem became obvious only a while after the update had occurred, as indicated by my last sentence:
At the time the problem was noticed I didn't have any backups with a version 9.2 to export. As I'm living under time constraints, too, a simple page for non-programmers, detailing what coders would like to see, would be fine. I'm sorry I have to confess that I haven't spent too much time searching for such a recipe of "how to keep coders happy with your report", but a simple link at every issues page shouldn't cost an arm and a leg, right? And please: KISS. I simply lack the time of reading pages about details I simply don't care about. Maybe just all the necessary (relative) links where to produce what report/export/… and we're all happy.