Admin User

[Adam Jones]

Hello. New user trying to kick the tires on the open source installation. Using the following docker compose file to spin up the demo site:

wget https://raw.githubusercontent.com/dotCMS/core/master/docker/docker-compose-examples/single-node-demo-site/docker-compose.yml

If I run it locally I can login to the /admin page with no issue using the standard ad...@dotcms.com / admin credentials.

Spinning this up on an EC2 instance and trying to login into /admin returns an invalid user exception. Keep in mind, the main site (non admin) loads locally and on the EC2 instance. Only the /admin page(s) result in different behaviors.

Any idea what the issue might be? Thanks.

Some of the relevant logging:

dotcms-dotcms-1      | 01:12:21.791  INFO  util.SecurityLogger - class com.dotcms.cms.login.LoginServiceAPIFactory$LoginServiceImpl : User dotcms.org.1 has successfully login from IP: XXXXXXXXXX -- ip:XXXXXXXXXX,user:Admin User [ID: dotcms.org.1][email:ad...@dotcms.com]
dotcms-dotcms-1      | 01:12:21.844  WARN  rest.WebResource - InitDataObject Error: uri:/api/v1/menu err:Invalid User
dotcms-dotcms-1      | 01:12:21.845  WARN  rest.WebResource - Invalid User
dotcms-dotcms-1      | 01:12:21.845  WARN  rest.WebResource - com.dotcms.rest.WebResource.authenticate(WebResource.java:522)
dotcms-dotcms-1      | 01:12:21.845  WARN  exception.ForbiddenException - {"error":"dotcms.api.error.forbidden: Invalid User"}
dotcms-dotcms-1      | com.dotcms.rest.exception.ForbiddenException: HTTP 403 Forbidden

...

...

dotcms-dotcms-1      | Caused by: com.dotcms.rest.exception.SecurityException: Invalid User
dotcms-dotcms-1      |  at com.dotcms.rest.WebResource.authenticate(WebResource.java:522) ~[dotcms_23.05_e3c7a96.jar:?]
dotcms-dotcms-1      |  at com.dotcms.rest.WebResource.getCurrentUser(WebResource.java:424) ~[dotcms_23.05_e3c7a96.jar:?]
dotcms-dotcms-1      |  at com.dotcms.rest.WebResource.init(WebResource.java:353) ~[dotcms_23.05_e3c7a96.jar:?]
dotcms-dotcms-1      |  at com.dotcms.rest.WebResource$InitBuilder.init(WebResource.java:886) ~[dotcms_23.05_e3c7a96.jar:?]
dotcms-dotcms-1      |  at com.dotcms.rest.api.v1.menu.MenuResource.getMenus(MenuResource.java:96) ~[dotcms_23.05_e3c7a96.jar:?]

[Will Ezell]

Did you set the environmental variable DOT_INITIAL_ADMIN_PASSWORD ?   If not, dotCMS will supply one for you.  You can go back into the initial startup logs and see the generated password, which gets spit out after the database has been imported.

--
http://dotcms.com - Open Source Java Content Management
---
You received this message because you are subscribed to the Google Groups "dotCMS User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dotcms+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dotcms/8e3ca525-5bde-4ff9-9008-942f1bb92ec2n%40googlegroups.com.

--

382 NE 191st St #92150

Miami, Florida 33179-3899

Main: 305-900-2001 | Direct: 978.294.9429

wi...@dotcms.com | dotcms.com

[Adam Jones]

Thanks Will. 

I used the default for the DOT_INITIAL_ADMIN_PASSWORD property that comes in the stock docker-compose.yml file.

I tried a couple of things after looking through the documentation:

- I updated the docker-compose file property for DOT_INITIAL_ADMIN_PASSWORD just to see if that would trigger something - that did not alter the behavior. I did notice that entering an intentionally incorrect password results in this message:

dotcms-dotcms-1      | 16-May-2023 22:57:59.473 INFO [url:POST//demo.dotcms.com/api/v1/authentication | lang:1 | ip:23.112.109.132 | Admin:false 

However, entering the default password of admin causes the security exception/invalid user message from my original post.

- Digging a little more, I thought that maybe the json.web.token.allowhttp might be influencing the behavior since I'm trying to connect without HTTPS for test purposes. I added DOT_JSON_WEB_TOKEN_ALLOWHTTP: 'true' to docker-compose.yml and executed docker compose up -d && docker compose logs -f . After firing up the containers I looked at the dotmarketing-config.properties and the value was still set to false. 

Seems like adding the entry to the docker-compose.yml should be fine?

I may have to explore configuring SSL. I tried this link: 

https://www.dotcms.com/docs/latest/ssl-configure-dotcms-to-run-ssl which no longer exists. 

If you could also share a link for your supported SSL configuration process, that would be great.

Edit: just ran across this one as well:

https://www.dotcms.com/docs/latest/how-to-modify-java-keystore-in-docker

Thanks again!

[Will Ezell]

Adam:

You should be able to hit the dotCMS container in SSL on port 8443.  Open that up in your docker config, start dotCMS and then hit

https://local.dotcms.site:8443/dotAdmin

To view this discussion on the web visit https://groups.google.com/d/msgid/dotcms/0b40b75c-82a3-4545-9838-57f5b2cc381an%40googlegroups.com.

[Adam Jones]

Maybe some additional information will help. 8443 is definitely defined in the docker-compose file - I haven't changed any of the settings in the docker-compose file that dotCMS supplies.

What we noticed:

Running on my local machine:

1 - (successful authentication) logging in through the /dotAdmin page, there is a successful authentication response. We receive a 200 and the response contains user context information, i.e. admin: true, backendUser:true, etc.

2 - JSESSIONID cookie is NOT in the response header of the call to /authentication but...

3 - the JSESSIONID cookie is subsequently sent in the request header to /menu, which returns a 200, thus displaying the admin screen + options

When firing up the containers on EC2:

1 -  (same successful authentication as above)

2 - JSESSIONID cookie is IN the response header of the call to /authentication but...

3 - the JSESSIONID cookie is NOT sent in the request header to /menu, which returns a 403, and the admin screen + options is not shown

==========

Summary: EC2 instance of dotCMS is not sending JSESSIONID cookie with any calls after successful /authentication. When manually adding the JSESSIONID to cookie header, those calls are successful.

We tested it successfully with curl, adding the JSESSIONID cookie to the request headers (--header).

I guess the question is what might cause the JSESSIONID to not be sent from /dotAdmin to /menu?

[Adam Jones]

I just got this part working Will. Thanks for the responses you shared.

On Tuesday, May 16, 2023 at 7:49:01 PM UTC-4 Will Ezell wrote: