dotCMS / core

Headless/Hybrid Content Management System for Enterprises
http://dotcms.com
Other
860 stars 467 forks source link

Secrets can not find the inode on certain url #27516

Closed jdotcms closed 6 months ago

jdotcms commented 8 months ago

Parent Issue

No response

Problem Statement

Secrets tool can not parse url such as this: /data/shared/assets/c/e/ce837ff5-dc6f-427a-8f60-d18afc395be9/fileAsset/openai-summarize.vtl

In order to get the inode and realized if the last editor has permissions to retrieve the secret

Steps to Reproduce

Error reported on Auth, when accessing a page (using secrets) as an anon user, you get this error:

[05/02/24 22:33:57:468 GMT]  WARN servlets.BinaryExporterServlet: org.apache.catalina.connector.ClientAbortException: java.io.IOException: Broken pipe Error for = /contentAsset/raw-data/e4f816a6-e00d-42a7-acd4-b66b07c6bbae/asset/byInode/true

[05/02/24 22:34:07:997 GMT]  WARN viewtools.SecretTool: Failed to find last modification user from Retrieved ID '' in URL Path '/data/shared/assets/c/e/ce837ff5-dc6f-427a-8f60-d18afc395be9/fileAsset/openai-summarize.vtl': begin 1, end -1, length 91
[05/02/24 22:34:07:997 GMT]  WARN viewtools.SecretTool: begin 1, end -1, length 91
[05/02/24 22:34:07:997 GMT]  WARN viewtools.SecretTool: java.base/java.lang.String.checkBoundsBeginEnd(String.java:3319)
[05/02/24 22:34:07:997 GMT]  WARN viewtools.SecretTool: Failed to evaluate Scripting Role presence: External scripting is disabled in your dotcms instance
[05/02/24 22:34:07:997 GMT]  WARN viewtools.SecretTool: External scripting is disabled in your dotcms instance
[05/02/24 22:34:07:997 GMT]  WARN viewtools.SecretTool: com.dotcms.rendering.velocity.viewtools.SecretTool.canUserEvaluate(SecretTool.java:142)
[05/02/24 22:34:07:997 GMT]  WARN viewtools.SecretTool: get External scripting is disabled in your dotcms instance @ url:GET//dotcms.com/testing/testing | lang:1 | ip:71.184.123.101 | Admin:false | start:02-02-2024 02:47:48 GMT >/LIVE/063474c6-6fb2-4ff1-80ca-85beb756e2fd/d1123bda-80c8-4f70-9d7a-e0b94f54033d.fields

[05/02/24 22:34:16:265 GMT]  INFO util.OpenAIRequest: Rate limit:3000/minute, or 1 every 20ms. Sleeping:19

[05/02/24 22:34:16:475 GMT]  INFO db.EmbeddingsDB: Saving embeddings for content:cache

In your local dotCMS instance, please do the following:

  1. Go to the System > Apps portlet, click the Dot Velocity Secrets App, and click your current site -- default or demo.dotcms.com
  2. Add two custom properties to the Velocity Secrets: 2.1 keyone with value Value for Key One. 2.2 keytwo with value Hidden Value for Key Two, and mark it as Hidden.
  3. Create an Advanced Template with some HTML code that will display the secret values:
    <html>
    <header>
        <title>My Custom Template</title>
    </header>
    <body>
        <h1>Welcome to my page!</h1>
        <div>
            <ul>
                <li>Key One = $dotsecrets.keyone</li>
                <li>Key Two = $dotsecrets.keytwo</li>
            </ul>
        </div>
    </body>
    </html>
  4. Create a test HTML Page using your Template.
  5. View the test HTML Page in the front-end, and make sure you can se the value from both keyone and keytwo keys.
  6. Now, create another test HTML Page, BUT log in as a limited User that DOES NOT have the Scripting Developer Role assigned to it.
  7. You must not be able to see the value of the Secrets on the new test page.

Acceptance Criteria

The secrets should work ok

