Turning on native comments option leads to logging of errors at console

Developer help
1
TECHNICAL DETAILS

Environment info:

  • Ghost Version - 5.47.0
  • Environment Type: Production
  • Database: mysql8
  • Theme: Solo


Installation info:

History of installation and configuration:
The Ghost CMS was installed by following the official documentation guide for Ubuntu in Production Environment via the CLI interface, configured with Nginx (v1.18.0).
The configuration file matches exactly the site URL.
Hosted over a Virtual Machine instance at Google Cloud Platform.

Technical dependencies:
Host OS: Ubuntu 22.04.2 LTS
Node version: 18.16.0
Database: MySQL v8.0.33 (x86-64)

Client-side Testing Environment:
OS: Windows, Android, iOS
Browser: Google Chrome, Mozilla Firefox

Website Status: LIVE (on HTTPS)

đź”´ UNSOLVED ISSUE

The Ghost CMS had been set up and customized for almost a month.
After working with many settings and options, the native comments option was supposedly turned on at the Ghost admin settings [ghost/#/settings/members] for all logged-in members as part of the website development.
Henceforth, the console started logging errors at two different variations only at webpages that included comments section, in this case, posts.

🔺 Summary 🔻

Problem: Errors at console
Cause: Turning on native comments.
Location: Pages that include comments, mostly the posts.
Source: admin-auth.min.js and App.js

Errors and their variations:

1. User as - guest (logged out), logged in, and/or on reload:
Errors for admin-auth.min.js and App.js are logged at the console a couple of times.

Guest User or Logged out
Guest User or Logged out1011Ă—421 18.2 KB

User Logged in
User Logged in1051Ă—354 17.8 KB


2. User and Admin logged in at same session or browser instance:
On loading of the page, within a few seconds, multiple errors were logged especially on the load of the comments section.

User and Admin logged in at same session.
User and Admin logged in at same session.1161Ă—749 58.6 KB


Steps to Reproduce:

  1. Turn on native comments at the Ghost CMS at domain[.]com/ghost/#/settings/members
    [Ghost Admin → Settings → Membership →
    → Commenting → Enable (with logged-in or subscription)]

  2. Make sure that your site has {{comments}} in which ever page(s) or post(s) required.

  3. Look out for the errors mentioned above with the respective scenarios.

  • YES, there are errors in reproducing the issue.
  • NO, errors not found on reproducing the issue.

0 voters



Related topics discussed in the past:

Ghost, Digital Ocean, Cloudflare, 403 on ghost/api/admin/users/me/?include=roles

Admin-auth.min.js and App.js errors

  • Takeaways: With the realization that some of the errors logged are expected like the error 403, but still it in your next commit, it would be an urge to remove these console.log() or replace them to function in such a way that these errors are reported directly to system logs. Possible solutions are accepted too.
    Though the second error instance can be avoided, for the first instance (when a user is logged out), do consider providing a solution or file this as a bug or a feature request.


NOTE:
The site URL concerned in this case cannot be disclosed due to miscellaneous reasons.
So only, in-depth details of this case have been mentioned, and provided with another reference site: https://omnipada.com/my-experience/

3

The Ghost CMS has been once again upgraded to the current latest version as of 16th May 2023, Tuesday: 5.47.2
But above described errors still persists to exist in the Ghost Solo theme with the native comment section enabled.

Live example URL: https://omnipada.com/my-experience/

4

When you see those errors in the console, switch to the Network tab of the web developers tool and find the requests that generate the errors. Look at the “Response”. You should see some JSON object that the frontend is failing to parse. It may contain an “interesting” error message.

5

Definitely, this error was noticed earlier regardless of user being logged in or not, whenever the comment section is present at any page/post.


At console,

Failed to load resource: the server responded with a status of 403 () /ghost/api/admin/users/me/


At network tab,

Name: me/
Status: 403
Type: fetch
Initiator: admin-auth.min.js

RESPONSE:

{
    "errors": [{
        "message": "Authorization failed",
        "context": "Unable to determine the authenticated user or integration. Check that cookies are being passed through if using session authentication.",
        "type": "NoPermissionError",
        "details": null,
        "property": null,
        "help": null,
        "code": null,
        "id": "9fda2mk0-f70a-11ed-96h4-cbc5673b00a1",
        "ghostErrorCode": null
    }]
}

Just for further information, these instances were cross checked at multiple devices at incognito/private browsing with cleared cache and no extensions enabled.
Maybe this seems to be intended but it would be great if it is possible to get rid off this or have an alternate solution for admin app to show the login screen.

6

The 403 response is exactly as expected and working the way HTTP status codes are intended to work in this case, it’s not an error, it’s just indicating that no staff user is logged in. Browsers will show that log message no matter what we do - you’re looking at developer logs after all.

The other errors when you have logged in as a staff user are not expected, you should inspect the response of the failed network requests because your screenshots don’t show enough information to determine what’s gone wrong.

2 Likes