Buscar este blog

lunes, 26 de diciembre de 2016

Windows 7 - Reboot and select proper boot device

My second windows 7 apocalypse in three weeks.

These are the steps and links I followed in order to not format (again) my system:
1) Ensure my main hard drive works properly
I disconnected the others hard drives (I have three) and I searched my main hard drive in BIOS.
The HD was there and was the first option to boot menu.

2) Try windows 7 gui repair tools
I booted from a win7 install DVD and tried to use all repair options. The problem was that my previous win7 installation was not recognized.

3) Try windows 7 command line repair tools
One of the repair win7 options is to open a DOS prompt. There I put the following commands:
bootrec /FixMbr
bootrec /FixBoot
bootrec /RebuildBcd
The first one was successful, but the other two prompted "element not found"

4) Reactivate main partition (https://aitorlozano.com/arreglando-el-arranque-de-windows/)
With these commands I could set the hard drive partition as active.
list disk
select disk = X
list partition
select partition = Y
active
exit X
X is the disk number associated with your main hard drive. You check this number with the list disk command.
Y is the disk partition. Usually has the value 1.

Then, I could execute the previous commands successful (bootrec).

5) Change boot order.
The next time I restarted the PC I got this error: "bootmgr is missing".
The only avaliable option was "Press Ctrl+Alt+Supr" to reboot, and then back to the same message.
In this situation I was not able to boot from win7 install DVD neither. So I went to BIOS again and I changed the devices boot order by selecting DVD as first option. In this way, next time it will try to boot front win7 install DVD again.