dotCMS Version

master

Proposed Objective

Core Features

Proposed Priority

Priority 3 - Average

External Links... Slack Conversations, Support Tickets, Figma Designs, etc.

No response

Assumptions & Initiation Needs

No response

Quality Assurance Notes & Workarounds

No response

Sub-Tasks & Estimates

No response

jcastro-dotcms commented 8 months ago

INTERNAL QA: PASSED

A page created by a User with the expected Scripting Developer Role can now display secrets without issues, and no errors are displayed in the log.

josemejias11 commented 7 months ago

Failed: Tested on master_62e8d60, Docker, macOS 13.0, FF v121.0.1

I see this is still happening

Screenshot 2024-02-26 at 9 04 08 AM Screenshot 2024-02-26 at 9 03 00 AM
jdotcms commented 7 months ago

hi @josemejias11 could you please add the steps to reproduce it

fmontes commented 7 months ago

@bryanboza any ideas here?

josemejias11 commented 7 months ago

Approved: Tested on master_909f9ce, Docker, macOS 13.0, FF v121.0.1

I was trying to reproduce this once again and I'm not able to do it so.

bryanboza commented 7 months ago

Ok, I tested this card and what I have we need some work here:

Following the provided steps, this is what I have...

https://github.com/dotCMS/core/assets/2641437/3a6a7c87-5648-4d36-acd8-b44f8615cb7a

jdotcms commented 7 months ago

hi @bryanboza

Thanks for the feedback, unfortunately in your video I can not see 2 things: 1) the ttl for the testing page (I would recommend 0 to avoid caching issues) 2) the last modifier user for the template

I am wondering that, because the rules are the following:

a)

boolean hasScriptingRole = checkRoleFromLastModUser(scripting);

If the last mod user has scripting role it is enough to show the secrets, even if the current user does not have the scripting role or it is anonymous

b)

if (!hasScriptingRole) {
                final User user = WebAPILocator.getUserWebAPI().getUser(this.request);
                // try with the current user
                if (null != user) {
                    hasScriptingRole = APILocator.getRoleAPI().doesUserHaveRole(user, scripting);
                }
            }

If the last mod user does not have the scripting role, then we check if the actual user has the scripting role permission

So, what I think is happening, is that the last user to modified the template was the admin, so the page is accesible for everyone in terms of secrets, I have debugged master and I can confirm that

bryanboza commented 7 months ago

Yes I tested modifying the template with the limited user and the same thing happens, and also I tested in a incognito mode to make sure that is not the browser cache and flushing the dotCMS caches too.

wezell commented 7 months ago

This is working on the demo site - take a look here, it is pulling the secrets. I think the user (admin?) you used to create the template does not have the scripting role?

https://demo.dotcms.com/testing-secrets

jdotcms commented 7 months ago

Per discussion with @bryanboza , it seems he tested/edit the template with Chris Publishi who does not have any script role and then request the page associated to that template with the same Chris or Annonymous and was able to see the secrets

About to re-test the scenario

jdotcms commented 7 months ago

I have done the following test 1) have created an user with access to pages, templates, etc but without the scripting role 2) have created with admin user a template + page + secrets tools (admin of course has scripting role) 3) the page works fine even if the limited user is the one that request the page, of course admin works too. 4) get login as limited user 5) edit the template where I wrote the secrets tool code 6) looks such as this

Screenshot 2024-03-19 at 3 09 35 PM

7) get back again to the page and see, the secrets are not longer available b/c the latest upd user has not the role, and even the current one (which is the limited)

Screenshot 2024-03-19 at 3 10 28 PM

Note: if I logout as a Limited user and get back to admin, and re-open the page again (the one with the template with secrets), the secrets are available to see b/c even if the latest mod user has not the script role, the current user is admin and he has the script role

bryanboza commented 7 months ago

Fixed, after the discussion seems that this is ok for now!!!

Tested on master // Docker // FF

erickgonzalez commented 6 months ago

Only for 23.10 LTS