Default login credentials for new Liferay 7.1 virtual instance

Max Max Max, modified 2 Years ago. New Member Posts: 23 Join Date: 2/2/07 Recent Posts
I'm really struggling to create a virtual instance and don't recall having had these problems in 6.x + mysql.

I have a fresh Liferay 7.1.2 GA3 installation on ubuntu and a postgresql db.

After using the setup wizard (and creating a new admin user) and restarting the portal on localhost:8080, I then create a new virtual instance as follows:

Web ID: mydomain.com
Virtualhost: inst01.mydomain.com
Mail domain: mydomain.com
Max users: 0
Active: yes

I then log out of the localhost portal, browse to https://inst01.mydomain.com, and now have to log in to the new instance.

Unfortunately the online documentation (https://dev.liferay.com/en/discover/portal/-/knowledge_base/7-1/virtual-instances) says absolutely nothing about what the login  credentials for the new instance will be! After googling around I found a number of people having the same problem and the general advice is to use the credentials "test@mydomain.com" and password "test" - it would be great if this was added to the documentation page. But this unfortunately just results in a invalid authentication error! 

The default configuration is that users can create their own accounts from a link on the login page, so I try to create a user test@mydomain.com and password test, which then results in an error that the user already exists! But now at least I can log in to the virtual instance. 

The next problem arises that I need to configure the instance and so goto to Control Panel - Configuration - Instance Settings. But all the fields are grayed out and uneditable!  So I checked the roles associated with the user test@mydoamin.com and this user has been automatically assigned Administrator and Power User roles.

This problem is completely preventing me from using the portal, so any advice would be most welcome.
thumbnail
David H Nebinger, modified 6 Years ago. Liferay Legend Posts: 14933 Join Date: 9/2/06 Recent Posts
test@liferay.com and test for the password.

If you use the company.default.web.id property in portal-ext.properties, this would be used as the domain for the email address instead.

Note that you have full control over these settings prior to first launch of the portal by setting the following portal-ext.properties:

default.admin.password=test
default.admin.screen.name=test
default.admin.email.address.prefix=test
default.admin.first.name=Test
default.admin.middle.name=
default.admin.last.name=Test

Because of this flexibility, documenting something like "Always use test@liferay.com and test" to log in is just plain wrong. And documenting all the aspects for how to determine what the admin login is going to be, well that's easy to do but it will not be an easily findable page about what initial login credentials to use.
​​​​​​​
thumbnail
Olaf Kock, modified 6 Years ago. Liferay Legend Posts: 6441 Join Date: 9/23/08 Recent Posts
David H Nebinger

test@liferay.com and test for the password.

...
Because of this flexibility, documenting something like "Always use test@liferay.com and test" to log in is just plain wrong. And documenting all the aspects for how to determine what the admin login is going to be, well that's easy to do but it will not be an easily findable page about what initial login credentials to use.
​​​​​​​
it's actually test@<maildomain>, where the part before the "@" is configurable, as described.

in your case test@mydomain.com, assuming that you didn't configure anything upfront. The password, as David says, is "test". I don't like those default passwords.

This triggers me - I'm going to write a feature request to make this data explicit in the "new instance" dialog to just enter the name and password
thumbnail
Olaf Kock, modified 6 Years ago. Liferay Legend Posts: 6441 Join Date: 9/23/08 Recent Posts
Olaf Kock
it's actually test@<maildomain>, where the part before the "@" is configurable, as described.

in your case test@mydomain.com, assuming that you didn't configure anything upfront. The password, as David says, is "test". I don't like those default passwords.

This triggers me - I'm going to write a feature request to make this data explicit in the "new instance" dialog to just enter the name and password
Filing LPS-91477 for this, I found out that test@<maildomain> isn't even correct: When you've given "bruno.admin@liferay.com" as administrator in your first instance, it's "bruno.admin@maildomain" in the new instance. But "test" is correct as password.

Edit: The secret sauce is more secret: If your first domain's account (provided in setup wizard) is "bruno.admin@<firstinstancemaildomain>", then the account will be "bruno.admin@<secondinstancemaildomain>". Otherwise it's "test@<secondinstancemaildomain>". m(

Roger, Over and Out. You should have enough empirical basis to figure out the account's name. Vote for the feature request ;)
Max Max Max, modified 2 Years ago. New Member Posts: 23 Join Date: 2/2/07 Recent Posts
Hello Olaf,

Thanks. This did the trick. In my case it was franz@<secondinstancemaildomain> with password test.

The portal then prompted to accept the User Terms.

However, after logging in with these credentials, when I then browse to Control Panel -> Configuration -> Instance Settings, all fields are grayed out and I can't configure the virtual instance. It's as if the user has no rights to make changes .

Thanks for the help.
thumbnail
Olaf Kock, modified 6 Years ago. Liferay Legend Posts: 6441 Join Date: 9/23/08 Recent Posts
Max Max Max
However, after logging in with these credentials, when I then browse to Control Panel -> Configuration -> Instance Settings, all fields are grayed out and I can't configure the virtual instance. It's as if the user has no rights to make changes .
That user should have all administrative permissions one can get on the secondary instance (it's less than on the primary instance).
I currently have 7.2 alpha1 running, and can change the instance settings.
If you can sign in with this user, it'll be the only one you have on that system, thus there's not much room for any glitches...

That being said... "works for me, can't reproduce". Sorry.

Maybe check if there are any problems loading the JS content? My tests were always with identical values for webid, virtual host and mail domain. And on a different version - this all might contribute.