The default group configuration still works the same between 6.3 and
6.5. I would suggest to enable debug logging for
com.adobe.granite.auth.saml and see if there is some error when it tries
to add the user as a member of the default group. Also, make sure you
don't have any duplicate invalid SAML OSGi configs.
This issues sounds similar to a known issue with crx2oak on AEM6.3.
Please try running the same command using the latest oak-upgrade 1.6.20
jar here instead of crx2oak
To migrate to S3 from file datastore, the easiest way is to do the
following:1. Run your oak-upgrade or crx2oak migration with --datastore,
as you have done.2. On the destination repository instance, remove all
FileDataStore related config files - both fr...
Somebody might have accidentally deleted the configuration for the
service user by clicking delete in the /system/console/configMgr. I
would suggest you add the missing mappings manually again via
/system/console/configMgr UI in the affected environment. If the problem
is affecting many environments then please contact our support team to
debug the root cause.
SAML by design delegates the authentication itself to the IDP. The login
page you would want to customize would be on the IDP, not AEM. Do you
just want the login page to have a link for the user to click that takes
them to the SAML authentication process?
If the Jetty Session Timeout isn’t helping then it might be something
resetting the JSESSIONID cookie so a new session is generated per
request. You might debug if the value is changing per request. Also,
investigate your code to see if you even need JSP sessions. If you
don’t, then disable it in your code or in the jetty config default
Try to download the jcr:data property directly and see if the binary is
corrupted or if the workflow just needs to be run again. For
I meant to check the actual log, not the http response, to see if the
binary is missing in case you have this
Please send more specifics like a screenshot of the Assets UI for the
corrupt images versus good ones and any other specifics that might help
me in finding root cause for you.
Ah ok yeah, there is something conflicting then. If you have any custom
dam:Asset or dam:AssetContent workflow launchers then temporarily
disable those to see. Also compare your workflow launcher configs to a
fresh install of 6.4.7.
That error isn't a known issue with 6.4.7, so there must be something
conflicting with the workflow. Is the error being logged every time the
dam-xmp-writeback workflow runs? Please send a screenshot of the
Workflow Launcher UI. To debug merge conflict errors go to
http://aemhost/system/console/slinglog and add a DEBUG log
output of that log will give you an idea of what...
There is a known performance hit associated with nesting experience
fragments (especially in conjunction with container components such as a
responsive grid) due to how it calculates the allowed components and
styles. The recommendation instead is to leverage building blocks as a
Hi @ericr37211598 the URL for the published page depends on your
architecture. You can go to /etc/replication.html and view the
replication agents to see where they are pointing to. Then you can view
the page via those URLs.For
example:http://publishhost:4503/content/test/publishedpage.html Also, to
view the page in its final form: You might have a CDN then load balancer
fronting the site and DNS entry would be something you guys have chosen
for your site. For example:www.adobeaemtest.adobe.com ...