Announcement Announcement Module
No announcement yet.
Where does ${security.encryptPassword} come from? Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Where does ${security.encryptPassword} come from?

    Looking at the GH application and am trying to figure out where the ${security.encryptPassword} is coming from?

    <gh:environment-bean id="passwordEncoder">
    		<gh:when environment="embedded">
    			<beans:bean class="" factory-method="getInstance" />
    			<beans:bean class="">
    				<beans:constructor-arg value="${security.encryptPassword}" />

  • #2
    Make sure to pull down the latest revision of the code--the greenhouse-specific environment bean tags have been replaced with official Spring Framework 3.1. profile support for several weeks now. Also, the code is now fully documented so you'll definitely want to update for that.

    The various ${placeholders} in the config are used to inject externalized property values. The actual values come from a /WEB-INF/classes/ file loaded by the PropertyPlaceholderConfigurer defined in properties.xml. We do not version control the actual file or otherwise expose its properties values, else that would be a security vulnerability.

    For the CI build that deploys Greenhouse into production, we simply define the secure property values in a <profile/> in the local Maven <settings/> file, then rely on the Maven properties plugin to create the file as part of the build process.



    • #3
      Thanks Keith. I figured the properties were being externalized. Do you have a list of the properties that should be added to a maven profile? Maybe you could cut and paste the profile you are using in production and remove the actual values?

      I also didn't realize that GH also got bumped to using a snapshot of Spring 3.1!


      • #4
        Here's the maven settings snippet showing the properties that can be configured externally:

        You can find these referenced across the various Spring XML files, for example data.xml, security.xml, and mail.xml. Some are also injected using @Value annotations in code. Some of these also have defaults if they are not specified (for example, see properties.xml and mail.xml).

        Of course, if you run with the embedded profile no externalized property values are required.