Is there a way to disable JSF pages when deploying to a production environment, but use these features in a development environment?
I am using Java EE with JSF to create a web application. I use a number of JSF pages to carry out debugging and testing. I want to disable these pages when the application is deployed in its production environment. No-one, not even develops will need to use these pages on the deployed application, so I want to disable them as a security precaution.
I do not want to simply restrict access to authenticated users. Firstly, this makes it tedious to use the debug features, as a login is required. And secondly, the debug features are quite powerful, and if there is a vulnerability in my web application, it could be devastating for an attacker to gain access to these features.
You can use the Maven WAR plugin in order to exclude resources from your build. You are allowed to use wildcards an even expressions to specify what you want to exclude.
Let's refer to some adapted example from the docs:
<build>
<plugins>
<plugin>
<artifactId>maven-war-plugin</artifactId>
<version>2.4</version>
<configuration>
<packagingExcludes>*-test.xhtml</packagingExcludes>
</configuration>
</plugin>
</plugins>
</build>
That will exclude all the -test.xhtml ended resources from the root of your web application. You can develop this as far as you want to accomplish your requirements.
See also:
Including and Excluding Files From the WAR
Related
I am working on one project and we are using tool Whitesource for our project.
The system Whitesource tells me usually that I need to update some dependency. Now it just says
Whitesource shows a problem Security Vulnerability with the message:
An issue was found in io.springfox:springfox-swagger-ui. This vulnerability can lead to �Log injection�- whereas untrusted data gets written into log files/entries. It allows attackers to forge log entries or inject malicious content into the logs.
pom.xml
<dependency>
<groupId>io.springfox</groupId>
<artifactId>springfox-swagger-common</artifactId>
<version>3.0.0</version>
</dependency>
<dependency>
<groupId>io.springfox</groupId>
<artifactId>springfox-swagger2</artifactId>
<version>3.0.0</version>
<scope>compile</scope>
</dependency>
Please help me solve the problem or tell me where to start solving the problem.
Unfortunately, SpringFox https://github.com/springfox/springfox is not maintained for last 2 years. Applications currently leveraging SpringFox should migrate to SpringDoc.
SprinDoc GitHub repo and here is migration guide
Unfortunately, there is currently no fix available from Springfox.
A little explanation: With this security issue, an attacker could write untrustworthy data in the log files and thus falsify log entries or inject malicious content into the logs.
How can you use Liquibase with an Azure SQL database and Azure Active Directory Authentication? Specifically, I want to connect using ActiveDirectoryPassword authentication mode as documented here:
https://learn.microsoft.com/en-us/sql/connect/jdbc/connecting-using-azure-active-directory-authentication?view=sql-server-ver15#connecting-using-activedirectorypassword-authentication-mode
I cannot figure out how to call the Liquibase CLI to make this happen.
Is this possible?
I was able to get this to work. I am not very familiar with Java (we use Liquibase with a C# project), so I think some of the Java pieces tripped me up.
There were a few things I had to do to make this work:
I needed to add some properties to the URL I sent to Liquibase:
--url="jdbc:sqlserver://REDACTED.database.windows.net;databaseName=REDACTED;authentication=ActiveDirectoryPassword;encrypt=true;trustServerCertificate=true"
ActiveDirectoryPassword is what tells the driver to use the authentication mechanism I wanted. I also had to add encrypt=true and trustServerCertificate=true to avoid some SSL errors I was getting (from: https://learn.microsoft.com/en-us/sql/connect/jdbc/connecting-with-ssl-encryption?view=sql-server-ver15).
I needed the MSAL4J (Azure Active Directory) libraries in my classpath. I added them to the liquibase/lib directory so that the default Liquibase launcher scripts would add them for me. I got caught on this, too, because I needed to use Maven which we do not use. After downloading Maven, I used the copy-dependencies plugin to download the dependencies I needed.
mvn dependency:copy-dependencies
Here was the simple pom.xml I used:
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>com.mycompany.app</groupId>
<artifactId>my-app</artifactId>
<version>1</version>
<dependencies>
<dependency>
<groupId>com.microsoft.azure</groupId>
<artifactId>adal4j</artifactId>
<version>1.6.3</version>
</dependency>
</dependencies>
</project>
I also put these dependencies in the liquibase/lib directory so they were automatically included in the classpath. The instructions from Microsoft were helpful in leading me to the correct places:
https://learn.microsoft.com/en-us/sql/connect/jdbc/connecting-using-azure-active-directory-authentication?view=sql-server-ver15#connecting-using-activedirectorypassword-authentication-mode
Also, not sure it was required to meet my goal, but I upgraded to the latest Liquibase (3.8.7) and latest SQL Server drivers (8.2):
https://learn.microsoft.com/en-us/sql/connect/jdbc/download-microsoft-jdbc-driver-for-sql-server?view=sql-server-ver15
Using Broadleaf Commerce version 5.2.2-GA. I have implemented custom search capability using spring-data-solr.
Seeing this issue:
[org.broadleafcommerce.cms.url.domain.URLHandlerImpl]
are managed classes within the MergePersistenceUnitManager
but were not detected as being transformed by the EntityMarkerClassTransformer. There can be multiple causes for this:
1. Session persistence is enabled in your servlet container (like Tomcat) and an entity object has been loaded by the container before being loaded by the application's classloader. Ensure that session persistence is disabled; in Tomcat ensure that a <Manager pathname="" /> element exists in your context.xml.
2. You are inadvertently using class scanning to find a ServletContainerInitializer class, and your servlet container is loading all classes before transformers have been registered. If you are using a web.xml, ensure that there is an <absolute-ordering /> element somewhere in that file. If you are not using a web.xml and are using Spring Boot, then you likely need to add one. See https://www.broadleafcommerce.com/docs/core/5.2/broadleaf-concepts/key-aspects-and-configuration/app-server-configuration/tomcat for the example web.xml
3. The classes are being used as apart of an #Bean method or in some other runtime capacity that is initialized prior to persistence manager startup
I can get around the error by either:
removing spring-instrument.jar, via site/pom.xml overriding spring-boot-maven-plugin config:
<pluginManagement>
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<configuration combine.self="override">
</configuration>
</plugin>
</plugins>
</pluginManagement>
Removing 'specifically' the spring-data-solr dependency (just to prove it causes the error), i.e. from core/pom.xml, removing this:
<dependency>
<groupId>org.springframework.data</groupId>
<artifactId>spring-data-solr</artifactId>
</dependency>
I am happy to remove instrumentation for the time being, although this causes issues with the Auditing functionality. I.e. when attempting to save a BLC organic entity (such as StaticAssetImpl), due to the fact spring-instrumentation is not available, I see this:
java.lang.NullPointerException: null
at org.broadleafcommerce.common.audit.AbstractAuditableListener.setAuditData(AbstractAuditableListener.java:88)
Ideally in the longer term, I would like to safely be able to include the spring-data-solr dependency. NOTE: I can safely use spring-data-commons and spring-data-jpa, it appears that spring-data-solr is solely causing the issue. I have tried spring-data-solr 3.0.5.RELEASE, 3.0.8.RELEASE (latest) and 2.0.9.RELEASE.
In the meantime, have been looking for a way to disable Auditing, cant seem to find any documentation. I have tried overriding Entities to remove the #EntityListener, tried to override the AdminAuditableListener, tried to look for a property that would disable it but no luck as yet.
Appreciate any help with either a short term workaround to disable Auditing, disable Auditing for specific Entities only or perhaps something I have not tried that could make spring-data-solr compatible.
Thanks
The error you are running into regarding UrlHandlerImpl was resolved in Broadleaf 5.2.3-GA, see https://github.com/broadleafcommerce/issues/issues/5. The latest Broadleaf release is actually 5.2.6-GA.
There might be something inadvertent (scanning or something) that Spring Data Solr adds, but generally this piece shouldn't be an issue.
I am searching the web for information regarding the usage of Oracle ADF as a component suite (and not as a development framework), alongside vanilla JSF (2.0).
I am working with a client that insists the solution uses the Oracle ADF UI components. The rest of the Fusion Middleware, however, can be completely skipped for all he cares. Therefore, I'd like to stay as close to the Java EE-JSF2 blueprints as possible, and only resort to ADF as a UI component library, as one would with PrimeFaces, for example.
So, the question - is it possible? Does ADF imposes limitations/dependencies that would prevent this scenario? Can we use it solely as a component library, or must we depend on its heavyweight framework to make them work?
It does not work; at least, not as one would expect. In short: ADF does indeed support JSF2 and Facelets, and they coexist nicely in a single application. As long as you don't mix them together.
I intended to use ADF as a component library, in a way similar to how one uses PrimeFaces or RichFaces: you add the correct dependencies, config what needs to be configured, and you're good to go. When Oracle says that ADF supports JSF2 and Facelets, this is the scenario that one would assume.
To start, you cannot use ADF components outside of a <af:document /> tag (or trinidad's counterpart); which means that content outside this tag is ignored, reducing the ability to use Facelets to a minimum. So, you'll hardly have any Facelets code on the same page where ADF components reside.
JSF + CDI integration is only available through the Mojarra implementation. Using MyFaces (the base for the current ADF version), one might make it work through updating the MyFaces jars and adding CODI, but it does not work out-of-the-box and I did not take the time to investigate it further.
To add to that, for layout management, you're stuck with the ADF way (through pageTemplateDef and pageTemplate tags), since mixing in Facelets is difficult due to the dependency on the document tag. So you see, Facelets support is there, "standard" JSF2 pages can exist in a ADF application - but to use ADF's components, you need to be in an ADF page.
To anyone that might be interested, once you populate your local maven repository using JDeveloper (as per the techniques suggested on the comments in the original question), the minimal dependencies to have ADF UI components in a web application (war) that can be run on WebLogic 12c or Glassfish with ADF essentials, are the following:
<dependency>
<groupId>javax</groupId>
<artifactId>javaee-web-api</artifactId>
<version>6.0</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>com.oracle.adf</groupId>
<artifactId>trinidad-api</artifactId>
<version>12.1.2-0-0</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>com.oracle.adf</groupId>
<artifactId>trinidad-impl</artifactId>
<version>12.1.2-0-0</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>com.oracle.adf</groupId>
<artifactId>adf-richclient-api-11</artifactId>
<version>12.1.2.0.40.66.34</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>com.oracle.adf</groupId>
<artifactId>adf-richclient-impl-11</artifactId>
<version>12.1.2.0.40.66.34</version>
<scope>provided</scope>
</dependency>
You'll also need to add several other configuration files:
WEB-INF/adfc-config.xml
META-INF/adf-config.xml
META-INF/connections.xml
META-INF/wsm-assembly.xml
Along with further ADF boilerplate configuration on faces-config.xml and web.xml files.
So, the answer so far is:
Is it possible (to use ADF as a component library)? Yes.
Are there any limitations? There's no CDI (out of the box), and limited Facelets support. JSF2 ajax capabilities cannot be used within a ADF document - you must resort to the ADF partial page rendering, but JSF2 custom components and any ClientBehavior you may code work fine.
Is it worth the hassle? No.
Couple of months ago, Oracle ADF was supporting only JSF 1.2.
But with the release of JDeveloper 12c there are lots of new features and improvements over the IDE and over the Oracle ADF, for which there is JSF 2.0 Support now.
So, to answer your question - yes, you can use Oracle ADF with JSF2/Facelets.
If you just want a WAR through Maven do this (In JDeveloper 12c):
New Application -> Custom Application
Add the ADF Faces technology (shuttle to the right).
In the last step of the wizard choose "Use Maven".
I would like to enforce a strict Maven dependency policy which goes beyond the basic checksumPolicy=fail approach.
This is an attempt to provide protection against a modified release dependency which still has a valid digest value also known as a "dependency chain attack".
This situation could arise from the following scenarios:
the dependency has been updated, but the author has not updated the version number and managed to overwrite the earlier release (or their repo account has been compromised)
a man-in-the-middle attack is in place (with on-the-fly rewriting/hashing)
the repository itself has been compromised
In discussions with other developers one approach to combat the above is to have a list of known MD5/SHA digests in the pom.xml and have Maven verify that the downloaded dependency has the same digest. This ensures that so long as the source code repository remains secure, any included dependencies that have been compromised will be detected.
Thus my question is twofold:
are there any alternative approaches that would work more efficiently?
are there any existing implementations/plugins that do this job?
If anyone is wrestling with this issue themselves I've created a Maven Enforcer Plugin Rule that deals with it. You can specify a list of artifact URNs that include the expected SHA1 hash value and have the enforcer verify that this is indeed what is being used in the build.
It is available through Maven Central under MIT license, with source code in GitHub here: https://github.com/gary-rowe/BitcoinjEnforcerRules
While the project indicates that it is for the Bitcoinj library, it is actually a general purpose solution which could be included in any security conscious build process. It will also scan your existing project and identify any problem area while it automatically builds the whitelist for you.
Below is an example of the configuration you'd require in your project to use it.
<build>
<plugins>
...
<!-- Use the Enforcer to verify build integrity -->
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-enforcer-plugin</artifactId>
<version>1.2</version>
<executions>
<execution>
<id>enforce</id>
<phase>verify</phase>
<goals>
<goal>enforce</goal>
</goals>
<configuration>
<rules>
<digestRule implementation="uk.co.froot.maven.enforcer.DigestRule">
<!-- Create a snapshot to build the list of URNs below -->
<buildSnapshot>true</buildSnapshot>
<!-- List of required hashes -->
<!-- Format is URN of groupId:artifactId:version:type:classifier:scope:hash -->
<!-- classifier is "null" if not present -->
<urns>
<urn>antlr:antlr:2.7.7:jar:null:compile:83cd2cd674a217ade95a4bb83a8a14f351f48bd0</urn>
<urn>dom4j:dom4j:1.6.1:jar:null:compile:5d3ccc056b6f056dbf0dddfdf43894b9065a8f94</urn>
<urn>org.bouncycastle:bcprov-jdk15:1.46:jar:null:compile:d726ceb2dcc711ef066cc639c12d856128ea1ef1</urn>
<urn>org.hibernate.common:hibernate-commons-annotations:4.0.1.Final:jar:null:compile:78bcf608d997d0529be2f4f781fdc89e801c9e88</urn>
<urn>org.hibernate.javax.persistence:hibernate-jpa-2.0-api:1.0.1.Final:jar:null:compile:3306a165afa81938fc3d8a0948e891de9f6b192b</urn>
<urn>org.hibernate:hibernate-core:4.1.8.Final:jar:null:compile:82b420eaf9f34f94ed5295454b068e62a9a58320</urn>
<urn>org.hibernate:hibernate-entitymanager:4.1.8.Final:jar:null:compile:70a29cc959862b975647f9a03145274afb15fc3a</urn>
<urn>org.javassist:javassist:3.15.0-GA:jar:null:compile:79907309ca4bb4e5e51d4086cc4179b2611358d7</urn>
<urn>org.jboss.logging:jboss-logging:3.1.0.GA:jar:null:compile:c71f2856e7b60efe485db39b37a31811e6c84365</urn>
<urn>org.jboss.spec.javax.transaction:jboss-transaction-api_1.1_spec:1.0.0.Final:jar:null:compile:2ab6236535e085d86f37fd97ddfdd35c88c1a419</urn>
<!-- A check for the rules themselves -->
<urn>uk.co.froot.maven.enforcer:digest-enforcer-rules:0.0.1:jar:null:runtime:16a9e04f3fe4bb143c42782d07d5faf65b32106f</urn>
</urns>
</digestRule>
</rules>
</configuration>
</execution>
</executions>
<!-- Ensure we download the enforcer rules -->
<dependencies>
<dependency>
<groupId>uk.co.froot.maven.enforcer</groupId>
<artifactId>digest-enforcer-rules</artifactId>
<version>0.0.1</version>
</dependency>
</dependencies>
</plugin>
...
</plugins>
</build>
Sounds like a good job for the repository itself. Check out this other thread regarding a similar question.
I've no familiarity with the PGP signing scenario in Nexus, but does that sound like a good start?