I would like to modify a deployed installation of Sakai to allow iframes from several on-campus media servers. An example of an iframe is https://mediaserver.example.edu/p/player.html. What is the easiest way to edit the policy files in the deployed Tomcat?
Antisamy is an open source API and html scanner and cleaner. Sakai 2.9 or higher uses this as a part of it's security suite to protect users from XSS (Cross Site Scripting) attacks caused by malicious user created markup.
Sakai includes a default set of configurations which are community tested and will likely meet most users needs. These include a low and high security option (high is the default). To force Sakai to use the low security setting you can add a Sakai configuration property as shown below (setting this to false will default to high security):
content.cleaner.default.low.security=true
The primary difference between the high and low settings is the blocking of unknown sites for external content (like vidoes or iframes). High only allows a limited list of trusted sites. Low allows content from any site. Both have extensive rules for protecting against javascript related injection attacks.
The Antisamy configuration files are XML based (see the Antisamy developer guide for more details). The standard high and low security files are located in the Sakai source code under "kernel/sakai-kernel-impl/src/main/resources/antisamy/". These can be used as a basis for a locally customized version. To override the included files, simple place a custom version in the Sakai home directory (typically TOMCAT_HOME/sakai), for example:
${sakai.home}/antisamy/high-security-policy.xml
${sakai.home}/antisamy/low-security-policy.xml
For your specific use case, you would probably modify the following section (near the top of the xml file) as indicated in the comment:
<!-- SAKAI customized trusted sites listing:
This is where we specify what Flash/embed/iframe src to allow
To add a new host/site to this list:
Find this in the flashSites below: ...(download\.macromedia\.com/pub|...
Add in your site (e.g. "new.site.host.com/path": with escaped ".": "new\.site\.host\.com/path|"
Like shown here: (new\.site\.host\.com/path|download\.macromedia\.com/pub|
-->
<regexp name="flashSites" ...
Related
Below is some info to have context about the problem I am looking for solution:
"I only want to have a prod environment for contentful. the preview url is being used for UAT and Dev environments. So if the content is in the draft it will be reflected in Dev and UAT and when published it will be reflected in both environments as well as Prod".
Now the issue is there are some links in content that has a prod domain like www.[prod-domain]/blah blah, I need those URLs domain to be replaced with UAT or Dev domains in the draft (depending on environment) like www.[UAT-domain].blah blah
Is there any middleware for this? if not, what's the best way to achieve this in-app?
Salma from Contentful here!
If you use relative links in the content (e.g. /blahblah), they would automatically resolve to the current domain when navigated to on the front end.
If you're using Rich Text and outputting links in the flow of the text, you could get around the protocol requirement in the usual link formatter by creating a custom 'internal link' entry content type, which you can embed as an inline entry. For this content type, you could ask editors to provide a path to a page without the https protocol and domain, and ensure there is validation for that in the web app (using the pattern validation).
Another option would be to remove the protocol and domain from the urls when rendering on the front end to avoid the editors having to create extra entries when adding content to the Rich Text field.
How do you do relative links within text editor component? Adobe AEM doesn't like when I use relative links to external pages by default. It strips them out and shows the broken link symbol.
I strongly recommend you to uncheck Disable Checking in Day CQ Link Checker Transformer.
Be aware that It's your responsibility to ensure all links are valid:
Completly disable all link checking. All links are handled as valid.
This is something you want to check with your team (Devs, TAs...). It may work on your local environment and it will fail in QA, UAT and PROD as this option is not checked.
Disabling the link checker might not be a good idea as Content Authors may add broken links, which It'll break user navigation throughout the site if this is not picked during testing and regression testing.
Regarding paths, relative paths are those within the environment you're in. For instance,
/content/dam/geometrixx/banners/banner-mono.png
is a relative path, however path to Stack Overflow is outside you environment therefore is external. In order to be valid, you need to provide the full URL including the scheme, either http, https, ftp, ftps and so on. A valid external URL would be:
http://www.stackoverflow.com
More info about URLs can be found here.
While disabling the link checker will work, I'm not sure how you are referencing external websites by relative link. Relative links are on the same domain by their nature. Can you give us an example of what you mean?
The other problem with disabling the link checker is that the production deployment will likely have the link checker turned on. In this case your code will break again. You probably don't want your client/boss/whatever upset about that.
Relative links can be made to work just fine with the linkchecker. Can you post some example links? I can help you make things work properly.
This issue is quite common, if you have URL's (paths) in your domain that are NOT served by AEM. This can be files directly served by the Apache (e.g. robots.txt), Servlets creating dynamic redirects (e.g. language switcher) or another application (e.g. web shop under /shop).
First solution is to mark an individual link for the link checker as valid. Therefore you can add the following attribute to the link tag.
x-cq-linkchecker="valid" - link is marked as valid, without any
check
x-cq-linkchecker="skip"- link is ignored by the link
checker, and remains as is
e.g. Shopping Basket
Second solution is to configure special-threated link patterns in the OSGi config of the “Day CQ Link Checker Service”. In case you have a second application in the same domain, then you can specify regex-patterns matching the links to this second application. User either “Link Check Override Patterns” (not checked, but rewritten) or “Special Link Patterns” (not checked and not rewritten).
Example configuration that only links to /content/* are verified. Links that not matching ^/content/.*$ are threated as valid:
<?xml version="1.0" encoding="UTF-8"?>
<jcr:root xmlns:sling="http://sling.apache.org/jcr/sling/1.0" xmlns:jcr="http://www.jcp.org/jcr/1.0"
jcr:primaryType="sling:OsgiConfig"
service.special_link_prefix="[javascript:,data:,mailto:,#,<!--,${,tel:]"
service.check_override_patterns="[^system/,^(?!/content/).*$]"
/>
Fixed my issue in /system/console/configMgr# > Day CQ Link Checker Transformer > Check "Disable Checking" box.
Relative paths now work.
I would like to implement an extensible templating mechanism in AEM, so as to permit component users to control markup for individual projects (designs) without modifying the components' pre-defined JSPs.
I have extended the <cq:include> tag to permit this, by passing a template name, which is then retrieved from the current design, falling back to the default markup when an override does not exist in the design:
<ct:template name="listNav/prev" />
This should load the jsp script from [1], unless the location does not exist, defaulting to [2]:
/etc/designs/projectName/component_templates/listNav/prev.jsp
/etc/designs/component_templates/listNav/prev.jsp
When using the extended tag, I'm receiving the exception (yes, the file exists):
Caused by: org.apache.sling.api.SlingException: javax.servlet.ServletException: javax.servlet.jsp.JspException: Could not find script /etc/designs/component_templates/listNav/prev.jsp
This all works when the component_templates is under /apps. Is there any way to make this work? Is there a better approach? I'd prefer to keep the component_templates with the designs, if possible.
I don't think it is a good idea to put application script to etc. They should be under /apps.
But I think it could work, if you add /etc path to the "Resource Search Path" of this service:
system/console/configMgr/org.apache.sling.jcr.resource.internal.JcrResourceResolverFactoryImpl
you can choose between different "designs" within the advanced page properties tab! afaik you should use this mechanism to declare different designts i.e. stylesheets etc. to your pages and of cause you don't need to modify anything at the jsp's to switch between different styles if implemented properly.
Have a look at this:
Adobe AEM Designs
It seems to be quite basic problem, but I still cannot find a nice solution.
I made a component that uses a dialog property.
How could I avoid setting this property for every single page if this component is used also in template?
What I already have tried:
I set name attribute in dialog.xml to absolute path - Component stops working as standalone (dropped into parsys).
Move it to design_dialog.xml - First of all it's conceptually content, so I do not like such move, and again it doeas not make much sense for standalone versions.
Change resource path to absolute, while including in template:
<cq:include path="/content/site/somepage" resourceType="/apps/portal/components/myComponent" />
For the first look it was almost it. Instances included via parsys has it's own path, and Content for template is fetched from single resource... But where to store it, to make template code independent from pages tree structure?
Is there any other nice way to do so? or at least way to improve 3.?
To the original poster, the functionality you are looking for is now supported by Shared Component Properties in ACS AEM Commons (http://adobe-consulting-services.github.io/acs-aem-commons/features/shared-component-properties.html)
Compared to your suggested solutions:
No need for absolute property path required for SCP
Agreed these are "content" properties, so they should be stored as "content" instead of "design". SCP stores these values under the homepage node of a site, making them as genuine of content as any other piece of content.
Agreed that it is bad to have a template hard-coded to a content path of a single site, especially since this makes a multi-site implementation impossible without creating a bunch of templates. SCP does not have this problem, because each site has its own homepage under which the properties are stored.
If I understand correctly, you have a component which may work in two modes:
it may be included statically in the main page renderer via <cq:include>
it may be also dropped into some parsys.
In the first mode component should have some common configuration for all pages and in the second mode it should be configured separately per-instance. The problem is how to create such common configuration.
I think your 3rd solution is perfectly fine assuming that the component configuration is shared by all sites in your CQ instance. At some point it may be too strong assumption, eg. you may have a 3 language branches under /content/site-en, /content/site-fr and /content/site-de and you'd like to make a separate configuration for each branch.
I'd suggest following improvement to the 3rd solution: you may create the shared component under some relative path which will be the same for all pages, like /content/.../configuration/shared-component (where ... may be site1, site2 or site3). Then take first two parts of the current page path, add the /configuration/shared-component suffix and use <cq:include> to include path created in such way.
You may also take a different approach and create a common configuration page referenced by all statically included components. These components may try to find their configuration automatically (via the relative path as above) or they may have a single pathfield that references configuration page.
If you don't like these options (as they assume some site structure or they need some minimal configuration for each component), consider using HierarchyNodeInheritanceValueMap. It allows you to get property from the current resource and if there is no such property, it'll look into the same resource on ancestor pages. Using this you could configure your component just once, in the site root page and inherit configuration across the whole site.
Can tell me if Ektron can do these things in SEO?
XHTML Compliant - Renders in XHTML compliant mark-up out of the box
Canonical URLs - Able to specific a canonical URL for a single page SEO
Friendly URLs - Able to create and configure SEO friendly URLs and formats
XML Site Map - Able to dynamically and automatically generate an XML Site Map Granular
Site Map Priorities - Able to set XML sitemap priorities in the page admin
Semantic Menu - A menu system that uses semantic mark-up
Google Analytics Integration - Full integration of the Google Analytics script
Search Engine Submission - Allows you to submit the website to a variety of search engines from an admin interface
XHTML Compatible Controls - All controls used (menus, grids, etc.) render XHTML compliant mark-up
XHTML Compliant - Renders in XHTML compliant mark-up out of the box
Not sure. You'll want to download the Developer starter site to check the control you are interested in. If you're concerned about accessibilty, I several controls have a 508 Compliance switch.
Canonical URLs - Able to specific a canonical URL for a single page SEO
In theory yes, in practise no.
Friendly URLs - Able to create and configure SEO friendly URLs and
formats
Yes. Option for manual, regex and automatic aliasing.
XML Site Map - Able to dynamically and automatically generate an XML Site
Map Granular
Site Map Priorities - Able to set XML sitemap priorities in the page
admin
Don't think this is out of the box. You would need to look at a custom solution.
Semantic Menu - A menu system that uses semantic mark-up
Not out of the box. You would need to customise the mark-up via XSLT.
Google Analytics Integration - Full integration of the Google Analytics
script
Yes, out of the box. See here for some help implimenting this.
Search Engine Submission - Allows you to submit the website to a variety
of search engines from an admin
interface
Not that I am aware of.
XHTML Compatible Controls - All controls used (menus, grids, etc.)
render XHTML compliant mark-up
See my answer to question 1. Out of the box - no, but depends on which controls you are using.
As Justin Niessner mentions, there is the option to overcome any of this via custom work. To help with your evaluatation, I recommend downloading the Developer starter site and having a look at the default markup of the control.
Also, there is an Ektron forum which is quite vibrant.
Edit - To clarify, I am not employed nor speak for Ektron. Just a developer who is working on the platform.
Yes. Ektron's CMS400 can do everything that you have listed there. It's all up to the developer to implement everything though (and it's a hell of a lot of work to get it all working correctly).