Alfresco Enterprise 4.1.4 was released on Thursday, bringing with it a slew of security and stability fixes. One such fix protects against cross-site request forgeries (CSRF). A CSRF attack is one in which malicious code pretends to be an authenticated user by piggy-backing on the trust granted to the user's browser, then performing requests as that user.
If you've built a custom application based on the Alfresco platform and are performing POST requests against either Share- or repository-tier webscripts, you may encounter problems after upgrading to 4.1.4 due to this fix. In this post, I will explain how to update your application to work with this fix.
Edit: Here is an official blog post on the new CSRFPolicy.
Laura, Michael and I have been banging our heads against this one for a few hours: The webpreview in Alfresco 4.1.2 Enterprise Share wasn't working, giving us an annoying error that read, "The preview could not be loaded from the server." On top of that, there were no exceptions in the Tomcat log.
On Wednesday I wrote about downsizing the monolithic project created from the Alfresco All-in-One Maven SDK archetype. My goal was to end up with a project that would only build and deploy the Alfresco repository AMP and Share JAR. After discussing with Gab Columbro, he suggested a more efficient solution of combining two AMP projects created from the AMP archetype. This ended up not only being easier to configure but the deployment process is faster and there is the added bonus of separating the repository and Share containers, which is a development best practice.
The all-in-one archetype generates a project with a buffet of extension projects for a repository AMP, a Share JAR, an Alfresco overlay, a Solr configuration, and a Web Quick Start deployment. I don't need all of these but none of the other archetypes offer what I consider the minimum projects: the repo AMP and the Share JAR. By using the all-in-one, I can pare it down to what I need and configure the resulting project for my system (Mac OS X Mountain Lion). I fully expect that this type of archetype will become available in the future, but in the meantime, here are the steps I'm taking to fit the project to my needs.
CMIS, which stands for Content Management Interoperability Services, is a standard that describes what you can do with items in a content management system. This includes actions like searching, querying metadata, updating or deleting content, and so on. It's an extension to AtomPub, meaning you perform these operations by posting XML-based requests to HTTP endpoints, which Alfresco provides via webscripts in versions 3.3 and higher.
Alfresco uses SWFTools -- specifically, "pdf2swf" -- to generate Shockwave renditions of PDF documents for document previews. If you're using HomeBrew to manage packages, and you run the following command, you might run into some problems:
$ brew install -v swftools
Namely, the "pdf2swf" command (among others) will not be installed due to some missing dependencies. This is most noticable when installing SWFTools on a clean system. To fix this, install the following packages prior to attempting the above command:
$ brew install freetext libjpeg giflib swftools
This should result in a clean build of SWFTools with the pdf2swf command available in your path and for use with Alfresco.
Last week I spent several hours automating the creation of an Alfresco development environment using bash scripts--copying sample project files, customizing Ant scripts and properties, creating databases, etc. While taking a break and surfing the web, I read several recommendations for Apache Maven. A few years have passed since I last touched Maven and I remembered it being pretty easy to use. I also remembered some chatter in Alfresco circles about an official Maven repository for Alfresco, so I decided to dig a little deeper to see if Maven could help me out. I was unprepared for just how slick--and fun!--it would end up being.
I've been creating quite a few development environments for Alfresco lately for various projects -- extensions, dashlets, and new customizations -- and decided to try scripting the setup to save myself some time. This involves creating the directories and copying the necessary source and project files, which is simple enough, but it also includes creating an Alfresco database and granting the correct permissions to it. In order to do this from the command line (I'm using a bash script on Mac OS X), I had to figure out some escaping trickery to get this to work.
I recently built a simple sequence generator in Alfresco as part of a project for a client who needed a way to configure and retrieve a unique integer value to be used both in Alfresco and outside of the system. The sequence needed to be global and maintain its current value across sessions and server restarts. While there were a few project-specific requirements, such as requiring multiple counters and a way to distinguish them, I've seen other requests for ways to do something along these lines. The approach I took was suggested by Mike Rogers, which is simply to create a custom type that will store the count as an attribute. My client needed a way to distinguish between multiple counters for various sequences so each is stored as a separate node. I then built a webscript to access and maintain it. These two steps are outlined below.