Hi, I am not sure that the user data you mentioned is used by (all!)
workflows to prevent other workflows from firing. Where did you find
this documented?Regarding your usecase you have test many different
conditions (actually a lot of changes happen on cq:PageContent nodes).
Maybe an ObservationListener or a ResourceChangeListener are better
Hi, AFAIK the security checklist advises you to always have a dispatcher
in front an AEM instance. And then configure this on the
dispatcher/webserver. And in that case no one will have direct access to
the AEM instance (except maybe admins).
The OSGI ResourceResolverFactory configuration contains a configuration
if this situation needs to be logged. This was enabled in the past, but
in newer AEM versions the default has been changed. So on any freshly
setup instance this cannot be observed (anymore). From a personal
perspective this is unfortunate 😞
Thanks for reporting. But there is nothing you can do about it. I am
currently following up on this topic internally in Adobe.(Fortunately
this does not have any negative impact on your application.) Jörg
Have you already explored if the MultiSiteManager (MSM) would a solution
to your problem? It is designed exactly for this usecase.
Hi Franceso,Actually that's very easy, because it should not matter at
all how a user got logged in. Assuming that you have mapped that user to
a JCR user (what the standard SAML authentication does) you can just do
something like User user =
The time it takes to upload the binary to AEM is typically recorded in
the access.log of AEM/dispatcher in front of the authoring instances.
You can also check the request.log for the respective numbers. But I am
not aware of any way that this number is recorded. The number is not
really actionable, because it depends too much on the network bandwidth
between the desktop and AEM.
In the dispatcher configuration the cache invalidation is typically
constraint to a certain network / IP range. And that's probably
configured differently now than it was before. Check the dispatcher
configuration for the parameter "allowedClients" (see also the
you migrate to AMS, your CSE will not allow you make this functionality
available to everyone (wh...
Your prblem is that you want to reuse an already existing vanity URL.
Vanity URLs can exist only once per server, it cannot point to both
locations. Personally I wouldn't use it, but rather the map the resource
path to a proper URI using resource mapping. That's much more convenient
and scales much better (assume that you want to have "nice" URLs also
for other pages). Others in this thread have already pointed out URLs
where you can read how you can achieve that. HTH,Jörg
With "measuring time to upload" you mean the time it takes to get the
file from your local machine to the AEM DAM, is that correct? I am
asking because the others in this thread are already talking about
"workflows", and from my opinion the workflow is just starting then the
complete asset has been uploaded to AEM and is fully available within
the repository.Can you clarifiy that? Jörg
Hi, you mention "blocking links", which makes me think of "blocking
URLs". So do you want to block some URLs so they are not reachable from
the public anymore? That would be a topic for using the dispatcher to
for the official documentation how you can allow or deny access to
Archival is a tough thing, also because it's so diverse. First of all,
from my point of view, archival is not backup. You archive things which
are finished and closed, and you need to keep them around for mostly
legal reasons. Just storing files on a fileshare is not an option,
because everyone can read and write on them (you cannot check for
integrity), you don't have an audit trail, and you can not delete these
records on time (because you must not keep them longer than
required).For this requ...
Are you using the Audit Log functionality of ACS AEM Commons? In that
case you should raise a ticket there.It seems that the query you are
doing is not covered by any index, and to preserve the performance of
the instance, the query is terminated after 300k nodes have been
Hi,do I understand you correctly, that if a user opens a page in
editmode and this is part of a workflow, you would like to retrieve the
workflow ID of that workflow? What would you like to do with that ID?
HI,I think this are topics you need to discuss with your CSE, because
that's not standard. Regarding authentication I would recommend you to
switch to use IMS ("AdminConsole") and connect it to your SAML provider.
That should address a lot of the needs.
What are your requirements regarding archival? If these are legal
requirements, you can an archival solution which satisfies all these
legal requirements. I typically recommend this archival strategy for
pages: Together with the publishing process you create a PDF/A of the
published page, which contains all relevant metadata as well. Store this
in your archival solution. The archival solution must then provide the
necessary features like retrieval, search for metadata, audit trail,
Of course this can be done in AEM. But in that case you don't make use
of the features of AEM at all. For example, why do you want to store
"HTML" within the repository, and why don't you use the standard ootb
edit mode for creating content? This is WYSIWYG too. it can be embedded
in a SPA as well.(Not sure how this Spring Boot application fits into
it, but you can of course make your SPA talk to this application too.) I
would recommend that you talk with an AEM architect, who can recommend
Only AEM 6.5 and AEM as a Cloud Service support Java11. And the
migration of the codebase of your application is typically a no-brainer,
because in most cases you don't have to do anything with your code.
There might be 3rd party libraries, which might have problems with
Java11 (mostly the module system introduced with Java9), but Sling and
AEM work flawlessly with Java 11.
Hi,It is the decision of the core component team to hide the
implementation classes. My recommendation is to have that discussion at
the core components repository at
https://github.com/adobe/aem-core-wcm-components/issues.You get the best
answers there for this question.
I am not aware of any reason why it should behave differently. There is
likely some configuration which you haven't checked and which makes the
difference.You should work systematically down and check with curl the
CDN and then each publish instance if the headers are missing or not.
To be coherent, I would unify the way your frontend is created.
Personally I am not in favor of any (I don't build frontends), but as
one part is already using webpack, I would think that switching the part
also to webpack isn't that hard (you already have some experience in
your team how it works).
Ok, understood. But that means that you reconfigure AEM explicitly for
this request. The timeout configuration is a safety measure of every
system, which allows it to recover from operations which take too long.
If you increase the overall timeout, the loosen this safety net a bit.In
your case you have 2 timeouts to consider:* The timeout of jetty (the
request from user to AEM)* the timeout of your external request (from
AEM to the external system) You have to increase the timeout of both.