Hi,
So in my uPortal source tree, I have an overlay project for each portlet
that gets deployed into the EAR. Generally these overlay project do 2
things. 1) Filtering and 2) Plutoifying
Number 1) is because when I push portlet WARs to my local Nexus I use a
blank filter file. Therefore the portlet projects own build filtering
does nothing, leaving the tokens intact which are later replaced by
uPortals overlay project.
uPortals portlet overlay artifacts produced are environment specific and
therefore "should" not be in the local (.m2) maven repo.
Your suggestion will remove the need for number 1) above meaning that
overlays are reusable across environments, which is good!!
If the pluto stuff could be done at a different stage, then the portlet
overlays might not be necessary at all :-)
FYI for my uP4.1 server set up, I've been experimenting not using
uPortals EAR project. By using my own separate my-edu-ear project that
just pulls everything together I can speed up environment re-build times
assuming that everything is pre-built.
Often a rebuild is needed only because a portlet version number has
increased, yet everything gets re-filtered for that environment.
To achieve my stand-alone ear project I've followed UW-Madison's
approach and used an environment specific maven group name for the
overlayed artefacts. So I can keep the filtered artifacts hanging
around. However I've struggled about WHEN to do the filtering-overlay
and have so far conceded to adding a my-edu-eay/overlays sub-project. (I
believe UW hit a Jenkins many-project explosion at this stage!).
... still, I'm saving on the uPortal source build and also I don't have
to cut a local release of my uPortal fork every time a new portlet war
is added / removed.
I really hope this makes sense to you? If not, please understand that
NOT having artifacts that are environment specific is a massive step
forward.
-- Anthony.
On 16/01/15 20:26, James Wennmacher wrote:
Update: In regards to portlets, especially those that do DB
connections, load override property values from a location outside the
war similar to the way uPortal does (see
https://wiki.jasig.org/display/UPM41/Properties+Files+and+Properties+Overrides),
I propose we change the Apereo portlets to load property values in the
Spring configuration from
* local property files in war
* |${CATALINA_HOME}/portal/overrides.properties|
* |${CATALINA_HOME}/portal/{portletName}_overrides.properties|
* |${PORTAL_HOME}/overrides.properties|
* |${PORTAL_HOME}/{portletName}_overrides.properties|
The reason is that the main values that will be in the
overrides.properties file will be the following
hibernate.connection.driver_class=${environment.build.hibernate.connection.driver_class}
hibernate.connection.url=${environment.build.hibernate.connection.url}
hibernate.connection.username=${environment.build.hibernate.connection.username}
hibernate.connection.password=${environment.build.hibernate.connection.password}
hibernate.connection.validationQuery=${environment.build.hibernate.connection.validationQuery}
hibernate.dialect=${environment.build.hibernate.dialect}
(and some others for other uPortal Aggregation DB connections) and these
property names are the same property names that are used by uPortal and
portlets. The property value will be whatever the override value is,
not the build environment string.
This allows the common use case of having one file that applies to
uPortal and all portlets and sets the DB connection url (optional in
case you want to make it more 'hidden'), username, and password for
maintenance (one file to change when DB passwords change) and improved
security (more restricted file access to sensitive info). The
{portletName}_overrides.properties allows for the rare case of needing
something else. One example that I can think of is an encryption key
value used by a portlet to encrypt sensitive user portlet preferences
before storing them into the DB, though I could also see having that be
global, or a conflicting property name between a couple of portlets.
Please let me know if you have any feedback on this idea.
Thanks,
James Wennmacher - Unicon
480.558.2420
------------------------------------------------------------------------
*From: *"James Wennmacher" <[email protected]>
*To: *[email protected], [email protected]
*Sent: *Monday, December 15, 2014 11:37:14 AM
*Subject: *More securely handling storage of sensitive information
I'm going to be incorporating code to handle Exchange Impersonation in
Exchange Web Services in the Calendar portlet. The current
implementation stores the the username and password in a properties
file. Since this is such a powerful trusted account, I'd like to
improve the security a bit above that implementation. What have others
done? Has anyone implemented something that I can package into the
portlet utilities project to improve the security aspects of storing
credentials?
What I was thinking of doing was having an encryption key stored in
portlet preferences and the encrypted password in a properties file,
plus the option of retrieving the properties files values from
${CATALINA_HOME}/portlet/{portletName}_overrides.properties and
${PORTLET_HOME}/{portletName}_overrides.properties. This certainly
isn't perfect, but at least it prevents someone who gets access to the
file system from easily obtaining the credential values without some
additional work and another knowledge barrier to overcome. It also
allows for different encryption encryption keys for different portlets.
I'd love to do something like this for the DB credentials as well, but I
haven't looked into the possibility of that.
Thoughts on this approach? I'm hoping someone might have already done
something and hopefully can share their solution, even if it is just a
partial.
Thanks,
--
James Wennmacher - Unicon
480.558.2420
--
You are currently subscribed to [email protected] as:
[email protected]
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/uportal-dev
--
You are currently subscribed to [email protected] as:
[email protected]
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/uportal-dev
