I’ve been reading the 2.2.4 manual about authentication and security for the master or root account.
And since the security or authentication has been re-engineered as of 2.2 (and we were using 2.1.1), the way we were using geoserver needs to change.
In 2.1.1, since the password was not being encrypted, our geoserver had been customized at the GeoServerUserDao level, we injected a password encoder bean into this and encrypted the password using the Spring encoder.
Now looking at 2.2.4, I see that the a lot of thing has changed.
There are two things that we need:
1.) we need to use create or use a ROLE_ADMINISTRATOR with a name other than “root” – for example, “myappadmin”
2.) we need to keep the password encrypted on the hard drive – we dont need LDAP or other external systems. Since I see that encrypted passwords are not supported in 2.2.4, I figure this should be easier.
If I want to zip up the entire geoserver web app with the all these changes, what are my best approaches? (I figure that I could change the source code again or the spring context files but I think I would prefer to avoid that to avoid future upgrade issues.)
I tried to use the users.properties with content that looks like this:
I’ve been reading the 2.2.4 manual about authentication and security for the master or root account.
And since the security or authentication has been re-engineered as of 2.2 (and we were using 2.1.1), the way we were using geoserver needs to change.
In 2.1.1, since the password was not being encrypted, our geoserver had been customized at the GeoServerUserDao level, we injected a password encoder bean into this and encrypted the password using the Spring encoder.
Now looking at 2.2.4, I see that the a lot of thing has changed.
There are two things that we need:
1.) we need to use create or use a ROLE_ADMINISTRATOR with a name other than “root” – for example, “myappadmin”
2.) we need to keep the password encrypted on the hard drive – we dont need LDAP or other external systems. Since I see that encrypted passwords are not supported in 2.2.4, I figure this should be easier.
If I want to zip up the entire geoserver web app with the all these changes, what are my best approaches? (I figure that I could change the source code again or the spring context files but I think I would prefer to avoid that to avoid future upgrade issues.)
I tried to use the users.properties with content that looks like this:
Then I created manually created another user and added that user to the ADMIN group so that it can have the same privileges at root.
Then I packaged up all those files and along with other subdir in the security dir for others to use in my group.
–
Sean
On Thu, Feb 7, 2013 at 10:22 AM, Sean K <sk92129@…84…> wrote:
Hi,
I’ve been reading the 2.2.4 manual about authentication and security for the master or root account.
And since the security or authentication has been re-engineered as of 2.2 (and we were using 2.1.1), the way we were using geoserver needs to change.
In 2.1.1, since the password was not being encrypted, our geoserver had been customized at the GeoServerUserDao level, we injected a password encoder bean into this and encrypted the password using the Spring encoder.
Now looking at 2.2.4, I see that the a lot of thing has changed.
There are two things that we need:
1.) we need to use create or use a ROLE_ADMINISTRATOR with a name other than “root” – for example, “myappadmin”
2.) we need to keep the password encrypted on the hard drive – we dont need LDAP or other external systems. Since I see that encrypted passwords are not supported in 2.2.4, I figure this should be easier.
If I want to zip up the entire geoserver web app with the all these changes, what are my best approaches? (I figure that I could change the source code again or the spring context files but I think I would prefer to avoid that to avoid future upgrade issues.)
I tried to use the users.properties with content that looks like this:
Replacing the content of masterpw.digest directly is dangerous. The master password is also used to encrypt/decrypt the key store geoserver.jceks and is stored encrypted in security/masterpw/default/passwd (default master password provider). The masterpw.digest is used to avoid fetching the master password into memory for a root login.
If you want to change the master password, you have to trigger a master password change from the GUI to keep thins consistent.
Christian
Zitat von Sean K <sk92129@anonymised.com>:
I figured out a way around this.
I replaced the contents of masterpw.digest with the encrypted "geoserver"
Then I created manually created another user and added that user to the
ADMIN group so that it can have the same privileges at root.
Then I packaged up all those files and along with other subdir in the
security dir for others to use in my group.
On Thu, Feb 7, 2013 at 10:22 AM, Sean K <sk92129@anonymised.com> wrote:
Hi,
I've been reading the 2.2.4 manual about authentication and security for
the master or root account.
And since the security or authentication has been re-engineered as of 2.2
(and we were using 2.1.1), the way we were using geoserver needs to change.
In 2.1.1, since the password was not being encrypted, our geoserver had
been customized at the GeoServerUserDao level, we injected a password
encoder bean into this and encrypted the password using the Spring encoder.
Now looking at 2.2.4, I see that the a lot of thing has changed.
There are two things that we need:
1.) we need to use create or use a ROLE_ADMINISTRATOR with a name other
than "root" -- for example, "myappadmin"
2.) we need to keep the password encrypted on the hard drive -- we dont
need LDAP or other external systems. Since I see that encrypted
passwords are not supported in 2.2.4, I figure this should be easier.
If I want to zip up the entire geoserver web app with the all these
changes, what are my best approaches? (I figure that I could change the
source code again or the spring context files but I think I would prefer to
avoid that to avoid future upgrade issues.)
I tried to use the users.properties with content that looks like this:
A question for your above statement. I assume that I can trigger the master password change from the GUI and change it again after I “hack” in by changing the masterpw.digest and logging in as “root” with password “geoserver” encryped.
Replacing the content of masterpw.digest directly is dangerous. The master password is also used to encrypt/decrypt the key store geoserver.jceks and is stored encrypted in security/masterpw/default/passwd (default master password provider). The masterpw.digest is used to avoid fetching the master password into memory for a root login.
If you want to change the master password, you have to trigger a master password change from the GUI to keep thins consistent.
I’ve been reading the 2.2.4 manual about authentication and security for
the master or root account.
And since the security or authentication has been re-engineered as of 2.2
(and we were using 2.1.1), the way we were using geoserver needs to change.
In 2.1.1, since the password was not being encrypted, our geoserver had
been customized at the GeoServerUserDao level, we injected a password
encoder bean into this and encrypted the password using the Spring encoder.
Now looking at 2.2.4, I see that the a lot of thing has changed.
There are two things that we need:
1.) we need to use create or use a ROLE_ADMINISTRATOR with a name other
than “root” – for example, “myappadmin”
2.) we need to keep the password encrypted on the hard drive – we dont
need LDAP or other external systems. Since I see that encrypted
passwords are not supported in 2.2.4, I figure this should be easier.
If I want to zip up the entire geoserver web app with the all these
changes, what are my best approaches? (I figure that I could change the
source code again or the spring context files but I think I would prefer to
avoid that to avoid future upgrade issues.)
I tried to use the users.properties with content that looks like this:
A question for your above statement. I assume that I can trigger the
master password change from the GUI and change it again after I "hack" in
by changing the masterpw.digest and logging in as "root" with password
"geoserver" encryped.
Is that correct?
Never tried this procedure based on a hacked masterpw.digest. Make a backup of your <GEOSERVER_DATA_DIR>/security directory and try a master password change. If you can login as root with your new password, the procedure was successful.
Christian
On Mon, Feb 11, 2013 at 4:27 AM, <christian.mueller@anonymised.com> wrote:
Hi Sean
Replacing the content of masterpw.digest directly is dangerous. The master
password is also used to encrypt/decrypt the key store geoserver.jceks and
is stored encrypted in security/masterpw/default/**passwd (default master
password provider). The masterpw.digest is used to avoid fetching the
master password into memory for a root login.
If you want to change the master password, you have to trigger a master
password change from the GUI to keep thins consistent.
Christian
Zitat von Sean K <sk92129@anonymised.com>:
I figured out a way around this.
I replaced the contents of masterpw.digest with the encrypted "geoserver"
Then I created manually created another user and added that user to the
ADMIN group so that it can have the same privileges at root.
Then I packaged up all those files and along with other subdir in the
security dir for others to use in my group.
On Thu, Feb 7, 2013 at 10:22 AM, Sean K <sk92129@anonymised.com> wrote:
Hi,
I've been reading the 2.2.4 manual about authentication and security for
the master or root account.
And since the security or authentication has been re-engineered as of 2.2
(and we were using 2.1.1), the way we were using geoserver needs to
change.
In 2.1.1, since the password was not being encrypted, our geoserver had
been customized at the GeoServerUserDao level, we injected a password
encoder bean into this and encrypted the password using the Spring
encoder.
Now looking at 2.2.4, I see that the a lot of thing has changed.
There are two things that we need:
1.) we need to use create or use a ROLE_ADMINISTRATOR with a name other
than "root" -- for example, "myappadmin"
2.) we need to keep the password encrypted on the hard drive -- we dont
need LDAP or other external systems. Since I see that encrypted
passwords are not supported in 2.2.4, I figure this should be easier.
If I want to zip up the entire geoserver web app with the all these
changes, what are my best approaches? (I figure that I could change the
source code again or the spring context files but I think I would prefer
to
avoid that to avoid future upgrade issues.)
I tried to use the users.properties with content that looks like this:
I use GeoServer 2.2.3, I tried to check the check box “Enable direct integration with GeoServer WMS” on the page “Caching defaults”. All the other options are as default. I submit the form, and log out and log in again, the check box “Enable direct integration with GeoServer WMS” is still checked. But if I reboot tomcat, and then login GeoServer again, the check box is unchecked. Is this a bug? How to keep the check box checked?
I found out that there is a file gwc-gs.xml and a file gwc-gs.xml.tmp in the data folder. (This is weird, probably because I login in two browsers and that messed up). I deleted the file gwc-gs.xml.tmp and set directWMSIntegrationEnabled as true in the file gwc-gs.xml. I reboot Tomcat, the check boxed is checked.
I use GeoServer 2.2.3, I tried to check the check box “Enable direct integration with GeoServer WMS” on the page “Caching defaults”. All the other options are as default. I submit the form, and log out and log in again, the check box “Enable direct integration with GeoServer WMS” is still checked. But if I reboot tomcat, and then login GeoServer again, the check box is unchecked. Is this a bug? How to keep the check box checked?
The .tmp file is where GeoServer saves changes, but it shouldn’t. It’s not because you were using multiple browsers. Already reported as http://jira.codehaus.org/browse/GEOS-5536
I found out that there is a file gwc-gs.xml and a file gwc-gs.xml.tmp in the data folder. (This is weird, probably because I login in two browsers and that messed up). I deleted the file gwc-gs.xml.tmp and set directWMSIntegrationEnabled as true in the file gwc-gs.xml. I reboot Tomcat, the check boxed is checked.
I use GeoServer 2.2.3, I tried to check the check box “Enable direct integration with GeoServer WMS” on the page “Caching defaults”. All the other options are as default. I submit the form, and log out and log in again, the check box “Enable direct integration with GeoServer WMS” is still checked. But if I reboot tomcat, and then login GeoServer again, the check box is unchecked. Is this a bug? How to keep the check box checked?
Thanks,
Meichun
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013
and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb
This transmission is intended for the named addressee(s) only and may contain sensitive or protectively marked material up to RESTRICTED and should be handled accordingly. Unless you are the named addressee (or authorised to receive it for the addressee) you may not copy or use it, or disclose it to anyone else. If you have received this transmission in error please notify the sender immediately. All email traffic sent to or from us, including without limitation all GCSX traffic, may be subject to recording and/or monitoring in accordance with relevant legislation.