While looking at the AEM 6.x security checklist I saw the hint on the Form Chooser Servlet. https://helpx.adobe.com/experience-manager/6-3/sites/administering/using/security-checklist.html#main-pars_text_1734142030
I wonder what this servlet is good for? For what is it used? Can it be just deactivated completely? Are other servlets or features within AEM using this feature and build on its availability?
While searching for a description, I could only find some code (https://github.com/ooyala/Ooyala-AdobeCQ/blob/master/ui/src/content/jcr_root/libs/foundation/src/impl/src/main/java/com/day/cq/wcm/foundation/forms/impl/FormChooserServlet.java), but not the actual use case behind the feature.
Given the high risk of receiving a DoS when this servlet is actively listening, I'd think of rather deactivating it.
Somebody here able to shed some light on this?
Related
I just started at my new job and found myself right in the middle of a big project using Adobe AEM CQ, which I've never used before. Currently there are developers creating and tweaking components while content authors are busy authoring about 65 pages of content using those components.
Obviously, every time a component changes someone needs to update all the authored content with the new component changes. This is a huge time-waster as it seems like the only way to do this is through a custom made script that looks for nodes in the xml files and tries to convert them to the new component specs. Sometimes this is not even possible and authors need to re-author tons of stuff and lose lots of time.
Can anyone with AEM experience please let me know if:
1) There is a more painless way to migrate authored content to new components?
2) There is a better way to have developers and authors work simultaneously?
I know that the ideal way is to develop components first, and then author on top of those but it seems unrealistic especially with a big client project where things change all the time.
Thanks
Firstly, it sounds like a business process problem. The components should be fully developed and fully tested before content is being added by the authors. If the edits to components are so different that you're having this problem, i would recommend having functional and technical requirements written before the build starts.
With that said, the Groovy console for AEM is an excellent tool for updating nodes and content within an AEM site. Take a look at it here: https://github.com/Citytechinc/cq-groovy-console
I would not agree that content production should happen after all the components where developed. It's beneficial, especially when the content production will take a lot of time, to start it while the development is happening.
On the other hand I completely agree with the other part of the answer. Groovy Console is a way to go, when dealing with content migration (both before Go Live and after, during BAU process). Ideal situation is where all the current content can be mapped to data in new version of component. Then you should be able to migrate all the content with scripts. If that's not the case then you can't run away from authors putting the content manually.
Definitely components should be fully developed before their usage.
But if you want to change something specific in a component which will remain same for the entire website just like logo component or header component you can look into the Design Dialog.
So advantage of it is:
If you have already done authoring for n pages, when you change the component using Design Dialog it will be automatically reflected in all the pages wherever the component is being used.
AEM is a CMS where content is your data is put it in simpler terms. If your development process is such that data is inconsistent with the UI after every release then your delivery process might be at fault. You can use the following ways to make things better:
Make components backward compatible with the data
Make components version-able, i.e. new versions of components work with new models of data and it's left to the user to use new versions.
Provision for data or component migration in your project plan.
In practice, most AEM implementation make components backward compatible and provide an upgrade path to new versions. This is not a technical problem, it's more of a project governance issue.
This post is resurfacing so don't want people to get wrong idea from the current state of answers (and some answers that should be comments IMHO) but the approach in general to deal with components and releases is not a technical problem of the platform.
Which is better for web content management purposed only?
The website requirements include a user discussion forum and a poll survey with a good search facility and also needs a good SEO tool. The site should also load faster and should be easy to edit contents.
I can't speak to Jahia, but dotCMS can do everything you're asking for. Below are some links that should help you self evaluate dotCMS. I also would point out that dotCMS is more of a platform (makes a great user experience platform UXP) than an off-the-shelf solution and because of this your requirements might take a little work to setup and get running. With that being said, your finished product should meet your exact needs.
Site Search (uses ElasticSearch)
http://dotcms.com/docs/latest/SiteSearch
Performance Report
http://dotcms.com/aw/performance-report
I hope this helps.
Jahia should be able to handle these request. I am the opposite if Fish and have experience with jahia. Jahia does have a forum and poll component's both available as open source so you can modify the code when you require to.
What I like about jahia (among many other things) is that editing content is straight forward and very easy to for non technical persons. ofcourse it has all the permissions in place for all content so you can set it up in such a way that you don't have to be afraid that the non technical persons will mess-up a website.
Performance of Jahia, even without fancy caching proxies is very good and it can run on low resource VM's, just if you want to start small. I am using them on small Linode machines without any issues
I have not worked with Dotcms, but basic forums, polls, search, and SEO are all freely available as Jahia modules. The forums are certainly not as good as a standalone like Vanilla, but they are simple to add and administrate. Search is good and requires little configuration, and anything more than basic SEO is going to be custom work.
I have requirements to establish a CMS system for enterprise and it has to be java based open source, I found out that liferay has CMS capabilities but I'm not able to find any detailed description of the features introduced on its CMS , also I found some people are talking about integrating Liferay with Alfresco ! does this mean that Liferay is not a complete CMS ? appreciate if anyone can guide me through this and provide me with any resources detailing liferay CMS features
Yes, Liferay has CMS features - coming from a portal background the CMS is only one of the many features delivered out of the box. A portal typically is an integration platform for any kind of application. If you ever only need CMS, it might be that "pure" CMS products offer a bit more of functionality, however, many people are very happy with the CMS functionality Liferay provides. And if you're not, it's typically easy to extend (this is the point of a portal).
Systems that start being a CMS and want to extend that with applications (who doesn't want that) typically have a different mindset - "everything is content" - and naturally your application feels a bit more like "content". The portlet standard, together with the additional APIs that you have available, is a nice way to start.
For CMSs the way to go is typically a proprietary API to extend it. In a portal, a CMS is one of the possible applications available.
Regarding Alfresco: Yes, you can combine it with Liferay. While Alfresco tends to come more from the Content-side, Liferay comes from the portal/integration side. I'd ask you to evaluate both first and see if you are missing vital features in any. Then evaluate which pain you'd like better: 1) Add the missing features you want in the system you decide for, or 2) integrate both systems and run them both. Of course, the optimum result is if only one of the two is sufficient for your requirements. Then project into the future and try to find out what you'll miss first.
There is no correct answer to this question, it all depends on your requirements, experience and ability to learn and administrate one or both of the systems.
Disclaimer: See my profile to detect my implicit bias - I hope to not stress it too much in this answer.
I know this question sounds like utter madness, but hear me out for a second. We're a mixed language shop that has a lot of ASP.NET MVC 2 applications in production. We've no interest in rewriting those applications in another language. That said, we're also a huge IBM/Notes shop. We plan to make the move to Websphere Portal 7. Most of our Lotus Notes applications will obviously integrate pretty smoothly; however, we're wondering if we can surface our .Net applications through the portal. I've used the IFrame portlet on a page and just pointed the url to the location of a few of our .Net applications. It appears that the application loads, allows for file downloads as it should, can still detect Active Directory, and even the jquery we're using to trigger the auto-save in the background works just it should.
My question: is there a better way to do this? I know it's not ideal.
Another question along these same lines is: do you know of a more robust IFrame portlet that will let you set the width and height of the portlet or will dynamically re-size itself based on the contents it's loading?
You can also use the Web Application Bridge, which might be the best solution for existing applications. For new development, I would recommend wsrp with netunity.
You can use Iframe to display the links of the existing .NET application.
So there wont be any need to re write the entire code.
Hope this helps :)
My understanding is that you can use WSRP to do this. NetUnity is one option. MS apparently has one as well. Would love to hear how it goes.
I am working with Coldfusion 9, running under jBoss/Liferay 6.
All is well, I have developed quite a few portlets that I have made work around for (when I run into some issues that I could usually handle in a straight forward fashion). Overall Coldfusion 9 portlets work very well inside of Liferay.
One thing I really dislike is that the URLs are so unreadable, and I was really hoping for clean urls for my application, so when a user searches, and the result comes back, I can have them click a link like http://liferaysite.com/web/viewitem/ABC123.
Currently I get a raggedy URL that includes portlet status, properties, the portlet ID associated with the variable that I am passing (usually a combination of portlet id + variable) and other garbage that is un-needed.
Is there any 'easy' way to get clean URLs? My issue is that I am not a JAVA person, so I am not too confidant in digging into jBoss/Liferay code to get something done. However I feel that Liferay is sufficiently 'hands-free' so that I can build my portlets and deploy them without modifying JAVA code and getting dirty.
Any ideas? I am not able to find many articles on this, especially since Liferay 6 is so new, and there are so few people posting things about it. Maybe this would be some sort of URL rewriting in Jboss?
Thank you, appreciate any and all suggestions :)
The short answer is to use URL rewriting to achieve this and transform Liferay URLs to any form you want. There are 2 possibilities I see to do this:
Put an Apache web server in front of your Liferay server and use mod_rewrite
Use the URL rewriting filter that is already included in Liferay as this mimics what mod_rewrite does without the requirement of an extra Apache server
You might be interested in FriendlyUrlMappers. See this blog entry about the basics.
Regarding the "easy" you have to judge about that yourself. The nature of portals, e.g. combining completely different and independent applications (portlets) on a single page bring with it that you loose control over URLs (by default), because the portal has to disambiguate quite a lot of stuff. In order to get back control, you need to do some work, FriendlyUrlMappers impose some work, but the result is worth it IMHO.