5 reasons of why Adobe/Daysoftware CQ sucks
Here I’ll try to summarize 5 reasons of why Adobe/Day CQ DOESN’T suck; it’s only perceived by the end user in this way.
1. Your organization is not ready for the new paradigm
If you are not ready to change your habits in web applications delivery/development and you’re not going to thinking of the web page in term of content and don’t provide appropriate roles as authors, reviewers and developers… Yes in your case CQ can sucks.
2. You are not willing to learn
If don’t want to learn the full stack of CQ, the way of using it at his maximum potentials and stuck on your position that you still want to deliver “full pages” (JSP) instead of thinking in term of templates and components… Yes in your case CQ can sucks.
3. You don’t want to listen to consultant
Adobe/Day consultant are there to help you in delivering your site as fast as possible and at the best of all your (reasonable) requirements. If you ask them for an opinion/solution and when it’s given, you reply them «…sorry I don’t like it. Don’t you have something else…», always try to impose your mind instead of open-thinking and understanding something new. Yes in your case CQ can sucks.
4. No magic button
There’s no magic button/tool. If you bought CQ because you saw his potentials in leaning the delivery of content for web applications and you wanted to lean your 6 weeks delivering delta for each editing but then you’re not changing your internal procedure and stuck yourself in a 6 week review for each content change… well… Yes in your case CQ sucks.
Corollary: if you want to migrate your existing application and content, there’s no magic button/trick/shortcut. You’ll have to roll-up your sleeves, plan the correct amount of time and budget and start doing the actual job by cutting endless, futile, time-wasting meeting. Again: listen to your Adobe/Day consultants.
5. Wrong tool
You simply bought the wrong tool. CQ is an amazing WCM with DAM and some other cool stuff. If you bought it for implementing your cool ultra-customized-very-integrated-with-internal-corporate-process web application most probably you did the wrong purchase. Having the Sling stack in the middle with OSGI as well, it’s technically possible to do almost everything but this doesn’t mean that it’s sane to do it. Yes in your case CQ can sucks.
Corollary: JEE != OSGI.
The moral of the story is that CQ is a very amazing product, but as all changes in every aspects of life, you have to be ready to take the changes otherwise you’ll end up having another product that at the end you wont like. Sure it has his bugs and way to improve; but do you know of any products that is completely bug-free?
I’m curious as to what you mean by number 5. It makes it sound like CQ5 has interoperability issues (which is very different than the tone of the article). We’re evaluating the product as a possible CMS solution and if you are willing top talk with me send me an email so I can find out more.
Hi Lance, I’d prefer to discuss using comments, so that everybody get an added value from this.
First of all, all I’m going to say can be wrong. I have not the omniscience
Short answer: no, there’s no interoperability issues regarding CQ.
Long answer.
As I said in the corollary: JEE!=OSGi. This means that if you have a very JEE application (EJB, MDB) and you’re planning in moving it to CQ stack, you cannot think it will be possible with a little effort. Just take the Corollary of point 4. You will have to develop your EJB stack following OSGi paradigms.
Let’s take same examples.
Transaction. As far as I know, OSGi implementation of felix doesn’t come with container managed transaction. You’ll have to manage your transaction in the classical way: Connection.commit()/rollback() or hibernate equivalent. To use a database connection from an OSGi bundle you’ll have to add the configuration to the Felix console and use it in the classic way. No jndi/jaas; as far as I know.
Message Drive Bean. OSGi doesn’t provide something like the MDB out of the box. You can implement something similar using the event handler and/or threads. But you won’t have something automagically handled by the container like MDB is in JEE stack.
If you really have the requirement of having EJB stuff, I’ll suggest to keep the EJB deployed on their app server, and call them from the bundle as service. As far as I remember it’s possible to call EJB from plain JavaSE so it will be possible to call them from OSGi bundles.
If you have some technical perplexities regarding integration, I’d suggest you to ask for a meeting with an Adobe consultant and let him speak with your tech leads. I’ve seen Adobe consultant in action, and they are very keen to be fair and provide the best solution.
If you need to get a bit deeper here’s a couple of links:
http://wiki.easybeans.org/xwiki/bin/view/Main/OSGi
http://weblogs.java.net/blog/ss141213/archive/2010/04/22/osgijmsmdb-example
http://www.google.com/search?q=OSGi+ejb
http://www.google.com/search?q=OSGi+JEE
http://aries.apache.org/
HTH
And if you want a site that’s secure? Yes in your case CQ sucks.
@J, can you please argument your perplexities about security and CQ? So it’s possible to start a discussion
Post the URL of your CQ instance and I’ll tell you everything wrong with it.
Let’s say the public url will be http://www.geometrixx.com/en/products.html.
I’m getting a 404 error. BTW do you work for Day/Adobe?
Yes. It’s normal. It doesn’t exists. It’s only a url I’ll end up to if I should have to deploy in production the geometrixx example.
I don’t know a CQ published site by hand. I should have to search the web.
If your looking for a site I assume http://www.day.com would be running on CQ…. but it’s just a guess
double checked with the sources. Yes it is
day.com/adobe.com have, in the last month, patched most of the security holes on their sites.
I’ve decided against posting too many details on here because there are still many live sites affected.
Generally speaking, if you follow the security checklist VERY closely you should cover off most of the holes, but new / undocumented issues are not hard to find.
If you want more info, please contact me at: unidentified.email.address1@gmail.com
I still don’t understand. Sorry. Do you have a link to this security checklist? I spotted this article but don’t know if it’s what you were referring.
BTW I discovered that http://www.sbb.ch/ is running CQ. If you’d like to explain just one hole I’m really interested into it.
The security checklist is here:
http://dev.day.com/docs/en/cq/current/deploying/security_checklist.html
It is added to frequently with no notice to clients.
Here’s one, directory-like listing on the whole site:
http://www.sbb.ch/.feed.html
http://www.sbb.ch/content/sbbshop/en/railcity_08.feed.html
Hi J.
First I’m not defending CQ just as it is. I’m really trying to see the point.
The security checklist is not a product bug or security issue. If you think that Adobe/Day should notify the customers about each changing at the page, this is more a process issue than a security/bug product related. BTW I’ve seen that there’s a feed on the page, so everybody can subscribe to it in order to be notified if it changes.
Directory feeds. I don’t see the security hole in having the site structure listed. It’s like a site-map.
You may have some actual security hole, but any system is insecure if it’s not configured correctly and I’m hearing you say that adobe patched their holes so is the software hard to configure securely or are these just bad implementations?
How about directory feeds that let you navigate through user generated content to show you submitted form data? I won’t post any direct links for this, but it’s possible to do on that site.
Using these feeds you can find files that are not meant to be public, such as the upload form on day/adobe.com that let you freely upload and link files. This could also include test pages, or administration pages.
If you’re only storing public facing content in the repository then the feed probably isn’t an issue. However, this isn’t the case for many CQ clients who do put things such as confidential documents, or configuration files in the repository.
There are many “features” in CQ that shouldn’t exist, such as being able to add as many non-existent selectors to a page as you want: http://www.day.com/day/en/products.you.shouldnt.buy.html If you’re using a dispatcher you can use these selectors to generate an unlimited amount of files on the web server effortlessly until it runs out of disk space. Pick the right file (such as the other ‘feature’ that lets you get an xml listing of the entire DAM) and you could be creating a huge file (many gigabytes) in the dispatcher for each different selector you use. The “Preventing Denial of Service (DoS)” section was added to the security checklist because of this issue, however it doesn’t bluntly state: “Someone with little programming knowledge can easily flood your web server, using all the available disk space”.
When you’re paying top dollar for a CMS, you shouldn’t have to be engineering code to prevent a default install from allowing your web server to be flooded.
Thanks for the feedback J.
However it seems that all of the stuff you said is covered into the Security Checklist.
Regarding using feeds for accessing the user generated content I don’t think it’s true. As far as I know user generated content are stored in a different node. You can configure as usual your apache for not providing it.
BTW it’s always possible to configure apache for answer as you like with Rewriterule. For example if you’d like to disable the /.feed.html stuff you could try a rule like the following: RewriteRule /\.feed(\.[^/]*)?$ – [G]. Didn’t try it actually so it could not works. What it should do is giving your browser an HTTP 410 if you try to hit the /.feed.html
The main point is that you’d never put your JEE application directly into the web. You’ll always put it behind an Apache so that you can trigger a lot of security stuff that are difficult to do during development. Why CQ should be different? I think that if you’re going to investigate all other CMS you’ll find as much security holes as in CQ. And you’ll investigate custom web application it could be even worst.
Said this, thank you very much for the /.feed hint. I’m going to put in in my apache configurations.
The fact that you don’t think you can navigate through user generated content pretty much sums up my point. Generally speaking people don’t know enough about the CMS to properly secure it. But it’s not their fault, this isn’t stuff you learn in training.
Yes, user generated content is stored in a different location, but that doesn’t mean you can’t access it. You can access it on that site, but I’m not going to share those links because it may have sensitive data. Here’s a comment on adobe.com (geometrixx) that’s not too hard to find:
http://www.adobe.com/content/usergenerated/content/geometrixx/en/blog/2009/01/dsc_2008_show_inber.xml
Form data is stored, and is accessible the same way.
“However it seems that all of the stuff you said is covered into the Security Checklist.” Yes, it is… now. As I mentioned earlier they’ve been updating the security checklist quite frequently, and not letting customers know. The reason they’ve been updating it is because people are submitting support tickets, letting them know about the issues.
Don’t bother putting rewrite rules in to fix the .feed selector. Cut it off at the source. Put a dummy feed.jsp file in /apps/foundation/components/primary/cq/Page/. The reason this happens is because in training you learn to inherit from the foundation base Page, which has a feed “feature”. Doing this makes the .feed selector work on every single node in your site, but most people don’t realize this.
You don’t seem too concerned about this issue, but you only asked for the one. If you’re looking for something more severe then I’ll tell you about a bug that exists in a default, non hot-fixed version of 5.3. It is _possible_ that a username and password can be stored on the login page node. Supposedly this happens if you try to log in with JavaScript disabled, but I’m fairly certain I’ve seen it come up for people who don’t disabled JavaScript. You can see the username/password in plaintext on the node /libs/cq/core/content/login.xml on an author or publish server. It’d be stored as a property on the first line. Here’s Day’s login.xml file, which does not have a username/password stored on it: http://author.day.com/libs/cq/core/content/login.xml Yes, there are still sites out there that have this issue, and credentials are stored on this node in a publicly accessible place. If I come across any, I let them know.
As a side note, I’m contacting sbb.ch and letting them know how to fix the issues I did find, not all of which I’ve posted here.
And one last url: http://www.adobe.com/content/dotcom.feed.xml (which I’m sure will be fixed shortly, if they read this comment)
J,
“most people don’t know this”…well if you do your research into how Sling uses default servlets to render content, and you do a bit of poking around in your newly licensed CQ system, it is extremely easy to find the mechanism that renders this feed. True, people start off not knowing much about a new technology. However I find that if you want a solid implementation using any technology stack, a good deal of learning is required no matter what the technology is. Those who want a “magic-button” tend to complain about things and seemingly do their best NOT to learn.
A simple overlay of the default feed servlet under /apps/sling/servlet/default/feed.jsp (please note, that only overlaying the one under the foundation/page component will NOT disable this functionality entirely) will change this feed functionality to literally whatever you want it to be…yes, even simply returning a proper 404 response. It literally would take you about 5 minutes to accomplish. Additionally, you could add “allowedPaths” to the logic of the servlet, so that you could define which paths are allowed to be rendered as a feed, and return a 404 for anything outside of those explicitly specified.
Also, I most certainly would not call the ability to render a feed a “security hole”…and yes, the security checklist does get updated, the reason for which is to KEEP people (both customers and the public at large) up to date with the latest information about how you may want to secure your CQ instance.
Just like literally any platform, CQ can be as secure or un-secure as your implementation allows.
Best!
well thank you very much J.
This has been a very good read, Thank you.
Nice post on how securing CQ instance…
I was fascinated by your comment about DAY CQ5 not being the right tool, depending on the goal.
When you consider Day getting integrated into the whole adobe system, what’s you view on Day versus SiteCatalyst? Yes, one’s content management, broadly speaking, and the other is web analytics. In your opinion, if you put Day in, does it do enough analytic work to get by?
Just curious what you’d say about that stretch.
DG
Hi Doug, CQ starting from the 5.4 is very integrated with Omniture (aka SiteCatalyst). Depending on what you’ll have to do with Omniture in terms of tracking. The basic functionality of integration as far as I saw (didn’t have time to play yet) will come OOTB.
Oh yes, I forgot. As far as I can see by the press, it seems that Adobe WEM (aka CQ 5.5) will have an easier and stronger integration with Omniture.
http://www.cmswire.com/cms/web-engagement/adobe-releases-its-wem-solution-combining-cq-54-online-marketing-suite-010261.php
http://www.fiercecontentmanagement.com/story/adobes-new-web-experience-management-tool-combines-omniture-and-day/2011-02-22
https://www.google.com/search?q=adobe+wem+omniture
What if you’ve done 1-5? Following everything Adobe/Day consultants say. You embrace the template and inheritance system and think its wonderful! A more accurate name for Day would be the CMS Titanic. One small thing goes wrong… Nothing is isolated. Your entire site comes down. Much more accurate a name. Day’s help center Daycare… Have tickets closed with no explanation or given a “hotfix” you need to do right away on your production servers with no testing that they swear will fix everything. Need to upgrade, be told that your author instance will take 2 weeks convert the content and DAM items from 5.2 to 5.3 leaving your users with no way to update content. 2 WEEKS! Have production issues that take 12 hours to solve while your site is down AND heres the kicker… you make a suggestion to Day consultant on hour 1 only to be told no that’s not the issue when on hour 12 they have you implement what you brought up on hour one and low and behold, everything comes back up. How about security patches where no explanation of what the patch is so you have nothing to test against to even know if the patch worked. Sure, I trust everything is fine… Yes your right, Day is a wonderful tool that totally SUCKS. On the bright side I’m hopeful Adobe will turn things around. Starting with a total re-haul of the CMS. Since they’ve acquired Day Communique we in the Day nightmare are hopeful things will be turned around…
After 4 years of experience with CQ I can fully agree to most of the points mentioned. The system out of the box has awful configuration settings , from a so called enterprise content management system with a price tag like CQ has you can at least expect a configuration somehow optimized.
CRX itself is a unbelievable slow repository if it comes to deletion of nodes. Optimizing the repository (internal transaction) takes forever if your instance has a certain size.
Even with the help of consultants and partners it takes forever to have it running with an acceptable performance,stability as well as security.
CQ is the perfect tool if the only thing you want to take care of the next couple of years is something trivial like operating a web content management system, CQ is not your first choice if the web content management just has to work and you expect an upgrade to not cost 100’000s of USD.
If your company has evaluated CQ and you are involved in the operating you really should run away as fast as you can.
Hi Mike,
I personally don’t share all your statements.
I agree with the configuration OOTB. I find it nice to have everything ready for the development but when it comes to production deployment I agree with you, it’s very complex to configure it properly; specially if we speak about security. It would be very nice if at least where were some automated tools that test your instances and if something is not properly configured highlight it and how to fix it. Another big improvements could be to have a sort of “script” that configure it for you giving few common scenarios.
I don’t find CRX particularly slow. When I went to customers that complained about slowness of the repository, I discovered data not structured properly. Comparing to a RDBMS, it could be like asking to join 15 tables of 1m records each. It will be slow. BTW the delete operations are always the slowest.
About consultants or partners I have to admit that it’s not easy to find all the skills for various reasons and I am the first one working with CQ who doesn’t know everithing. CQ5 it’s a quite new product and it’s very wide in terms of stuff offered. It’s based on top of a stack that is mainly not known worldwide (including OSGi). Often I found very complex implementations that could have been solved easily knowing a bit more about CQ and OSGi.
I don’t find either CQ right only for simple things. It’s true that for a simple CMS site you won’t have to do anything, but it doesn’t means that you can’t customize it for doing very complex stuff.
As said in the post, I find it amazing but of course it has HUGE space for improving, specially in bugs and security.