6) Replace bootmgr (https://answers.microsoft.com/en-us/windows/forum/all/bootrec-error-element-not-found/cac41df1-0590-4ea3-b7cd-134256e84c8f)
Using win7 disk I put the following commands:
bcdboot C:\windows /l es-ES

One more reboot and success!!!!

domingo, 25 de diciembre de 2016

Password hash 2016 - Argon2

Argon2 was the winner of Password Hashing Competition.

The project is written in C, but there is a java version that uses JNA (Java Native Access):  https://github.com/phxql/argon2-jvm

Maven configuration.
<dependency>
    <groupId>de.mkammerer</groupId>
    <artifactId>argon2-jvm</artifactId>
    <version>2.1</version>
</dependency>

Java example (most of the examples I saw are inaccurate due the fact that the password is actually wiped after the encryption);
import de.mkammerer.argon2.Argon2;
import de.mkammerer.argon2.Argon2Factory;

public class Main {

 public static void main(final String[] args) {
  final String hash = generateHash("secret".toCharArray());

  System.out.println(isValidPass("secret".toCharArray(), hash));
  System.out.println(isValidPass("otherPass".toCharArray(), hash));
 }

 private static String generateHash(final char[] pass) {
  final Argon2 argon2 = Argon2Factory.create(Argon2Factory.Argon2Types.ARGON2i, 64, 64);
     final char[] passwd = "secret".toCharArray();
  try {
   final int t = 2;
   final int m = 65536;
   final int p = 1;
      return argon2.hash(t, m, p, passwd);
  } finally {
      argon2.wipeArray(passwd);
  }
 }

 private static boolean isValidPass(final char[] passwd, final String hash) {
  final Argon2 argon2 = Argon2Factory.create(Argon2Factory.Argon2Types.ARGON2i, 64, 64);
  try {
   return argon2.verify(hash, passwd);
  } finally {
      argon2.wipeArray(passwd);
  }

 }
}

sábado, 26 de noviembre de 2016

Apache CXF - Hide service list

Apache CXF generates an HTML page in which you can see all SOAP and REST services published. This is very useful when developing, but may not be suitable por a Production enviorement because this page shows to much info about your system.

For example, if you have this servelt config in web.xml file:
<servlet>
 <servlet-name>ApacheCXF</servlet-name>
 <servlet-class>org.apache.cxf.transport.servlet.CXFServlet</servlet-class>  
 <load-on-startup>1</load-on-startup>
</servlet>

<servlet-mapping>
 <servlet-name>ApacheCXF</servlet-name>
 <url-pattern>/services/*</url-pattern>
</servlet-mapping>

The CXF info page will be: http://domain/context/services.


In order to disable this page I found two solutions:
  1. Disable the page at all
  2. Securize the page

Disable the info page 

In the servlet configuration you have to set the parameter "hide-service-list-page" to value "false".
<servlet>
 <servlet-name>ApacheCXF</servlet-name>
 <servlet-class>org.apache.cxf.transport.servlet.CXFServlet</servlet-class>  
 <init-param>
  <param-name>hide-service-list-page</param-name>
  <param-value>true</param-value>
 </init-param> 
 <load-on-startup>1</load-on-startup>
</servlet>

<servlet-mapping>
 <servlet-name>ApacheCXF</servlet-name>
 <url-pattern>/services/*</url-pattern>
</servlet-mapping>

Securize the info page

You can allow only certain users (based on their Application Roles) see this page.
In the web.xml file add the following lines:
<security-constraint>
 <display-name>CXF services list</display-name>
 <web-resource-collection>
  <web-resource-name>CXF services list</web-resource-name>
  <url-pattern>/services</url-pattern>
  <http-method>GET</http-method>
 </web-resource-collection>
 <auth-constraint>
  <role-name>roleAdminCXF</role-name>
 </auth-constraint>
 <user-data-constraint>
  <transport-guarantee>NONE</transport-guarantee>
 </user-data-constraint>
</security-constraint>

<security-role>
 <role-name>roleAdminCXF</role-name>
</security-role>

In this way, only users with roleAdminCXF will be able to see it.

miércoles, 23 de noviembre de 2016

JBoss EAP - Exclude logging modules

If you want to pack your own logging configuration inside your web application, you need to exclude JBoss logging modules.

Create a a file called jboss-deployment-structure.xml inside META-INF folder:
<?xml version="1.0" encoding="UTF-8"?>
<jboss-deployment-structure>
 <deployment>
  <exclude-subsystems>
   <subsystem name="logging" />
  </exclude-subsystems>

  <exclusions>
      <module name="org.apache.log4j" />
      <module name="org.apache.commons.logging" />
      <module name="org.jboss.logging" />
      <module name="org.jboss.logging.jul-to-slf4j-stub" />
      <module name="org.jboss.logmanager" />
      <module name="org.jboss.logmanager.log4j" />
      <module name="org.slf4j" />      
  </exclusions>
 </deployment>
</jboss-deployment-structure>

sábado, 5 de noviembre de 2016

Log4j diagnostic contexts

You have a cool web application with a lot of logging information. Each action the user performed logs a suitable amount of traces in the way of DEBUG, INFO, ERROR, etc.. But there are a lot of concurrent users performing the same actions and their logs messages are interleaved witch each other.

Of course you have the thread name in order to track down one specific user, but threads are poolled and so the names are. Multiple users may, at one time or another, pick the same thread and so the mess will continue.

If you are using Log4j there are two useful features called nested diagnostic contexts and mapped diagnostic contexts. In esence, Log4j allows you to insert arbitrary context information at some point in the thread execution and all subsequent logging instructions will retrieve and print that information.
In this link there are more info about thase two features.

In order to apply this in your application, one possible option would be to declare a Servlet Filter which populate the context. A useful context information could be:
  • A unique identifier
  • The user name, if any.
  • The user IP

For example, this is my ContextInfoLogFilter (I used the OncePerRequestFilter of Spring):
import java.io.IOException;

import javax.servlet.FilterChain;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

import org.apache.log4j.MDC;
import org.springframework.security.core.context.SecurityContextHolder;
import org.springframework.stereotype.Component;
import org.springframework.web.filter.OncePerRequestFilter;

@Component("log4ContextFilter")
public class ContextInfoLogFilter extends OncePerRequestFilter {

 @Override
 protected boolean shouldNotFilter(HttpServletRequest request) throws ServletException {
  return request.getServletPath().startsWith("/resources/");   
 }
 
 @Override
 protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain filterChain) throws ServletException, IOException {
  try {
   MDC.put("key", System.currentTimeMillis());
   MDC.put("usuario", getUsuario(request));
   MDC.put("ip", getIP(request));     
   filterChain.doFilter(request, response);
  }
  finally {
   MDC.clear();
  }
 }
 
 private String getUsuario(HttpServletRequest request) {
  if (SecurityContextHolder.getContext() != null 
    && SecurityContextHolder.getContext().getAuthentication() != null) {
   return SecurityContextHolder.getContext().getAuthentication().getName();
  }
  else if (request.getUserPrincipal() != null) {
   return request.getUserPrincipal().getName();
  }
  return "ANONYMOUS";
 }

 private String getIP(HttpServletRequest request) {
  final String ipAddress = request.getHeader("X-FORWARDED-FOR");
  if (ipAddress == null) {
      return request.getRemoteAddr();
  }
  return ipAddress;
 }
}

Remember to declare this filter after Spring Security Filter Chain, in order to have the security context.
(... Other Filters ...)
<filter>
 <filter-name>log4jContext</filter-name>
 <filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>
 <init-param>
  <param-name>targetBeanName</param-name>
  <param-value>log4ContextFilter</param-value>
 </init-param>
</filter>

<filter-mapping>
 <filter-name>log4jContext</filter-name>
 <url-pattern>/*</url-pattern>
</filter-mapping>


Finally, in your log config file you must configure the log pattern with the %X{property} conversion character. In my case I used "[%X{key}: %X{usuario} - %X{ip}]", which will extract the "key", "usuario" and "ip" properties from the mapped context.
You can check all conversio characters in htps://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/PatternLayout.html.

Fo example, this would be  my log4j.xml file:
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE log4j:configuration SYSTEM "log4j.dtd">

<log4j:configuration xmlns:log4j="http://jakarta.apache.org/log4j/">

 <appender name="CONSOLE" class="org.apache.log4j.ConsoleAppender">
  <layout class="org.apache.log4j.PatternLayout">
   <param name="ConversionPattern" value="%d{ISO8601} %-5p [%c] (%t) [%X{key}: %X{usuario} - %X{ip}] %m%n" />
  </layout>
 </appender>

 <appender name="LOG" class="org.apache.log4j.RollingFileAppender">
  <param name="File" value="${jboss.server.log.dir}/seguridad-presentacion.log" />
  <param name="MaxFileSize" value="10MB" />
  <param name="MaxBackupIndex" value="10" />
  <layout class="org.apache.log4j.PatternLayout">
   <param name="ConversionPattern" value="%d{ISO8601} %-5p [%c] (%t) [%X{key}: %X{usuario} - %X{ip}] %m%n" />
  </layout>
 </appender>

 (... Other log stuff ...)

 <root>
  <level value="INFO" />
  <appender-ref ref="CONSOLE" />
  <appender-ref ref="LOG" />
 </root>

</log4j:configuration>

Also, you need to keep in mind that a web application may has multiple entry points, not just a common HTTP request message. For example:
  • If the entry point is a web service you can use an interceptor to create the log context. In CXF you have this.
  • If the entry point is a EJB you can also use an interceptor as this or simply receive some information as a method parameter.

lunes, 31 de octubre de 2016

Spring MVC prevent caching static resources

Static resources like scripts or stylesheets are very good candidates for be cached by the browser. These resources don't  change during the life of the web application version, neither the adress where they are published, so there is no need to be actively fetch them in each request.

The problem is, what happen when one of these resources do change, for example, after the deployment of a new version of the web application. In this case, the browser keeps the previous resource version and the final user can't see the changes. In order to force the browser to refresh these resources, the user has to do something like Ctrl + F5, but this is quite cumbersome for the User Call Center.

That´s what happened to one of our web applications, so I started to thinking about some, more o less dirty, solution.

My first thought was to rename the resource file after each release. For example, if I have a /resources/css/styles.css file, I would rename it to styles-1.4.0.css file. In this way, when the resource was called from a HTML, the browser would interpret that this was a new one and made a new request.
This solution can be achieved by using Maven resource plugin, with filtering. But you have to parse all your JSP files where the resource is referenced, and also you need to rename these files to something like styles-${project.version}.css. I didn´t like.

Second try, google.
The first google solution was to use a cache control directive inside the mvc:resources configuration. You configure your resources to be valid only for a short period of time, so the browser will understand that they need to be reloaded after some time.
<mvc:resources mapping="/resources/**" location="/resources/">
    <mvc:cache-control max-age="3600" cache-public="true"/>
</mvc:resources>
This is valid, but you still depends on the browser goodwill. Besides, if your static resources don't change during the version lifespan, the browser should never reload then.

The second google solution was using Spring 4. As you can see in this good post, Spring 4 can create resources's fingeprints, so the file name is attached with some sort of hash automatically created.
This is exactly what I needed, but I was working with Spring 3. My web application had also dependencies with spring security and other spring components, so migrating all this stuff could take me some time.

Finally, I decided to make a mix with the Spring 4 aproximation and use the web application version as a query parameter. In this way, from the HTML the request will be something like http://domain/app/resources/css/styles.css?v=1.4.0

I created a custom tag (resources.tag) that is responsible for composing the full URL based on the resource path and on the application version.
<%@ tag pageEncoding="UTF-8" trimDirectiveWhitespaces="true"%>
<%@ taglib uri="http://www.springframework.org/tags" prefix="spring"%>

<%-- Parámetros --%>
<%@ attribute name="resource" required="true" description="Path del resource"%>


<spring:eval expression="@applicationProperties.getProperty('version')" var="version"/>
<spring:url value="${resource}">
 <spring:param name="v" value="${version}"/>
</spring:url>

You need to have a properties file inside the application context which holds the version key.
<context:property-placeholder properties-ref="applicationProperties" order="1" />
<bean id="applicationProperties" class="org.springframework.beans.factory.config.PropertiesFactoryBean">
 <property name="locations">
  <list>
   <value>classpath:conf.properties</value>
  </list>
 </property>
</bean>

And here is the conf.properties.
version = ${project.version}

(... other keys ...)

As the version property value is also a placeholder, it is Maven who sets the proper value during the build phase. You need to set your configuration in the pom.xml file.
<build>
 <resources>   
  <resource>
   <directory>src/main/resources</directory>
   <includes>
    <include>conf.properties</include>    
   </includes>
   <filtering>true</filtering>
  </resource>
 </resources>

 <plugins>
  <plugin>
   <groupId>org.apache.maven.plugins</groupId>
   <artifactId>maven-compiler-plugin</artifactId>
   <version>2.3.2</version>
   <configuration>
    <source>${java-version}</source>
    <target>${java-version}</target>
   </configuration>
  </plugin> 

  <plugin>
   <groupId>org.apache.maven.plugins</groupId>
   <artifactId>maven-resources-plugin</artifactId>
   <version>2.5</version>
   <configuration>
    <encoding>UTF-8</encoding>
   </configuration>
  </plugin>

  (... Other plugins ...)
 </plugins>
</build>

Finally, inside your JSP, when you need to reference a static resource, you only need to use your custom resources.tag:
<link rel="stylesheet" type="text/css" href='<custom:resources resource="/resources/css/styles.css"/>'/>

domingo, 30 de octubre de 2016

JBoss - Spring URL UTF-8 encoding

If you need to pass special characters in the request parameters, the browser will encode them by using the specified encoding. This is the case, for example, when using the JQuery serialize method to compose a URL with the elements inside a form.

In my case, the problem arose when I was trying to load a jqGrid base table. The user fills some fields inside a form and when she presses the search button, a jqGrid is created and a request is sent to a Spring MVC Controller.
$("#myGrid").jqGrid({
      url: '/myapp/mypage/search?+ $('#myForm').serialize(),
      loadonce:true,
      mtype: 'GET',
      datatype: "json",
      (...)
});

When some field inside "myForm" has special characters, for example 'áéíóú', the URL generated will be as follows:
http://localhost:8080/myapp/mypage/search?descripcion=%C3%A1%C3%A9%C3%AD%C3%B3%C3%BA&_search=false&nd=1477817915534&rows=20&page=1&sidx=&sord=asc
These values are the result of converting the input text to UTF-8. Inside the controller you would see ANSI characters but the application is expecting UTF-8.

The solution is to configure URI encoding in JBoss EAP 6.2 connector using the following standalone.xml configuration:
<system-properties>
     <property name="org.apache.catalina.connector.URI_ENCODING" value="UTF-8"/>
     <property name="org.apache.catalina.connector.USE_BODY_ENCODING_FOR_QUERY_STRING" value="true"/>
</system-properties>

In domain mode you can configure these properties at server level or server group level.
There are more useful JBoss properties I collected in a previous post: http://trabajosdesisifo.blogspot.com.es/2015/12/jboss-useful-system-properties.html

Anyway, if you are working with UTF-8, don't forget the the Spring CharacterEncodingFilter.

domingo, 23 de octubre de 2016

Jenkins - SonarQube - Exclude sources from code analysis

If you need to exclude some folders from SONAR code analysis, for example, style sheets or javascript files, there are two options:
  • Set exclusions in the POM.XML file.
  • Set exclusions in the SONAR Runner plugin, in Jenkins.
In both cases, the key properties are (check http://docs.sonarqube.org/display/SONAR/Narrowing+the+Focus):
Use exclusion to analyze everything but the specified files:
  • sonar.exclusions - to exclude source code files
  • sonar.test.exclusions - to exclude unit test files
Use inclusion to analyzes only the specified files:
  • sonar.inclusions 
  • sonar.test.inclusions


For example, in POM.XML:
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
 (...)
 
 <properties>
  (...)  
        <sonar.exclusions>**/*.css,**/*.js</sonar.exclusions>      
 </properties>
 
</project>


In Jenkins, you can configure the SONAR plugin inside each job. In the Post-build Action you can set this configuration in the "Aditional properties" fields with "-D" prefix.


When the job runs, in the output console you will see something like this:
[INFO] [15:20:44.174] Source paths: src/main/webapp, pom.xml, src/main/java
[INFO] [15:20:44.175] Test paths: src/test/java
[INFO] [15:20:44.175] Binary dirs: target/classes
[INFO] [15:20:44.176] Source encoding: UTF-8, default locale: en_US
[INFO] [15:20:44.176] Index files
[INFO] [15:20:44.194] Excluded sources: 
[INFO] [15:20:44.194]   **/*.css
[INFO] [15:20:44.194]   **/*.js
[INFO] [15:20:47.235] 366 files indexed