Cookies error

I had this problem also and found another possible reason.

I was using the long URL to access Workspace:

http://<aem_forms_server>/lc/libs/livecycle/core/content/login.html?ap=1

I get the error about the cookies in every browser (Chrome, FF, IE and Edge), both on the server itself, and through remote access.

When I switched to the short URL, it works:

http://<aem_forms_server>/lc/ws

So this error seems to have multiple causes, which reflects the previous comment that it appears to be a catch all, when an unexpected error occurs.

We are starting to experience this problem as well.   We are running AEM forms 6.2

So far the only difference seems to be the the users getting the error are running Chrome on a Windows 10 machine.

Using Chrome on a Windows 7 machine seems to work ok.

Hi Darren,

Although checking for 'AEMFormsStartupListener -- startup has finished' is a good option but you may find that in the number of cases it might not appear in the logs.The best way again would be to log in to system/console and check for the bundle's state.

Hi Mayank. If we wanted to automatically scan for AEM Forms being ready in the OSGi environment, what should we specifically look for from a logging perspective?

I saw this line recently and wondered if this is what we should scan for:

1. 09.04.2018 14:47:08.833 *INFO* [FelixDispatchQueue] com.adobe.fd.core.startup.AEMFormsStartupListener AEMFormsStartupListener -- startup has finished

Hi Jared,

Adding to your 2nd point.

Since you have been using J2EE side from long .Instead of just waiting for an hour a good to way to confirm the start /stop operation is to tail the CRX error logs( [AEM-Installation-Directory]/crx-quickstart/logs) and see it the logs have stabilized.So, apart from App server logs, CRX error logs and OSGI bundle state may give you an information about the successful start of an instance.The same would also help in scenarios when you have to patch the environment with any CFP or SP .

I have a couple of things to add to this.

1) Rebuilding the entire repository as I've described is a pretty heavy-handed workaround.  That said, I don't have a better idea and neither does Adobe Support at this time.

2) Coming from LC ES3, I'm used to restarting JBoss and watching for the "started in N seconds" line in the log, at which point I know that everything's up and running.  That's not the case here.  If you rebuild the repository it's advisable to wait quite a bit longer (like 1 hour or more) before you access workspace.

3) I believe the problem occurs after logging into CRXDE Lite and AEM Forms Workspace at the same time with the same user account and the same browser.  This causes AEM to get into some conflicty state where you can no longer log into AEM Forms Workspace.  I have adopted a habit of using separate user accounts and separate browsers for CRXDE Lite and Workspace.  Since I started that practice, I have not had the dreaded Cookies problem.

Okay I have the fix for this, which came from Adobe Support.  This resolved the problem for me:

1) Stop JBoss

2) Delete all folders except for "install" under the crx-repository directory

3) Start JBoss

I'll answer my own question about the logging.  The settings are in lc_turnkey.xml.  I modified the setting for periodic-rotating-file-handler and <logger category="com.adobe">, changing "INFO" to "DEBUG".  I'm not sure if it was necessary to change both or if one would have been sufficient.  I restarted JBoss and my logs became much more detailed.

Unfortunately, the detailed logs didn't help me much in figuring out what's causing the "cookies" screen to appear upon logging on to Workspace.  Below are a few lines that may be relevant.  I've put in bold the bits that made me think these may be relevant.

09:29:12,246 DEBUG [com.adobe.idp.um.businesslogic.authentication.AuthenticationManagerBean] (Thread-386) UserM:: [Thread Hashcode: 1475448974] Trying to authenticate against AuthProvider com.adobe.idp.um.provider.authentication.LDAPAuthProviderImpl

09:29:12,246 DEBUG [com.adobe.idp.um.provider.authentication.LDAPAuthProviderImpl] (Thread-386) UserM:: [Thread Hashcode: 1475448974] Authenticating with LDAP Auth Provider

09:29:12,246 DEBUG [com.adobe.idp.um.provider.authentication.LDAPAuthProviderImpl] (Thread-386) UserM:: [Thread Hashcode: 1475448974] Domains fetched for LDAP Authentication

09:29:12,246 DEBUG [com.adobe.idp.um.provider.authentication.LDAPAuthProviderImpl] (Thread-386) UserM:: [Thread Hashcode: 1475448974] Authenticating against LMNOP domain

09:29:12,309 DEBUG [com.adobe.idp.um.provider.authentication.LDAPAuthProviderImpl] (Thread-386) UserM:: [Thread Hashcode: 1475448974] Got DN for user langdonj

. . .

09:29:12,434 DEBUG [com.adobe.idp.um.businesslogic.authentication.AuthenticationManagerBean] (Thread-386) Authentication successful for com.adobe.idp.um.provider.authentication.LDAPAuthProviderImpl and the user is identified as langdonj . . .

. . .

begin sql[http-/0.0.0.0:8080-1] - 
SELECT  COUNT(*)  FROM tb_cache_config T0  WHERE T0.qname = 'Replicated:UM_COOKIE_SESSION_CACHE'

09:29:12,449 DEBUG [com.adobe.pof.adapter.LoggablePreparedStatement] (http-/0.0.0.0:8080-1) 2948:. end sql[http-/0.0.0.0:8080-1, 0

. . .

09:29:12,449 DEBUG [com.adobe.idp.um.server.cache.UMCacheManager] (http-/0.0.0.0:8080-1) Using cacheType [Replicated] for Cache [UM_COOKIE_SESSION_CACHE]

09:29:12,449 DEBUG [com.adobe.idp.um.auth.filter.SSOFilter] (http-/0.0.0.0:8080-1) Successfully authenticated so redirecting to source_url?login_result=0 also added the auth cookie with Id 5AF65F09-FE4F-B55B-15A4-2A2BFE2495DE

Thanks Scott.  It's a fresh install, but it was working as of earlier today.  Then I installed Workbench on my workstation and logged into that.  Afterwards I could not log in to Workspace.  I'm guessing that these things are related because of what DarrenBiz said about "You can often see it when you try to log in with one session (e.g. AdminUI) and use another browser tab to open another session".  His remedy didn't work for me though. 

I'll prepare a support ticket, but it would be helpful to have a server log at the DEBUG or TRACE level to send to them.  Can you point me to instructions on how to change the logging level?  Thanks so much.

If you install on a fresh server - do you see this issue? Looks like there is an issue with your environment.